About the HTTP Security Header Grader
The HTTP Security Header Grader parses a pasted HTTP response-header block and returns an A–F grade plus per-header verdicts on Content-Security-Policy, Strict-Transport-Security, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy, Cross-Origin-Opener-Policy, and Cross-Origin-Embedder-Policy. It maps each finding to OWASP ASVS and PCI-DSS 4.0 requirement 6.4, flags weak directives (`unsafe-inline`, missing `nonce`/`hash`, short max-age, `default-src *`), and emits copy-paste fix snippets for nginx, Apache (.htaccess), Express.js, and Cloudflare Workers.
It is built for developers hardening a site before launch, security engineers auditing inherited applications, agencies running quarterly client-domain checks, and platform teams enforcing header standards across many services. The CSP analyzer is the centerpiece — CSP is the single highest-leverage browser-side XSS mitigation, and the grader is opinionated about what a strict policy looks like.
All parsing and grading runs locally in JavaScript. The pasted headers, your origin URL (if you include it in the dump), and any internal hostnames in your CSP source list never leave the device. The tool does not fetch your site — you control what data the analyzer sees, which matters for staging and internal-only deployments.
Header grades are necessary but not sufficient: a perfect score does not mean the application is secure. The grader checks presence and strength of directives, not the underlying code — an XSS-vulnerable endpoint with a perfect CSP can still be exploited if the policy allows `unsafe-inline` anywhere. Headers also need to be verified at the actual production edge, since CDN response-header rules can override what your origin emits. Re-run the grader against `curl -I https://yourdomain.com` output after every deploy.
Browser: Open DevTools (F12) → Network tab → reload the page → click the first request → copy the Response Headers section.
Terminal: Run
curl -I https://yoursite.com and paste the full output below.
Why HTTP Security Headers Matter
HTTP security headers are your first line of defense against a wide range of web attacks. They are directives sent by your server that instruct browsers how to behave when handling your site’s content. Without them, browsers fall back to permissive default behaviors that leave your users vulnerable to cross-site scripting (XSS), clickjacking, MIME-type sniffing attacks, man-in-the-middle interception, and data exfiltration. Major security frameworks including OWASP, PCI-DSS, and HIPAA all require or strongly recommend specific HTTP security headers as part of a compliant web application deployment. Configuring these headers correctly costs nothing — they are simple server configuration directives — yet a surprising number of production websites ship without them or with misconfigured values that provide a false sense of security.
Content-Security-Policy: Your XSS Shield
CSP is the single most important security header. It defines an allowlist of content sources
the browser may load, blocking injected scripts from attacker-controlled servers. A
comprehensive policy covers script-src, style-src,
img-src, font-src, connect-src,
frame-ancestors, and a default-src fallback. The
report-to directive sends violation reports to a URL you control for monitoring.
Use Content-Security-Policy-Report-Only to audit a policy before enforcing it,
which is essential for rollout on sites with inline scripts or third-party dependencies.
Strict-Transport-Security and the HTTPS Guarantee
HSTS tells browsers to only connect to your site over HTTPS, even if a user types
http:// or clicks an HTTP link. This prevents SSL-stripping attacks where an
attacker intercepts the initial HTTP request before the HTTPS redirect. The
max-age directive (recommended: 31536000, one year) controls how
long browsers enforce HTTPS. Adding includeSubDomains covers all subdomains,
and preload qualifies your domain for browser HSTS preload lists —
hardcoded into browser builds so even the first connection uses HTTPS.
Clickjacking, MIME Sniffing, and Other Headers
Clickjacking is an attack where a malicious page embeds your site in a transparent iframe and
tricks users into clicking on hidden elements. X-Frame-Options prevents this by
controlling iframe embedding — DENY blocks all framing while
SAMEORIGIN allows only same-origin frames. Although CSP frame-ancestors
provides more granular control, X-Frame-Options remains important for backward
compatibility. X-Content-Type-Options: nosniff prevents browsers from guessing
MIME types, blocking attacks where files with misleading extensions get executed as active
content. Referrer-Policy controls how much URL information leaks to third-party
sites — the recommended strict-origin-when-cross-origin sends full URLs
for same-origin requests but only the origin for cross-origin ones.
Permissions-Policy lets you disable unused browser APIs like camera, microphone,
and geolocation, reducing your attack surface if the site is compromised.
Cookie Security Flags
Cookie attributes set via Set-Cookie are critical security controls.
Secure ensures cookies are only sent over HTTPS, HttpOnly prevents
JavaScript access (blocking XSS-based session theft), and SameSite controls
cross-site cookie transmission for CSRF protection. Use SameSite=Lax for session
cookies or SameSite=Strict for maximum security. All three flags should be set
on every sensitive cookie, especially session identifiers and authentication tokens.
Grading Methodology
This tool evaluates eight categories with a weighted scoring system: CSP (25%), HSTS (20%), X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy, and cookie flags (10% each), plus additional cross-origin headers (5%). Each category receives a grade from A through F, and the overall score maps to a composite letter grade where A requires 90 or above. Use the Hash Generator to verify file integrity after downloading configurations, or the Base64 & Encoding Toolkit to decode encoded header values.
Frequently Asked Questions
What is Content-Security-Policy and why does it matter?
Content-Security-Policy (CSP, defined in W3C CSP Level 3) is an HTTP header that restricts which sources a page can load scripts, styles, fonts, and frames from. A strict CSP is the single most effective browser-side mitigation against cross-site scripting (XSS), which is one of the OWASP Top 10 risks.
Should I use Strict-Transport-Security with preload?
HSTS (RFC 6797) tells browsers to only contact your site over HTTPS. Adding preload submits your domain to the Chrome HSTS preload list, bundled into all major browsers, so the very first visit is also HTTPS. Only preload once you are certain every subdomain supports TLS, because removal can take weeks.
What does X-Frame-Options do and is it still needed?
X-Frame-Options prevents clickjacking by blocking your site from being embedded in an iframe on another origin. Modern browsers also respect the frame-ancestors directive in CSP, which is strictly more flexible. Setting both is safe and covers older clients.
Are HTTP security headers part of PCI-DSS compliance?
Yes. PCI-DSS 4.0 requirement 6.4 and OWASP ASVS mandate protections that CSP, HSTS, and X-Content-Type-Options directly address. Auditors routinely check for these headers as evidence of a secure deployment.
Can I set these headers without touching my server config?
Yes. You can add them at the CDN edge using Cloudflare Transform Rules, AWS CloudFront Response Headers Policies, or Vercel/Netlify header files. This is useful when you have limited access to the origin server.
