Unsafe Cookie Flags — Session Cookies Too Easy to Steal or Replay
Learn how Scavo checks live Set-Cookie headers for Secure, HttpOnly, SameSite, and prefix-rule mistakes so session and auth cookies are not left too loose.
Open guideSecurity help for HTTPS, browser hardening, and public-facing trust controls.
Protecting real trust and risk — not just a dashboard score. Fix transport, header, and resource issues before they trigger warnings or incidents.
Weak Security Headers — Missing or Misconfigured Browser Protections
Learn how Scavo checks critical browser security headers, including weak or invalid values, so your live responses are not giving a false sense of protection.
Open guideContent Security Policy (CSP) Missing or Too Permissive
XSS accounts for approximately 20% of reported web vulnerabilities across all industries (OWASP, 2024). A strong CSP is your primary defence — yet only 21.9% of sites have adopted CSP (HTTP Archive, 2025), and 91% of those still include unsafe-inline, making the policy ineffective. Without CSP, a single compromised third-party script or input field can steal user data, inject malware, or deface your site.
Open guideHSTS (HTTP Strict Transport Security) Not Enabled
Only 17.5% of the top 1 million HTTPS websites have HSTS enabled, dropping to just 7% across the entire web (HTTP Archive, 2024). Without HSTS, attackers on the same network can perform SSL stripping — intercepting the initial HTTP request and serving malicious content before your redirect to HTTPS kicks in. This is especially dangerous for users on public Wi-Fi, where these attacks are trivial to execute.
Open guideHTTP to HTTPS Redirect Missing — Security and SEO Risk
Google has used HTTPS as a ranking signal since 2014, and 86.9% of websites now use HTTPS (W3Techs, 2025). If your site doesn't redirect HTTP to HTTPS, visitors land on an unencrypted connection where data can be intercepted. Search engines also treat HTTP and HTTPS as separate URLs, splitting your ranking authority between two versions of every page.
Open guideMixed Content — HTTP Resources Loading on HTTPS Pages
Chrome now automatically blocks mixed content on HTTPS pages — meaning HTTP-loaded scripts and resources simply won't work (Chrome Security, 2024). This breaks page functionality silently: images disappear, styles fail to load, and interactive features stop working. Your users see a degraded experience without understanding why, and search engines flag it as a sign of poor maintenance.
Open guideSSL Certificate Expired or Invalid — How to Fix It
An expired SSL certificate completely blocks visitors — 84% of users will abandon a purchase when they see a browser security warning (SSL.com, 2024). In the Keyfactor 2024 PKI Report, 45% of enterprises experienced downtime from certificate issues, with the average outage costing over $1.1M. Even Google's own Bazel project went down in December 2025 when a cert expired. This is one of the few issues that stops 100% of traffic until fixed.
Open guideAbout security
7 guides
7 active checks
4 sources
Public web security starts before the application code. Browsers make trust decisions from certificates, redirects, headers, and resource hygiene.
A lot of avoidable security pain happens in the delivery layer. If HTTPS is inconsistent, if headers are missing, or if secure pages still pull HTTP resources, browsers and users start from a weaker trust position before they ever interact with your application logic.
This category focuses on the security controls that are easiest to drift and easiest to verify: certificate health, protocol enforcement, mixed content, cookie safety, CSP, HSTS, and the header policies that narrow browser behavior on live pages.
Why it matters
These are user-visible trust signals. Weak transport or header setup can trigger browser warnings, broken functionality, or a very obvious loss of confidence.
They also limit exposure. A tighter browser policy reduces what can go wrong when other bugs or vendor scripts misbehave.
Common pitfalls
Setting header policy at one layer only, then discovering the CDN, load balancer, or app server is overriding it elsewhere.
Deploying CSP in a way that is either too permissive to help or too brittle to survive normal script changes.
What's covered
SSL/TLS certificate presence and expiry so browsers can establish trust without surprises.
HTTPS redirect and HSTS coverage so insecure protocol variants do not stay reachable longer than they should.
Where to start
Lock in the transport layer first: valid certificate, HTTPS redirect, and a clear plan for HSTS rollout.
Then fix the broad header baseline before moving to stricter controls such as CSP tuning.
