OWASP Security Headers Checker & Scanner
Audit CSP, HSTS, X-Frame-Options, X-Content-Type-Options, and Referrer-Policy headers to eliminate XSS, clickjacking, and MITM vulnerabilities.
Technical Deep-Dive: HTTP Security Headers Explained
📌 On this page
1. How this scanner actually works
The scan performs a single server-side HTTP request to the URL you submit (protected by SSRF allowlisting against private IPs, loopback addresses, and cloud metadata endpoints), then reads the raw response headers directly — no browser rendering, no JavaScript execution, just a straightforward inspection of what your server actually sent back. This means the results reflect exactly what a real visitor's browser receives on that specific page; headers set only on certain page templates (a common WordPress misconfiguration) will show as missing if the scanned URL isn't one of those templates.
2. Content-Security-Policy in depth
CSP works by explicitly declaring, in a single header value, which sources are trusted for each resource type — scripts, styles, images, fonts, frames, and more — and the browser refuses to load or execute anything from a source not on that list. This is a fundamentally different defense model from input sanitization: even if an attacker successfully injects a malicious <script src="evil.com/x.js"> tag into your page through some other vulnerability, a properly configured CSP will refuse to execute it because evil.com is not an allowlisted script source, containing the damage even after the initial flaw exists.
3. HSTS and the SSL-stripping attack it prevents
Without HSTS, a user who types "example.com" (no protocol) or clicks an old http:// link makes their first request over plain, unencrypted HTTP before any redirect to HTTPS occurs — and on an untrusted network (public WiFi, a compromised router), an attacker positioned in the middle can intercept that initial plaintext request and simply never let the redirect to HTTPS happen, silently downgrading the entire session (a technique called SSL stripping). HSTS closes this gap: once a browser has seen the header once, it refuses to ever make a plain-HTTP request to that domain again for the specified max-age duration, eliminating the vulnerable window entirely on repeat visits.
4. Clickjacking and X-Frame-Options
A clickjacking attack embeds your site inside an invisible <iframe> on an attacker-controlled page, then overlays deceptive content (a fake "Play Video" button, for example) precisely aligned over a real, sensitive button on your embedded site — a user believes they're clicking the visible fake button but is actually clicking a hidden real one (a "Delete Account" or "Confirm Purchase" button, for instance). X-Frame-Options: SAMEORIGIN instructs browsers to refuse to render the page inside a frame on any other origin, closing off this entire attack class. The modern CSP frame-ancestors directive provides equivalent (and more flexible) protection and is gradually superseding X-Frame-Options.
5. MIME sniffing and X-Content-Type-Options
Some older browser behaviors "sniff" the actual content of a downloaded file to guess its type, rather than trusting the server's declared Content-Type header — meaning a file uploaded as an "image" that actually contains executable script code could, in vulnerable configurations, be interpreted and run as a script rather than displayed as a broken image. X-Content-Type-Options: nosniff disables this guessing behavior entirely, forcing the browser to strictly respect the declared Content-Type — a small header with an outsized defensive payoff for any site that accepts user-uploaded files (avatars, media library uploads, form attachments).
6. A safe rollout plan for WordPress
Start with the lower-risk headers — X-Content-Type-Options, X-Frame-Options, and Referrer-Policy — which are extremely unlikely to break anything and can be deployed immediately. Add HSTS next, but only once you have confirmed HTTPS works flawlessly site-wide (HSTS with a long max-age is difficult to reverse if you later need to serve any page over plain HTTP). Save CSP for last and always start in Content-Security-Policy-Report-Only mode, testing across every page template your theme and plugins render, before switching to full enforcement — this single header is responsible for the overwhelming majority of "why did my site just break" incidents when security headers are added carelessly.
Frequently Asked Questions
Why are HTTP security headers critical for web applications?
Security headers act as defense-in-depth security directives. They instruct modern web browsers to restrict script execution origins (CSP), prevent clickjacking in iframes (X-Frame-Options), block MIME sniffing attacks (nosniff), and enforce HTTPS connections (HSTS).
What happens if a website lacks a Content-Security-Policy (CSP)?
Without a CSP, if an attacker finds an input sanitization flaw (XSS), their injected malicious script can execute freely, steal session cookies, or redirect visitors to credential harvesting phishing sites.
How can I add these security headers to WordPress?
You can inject security headers via your web server configuration (.htaccess for Apache/LiteSpeed, nginx.conf for Nginx), Cloudflare Transform Rules, or via security plugins like Wordfence or WPCode.
Does this tool enforce SSRF security checks?
Yes. All live audits enforce strict SSRF safeguards, blocking requests to private networks, loopbacks, and cloud metadata IPs.
How is the letter grade (A+ through F) actually calculated?
The grade is derived from a straightforward weighted point system out of 100: Content-Security-Policy contributes 30 points, Strict-Transport-Security 25 points, X-Frame-Options and X-Content-Type-Options 15 points each, Referrer-Policy 10 points, and Permissions-Policy 5 points — reflecting each header's relative importance to overall security posture (CSP and HSTS carry the most weight since they defend against the highest-impact attack classes, XSS and SSL stripping/MITM respectively). A+ requires 95+, A requires 80+, B requires 65+, C requires 50+, D requires 30+, and anything below is an F.
Can adding a Content-Security-Policy break my WordPress site?
Yes, and this is the most common mistake when hardening headers. A restrictive CSP that does not explicitly allowlist your active theme's inline scripts, Google Fonts, Google Analytics, embedded YouTube videos, or third-party plugin scripts (page builders, chat widgets, payment processors) will silently block them, breaking layout or functionality with no visible error to visitors. Always deploy a new CSP in Content-Security-Policy-Report-Only mode first, review the browser console for blocked-resource warnings across every page template, then switch to enforcing mode once you have confirmed nothing legitimate is blocked.
Do these headers need to be set at the server level, or can a plugin do it?
Both approaches work, with different tradeoffs. Setting headers via .htaccess, nginx.conf, or a CDN edge rule (like a Cloudflare Transform Rule) applies them at the network/server layer before WordPress even loads, which is faster and more resilient (a broken PHP execution still returns the headers). A WordPress plugin setting headers via the send_headers hook works but only applies to WordPress-generated responses — it will not add headers to static assets served directly by the web server, and adds a small amount of PHP execution overhead per request compared to a server-level rule.