HTTP security headers are often treated as a compliance checkbox. But each one exists because of a specific, proven attack technique. When a header is missing, that attack works. Here's what actually happens when your site lacks each critical security header — told from the attacker's perspective.
No Content-Security-Policy: XSS Runs Unchecked
Without a CSP, the browser trusts every script equally. An attacker who finds any injection point — a reflected parameter, a stored comment, even a third-party widget compromise — can execute arbitrary JavaScript in your users' browsers.
What that looks like in practice:
- Keyloggers capturing credentials as users type them into your login form
- Silent redirects to phishing clones of your site
- Cryptocurrency miners running in your visitors' browsers
- Exfiltration of session tokens, personal data, or payment information to attacker-controlled endpoints
A properly configured CSP doesn't just mitigate XSS — it makes most XSS payloads structurally impossible, because the browser refuses to execute scripts that aren't explicitly whitelisted.
No Strict-Transport-Security: SSL Stripping
When HSTS is missing, the very first request a user makes is often over HTTP — before the redirect to HTTPS kicks in. On any untrusted network (coffee shop Wi-Fi, hotel networks, airport hotspots), an attacker running a man-in-the-middle proxy can intercept that initial HTTP request and prevent the redirect from ever happening.
The user sees a normal-looking page. The attacker sees every request in plaintext — login credentials, session tokens, form submissions, everything. This attack, known as SSL stripping, was demonstrated over 15 years ago and still works on every site without HSTS.
No X-Content-Type-Options: MIME Confusion Attacks
Browsers try to be helpful by guessing the content type of a response. Without X-Content-Type-Options: nosniff, an attacker can upload a file with a .jpg extension that contains JavaScript. The browser sniffs the content, decides it's actually a script, and executes it.
This bypasses upload filters, CSP rules that allow image sources, and developer assumptions about file handling. It's a reliable technique for turning a "harmless" file upload into code execution.
No Referrer-Policy: URL Leakage
Without a Referrer-Policy, the browser sends the full URL of the current page as a Referer header on every outbound request. If your URLs contain session tokens, user IDs, internal paths, or search queries, all of that leaks to every third-party resource your page loads — analytics scripts, CDN providers, embedded widgets, and ad networks.
Attackers who compromise any third-party service (or simply run one) can harvest these URLs at scale. Leaked password reset tokens in URLs have been the root cause of multiple high-profile account takeovers.
No Permissions-Policy: Expanded Blast Radius
If your site is compromised — or a third-party script you include goes rogue — the attacker has access to every browser API by default. Camera, microphone, geolocation, payment requests, USB devices. A Permissions-Policy header restricts which APIs are available, limiting what a compromised script can actually do.
Without it, a single XSS vulnerability or supply chain compromise grants access to capabilities your application never intended to use.
The Compounding Problem
These headers don't exist in isolation. Missing multiple headers creates multiplicative risk. No CSP means XSS works. No HSTS means credentials can be intercepted. No Referrer-Policy means tokens leak. An attacker who finds one entry point can leverage the absence of other protections to escalate from a minor issue to full compromise.
The most dangerous aspect is that missing headers produce zero errors, zero warnings, and zero log entries. Your application works perfectly — it's just undefended.
ShieldReport identifies every missing and misconfigured security header on your domain and maps each gap to the specific attack it enables, so you know exactly what you're exposed to and what to prioritise.