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.

Start here

Before You Fix It: What This Check Means

Security headers are browser-level guardrails that reduce exploit surface before app code executes. In plain terms, this checks whether your site sends the main browser security headers and whether the critical ones are set to sensible values, not just present. Scavo looks at two groups of response headers.

Why this matters in practice: weak settings here can increase breach risk and incident blast radius before teams notice.

How to use this result: treat this as directional evidence, not final truth. A crawl snapshot cannot prove every route, subdomain, or transient edge rule is consistently configured. First, confirm the issue in live output: inspect live response headers and certificate state on the exact production host Then ship one controlled change: Capture the final production headers from the real route and environment Scavo tested. Finally, re-scan the same URL to confirm the result improves.

Background sources

TL;DR: This check reviews the browser-facing headers that help stop common web attacks before your application code even gets involved. It does not just ask “is the header there?” It also checks whether key headers are set to values that actually make sense.

That distinction matters. A site can technically send X-Content-Type-Options, X-Frame-Options, or Referrer-Policy and still be too weak, empty, or obsolete to deliver the protection people assume is in place. So this check now treats missing, invalid, and clearly weak critical values as different kinds of problems instead of treating every non-empty header as a pass.

What Scavo checks (plain English)

Scavo looks at two groups of response headers.

Critical baseline headers in this check:

  • X-Frame-Options
  • X-Content-Type-Options
  • Permissions-Policy
  • Referrer-Policy

Recommended hardening headers tracked here:

  • Strict-Transport-Security
  • Content-Security-Policy
  • Cross-Origin-Opener-Policy
  • Cross-Origin-Embedder-Policy
  • Cross-Origin-Resource-Policy

Scavo now checks more than presence for the critical baseline:

  • X-Frame-Options should use a valid protective value such as DENY or SAMEORIGIN
  • X-Content-Type-Options only protects browsers when set to nosniff
  • Referrer-Policy should use a recognized policy, and obviously weak settings are downgraded
  • Permissions-Policy should not be blank if present

How Scavo scores this check:

  • Pass: there are no critical header issues; some recommended headers may still be missing
  • Warning: exactly one critical issue was found (missing, invalid, or weak)
  • Fail: two or more critical issues were found
  • Pass with note: critical headers are sound but one or more recommended hardening headers are still missing

How Scavo scores this check

Scavo assigns one result state for this check on the tested page:

  • Pass: baseline signals for this check were found.
  • Warning: partial coverage or risk signals were found and should be reviewed.
  • Fail: required signals were missing or risky behavior was confirmed.
  • Info: Scavo could not gather enough reliable evidence on this run to score pass/fail confidently.

In your scan report, this appears under What failed / What needs attention / What is working for security_headers, followed by Recommended next steps and Technical evidence (for developers) when needed.

  • Scan key: security_headers
  • Category: SECURITY

Why fixing this matters

These headers are some of the cheapest security wins on the web. They reduce exposure to clickjacking, MIME sniffing, over-sharing of referrer data, and loose browser feature access. They are not a substitute for secure code, but they meaningfully reduce the blast radius of common mistakes.

They also drift easily. One team adds a good header set in application middleware, another adds or removes something at CDN level, and the final response no longer matches what anybody thought was live.

Common reasons this check warns or fails

  • A header exists but uses an obsolete or weak value.
  • A reverse proxy or CDN strips one of the expected headers.
  • Security middleware is enabled on some routes but not others.
  • Production and staging header policies diverged.
  • New infrastructure was launched with only part of the old header baseline copied over.

If you are not technical

  1. Ask for the live response headers from production, not config screenshots.
  2. Ask which system owns the final headers: app, server, reverse proxy, or CDN.
  3. Ask for one source of truth so the same baseline applies everywhere.
  4. Re-run Scavo and confirm the critical issue count drops to zero.

Technical handoff message

Copy and share this with your developer.

Scavo flagged Security Headers (security_headers). Please inspect the live response headers on the affected route, fix any missing or weak critical values (X-Frame-Options, X-Content-Type-Options, Permissions-Policy, Referrer-Policy), and confirm the final production response matches the intended baseline.

If you are technical

  1. Capture the final production headers from the real route and environment Scavo tested.
  2. Fix critical issues first: missing headers, invalid values, or weak policies.
  3. Use X-Frame-Options: DENY or SAMEORIGIN unless you have a very specific framing requirement.
  4. Use X-Content-Type-Options: nosniff exactly.
  5. Use a deliberate Referrer-Policy, typically strict-origin-when-cross-origin unless you have a reason to expose more.
  6. Make Permissions-Policy intentional rather than blank or placeholder-only.
  7. After the baseline is clean, add or improve recommended hardening headers such as CSP and the cross-origin isolation set.

How to verify

  • Run curl -I https://your-url and inspect the final response headers.
  • Confirm critical headers exist and use the expected values.
  • Test representative routes, not just the homepage.
  • Confirm CDN, WAF, and app layers are not fighting each other.
  • Re-run Scavo and verify the critical issue count is zero.

What this scan cannot confirm

  • It does not deeply validate full CSP or HSTS policy quality; those have their own dedicated checks.
  • It does not prove your application code is free from XSS, CSRF, or auth flaws.
  • It cannot see private edge rules or environment-specific routes that were not part of the scan.

Owner checklist

  • [ ] Assign one owner for final browser-security headers.
  • [ ] Keep the baseline header policy version-controlled.
  • [ ] Test headers at the final response layer, not just in framework config.
  • [ ] Revalidate after CDN, WAF, proxy, or platform changes.

FAQ

Because this check prioritizes critical baseline protection first. Missing recommended headers are still useful hardening work, but they do not always mean the basic setup is broken.

Why is a header value important if the header already exists?

Because some headers only work when set to specific values. A present-but-wrong value can create a false sense of safety.

Does this replace CSP and HSTS checks?

No. This is the broad baseline check. CSP and HSTS still need their own deeper validation.

Should every route send exactly the same headers?

Not always, but the security intent should be consistent and documented. Random variation between routes is usually a drift problem, not a design choice.

Sources

Need a single header baseline mapped to your app and CDN layers? Send support one live response and which layer you think currently owns the headers.

Related Guides

More checks in this area

Security cookie_security_flags

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 guide
Security content_security_policy

Content 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 guide
Security hsts

HSTS (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 guide

Raccoon Cookie Checkpoint

Can we use optional cookies?

Essentials always stay on. Optional cookies help with preferences, analytics, and smarter prompts.

Current setting: Decision needed