Security

Header Security Analyzer

Check which security headers a site sends, what each one defends against, and which are now obsolete.

Last reviewed by the Radiatus Cloud team

Need this handled by experts?

Radiatus runs VAPT, managed SOC & security engineering for regulated teams.

Book a free security consult

The headers that matter, in order

Content-Security-Policy is the most powerful and the hardest to deploy: it controls which sources may load scripts, styles, frames and other resources, and it is the primary defence against cross-site scripting. Strict-Transport-Security forces HTTPS for a stated period, closing the window where a first plain-HTTP request can be intercepted. X-Content-Type-Options: nosniff stops browsers second-guessing a declared content type, which prevents a text file being executed as script. Referrer-Policy limits what URL information leaks to third parties. X-Frame-Options, or better the frame-ancestors directive in CSP, blocks clickjacking.

CSP is worth doing properly or not at all

A policy containing unsafe-inline for scripts provides almost no XSS protection, because inline injection is the main attack. The meaningful path is nonces or hashes on legitimate inline scripts and strict-dynamic for loaders. Deploy in report-only mode first and collect violations for a couple of weeks — every non-trivial site discovers dependencies its authors had forgotten. Enforcing an untested policy breaks analytics, embedded video and payment widgets simultaneously.

HSTS has a commitment you cannot undo quickly

The max-age directive tells browsers to refuse plain HTTP for that duration, and they honour it even if your certificate later expires or you need to serve HTTP. Start with a short max-age, confirm nothing breaks, then raise it. The preload list is stronger still — it ships in browsers, applies before any first visit, and removal takes months. Do not add includeSubDomains until every subdomain genuinely serves HTTPS, including ones you forgot about.

Headers that are now noise

X-XSS-Protection controlled a browser auditor that every major browser has removed; it did nothing useful and in some configurations introduced vulnerabilities, so the current advice is to omit it or set it to 0. Public-Key-Pins was deprecated and removed after it caused sites to lock themselves out permanently. Expect-CT is obsolete now that Certificate Transparency is enforced by default. Scanners still flag some of these, and following that advice is a step backwards.

Permissions-Policy limits browser features

Formerly Feature-Policy, it disables APIs the site does not use — camera, microphone, geolocation, payment. Its value is containment: if a third-party script is compromised, it cannot reach a capability the page already surrendered.

Headers do not fix the underlying flaw

They are defence in depth. A strong CSP reduces the impact of an XSS vulnerability; it does not remove it. Input validation, output encoding and current dependencies remain the primary work, and a perfect header score on a scanner says nothing about the application behind it.

Related tools

  • Password Strength Checker — Measure password strength by entropy and pattern analysis rather than character-class rules. Checked entirely in your browser.
  • Password Generator — Generate strong random passwords and passphrases in your browser using the Web Crypto API. Nothing is transmitted, logged or stored.
  • Hash Generator — Generate MD5, SHA-1, SHA-256 and SHA-512 hashes in your browser. Compare checksums and verify file integrity with nothing uploaded to a server.
  • Base64 Encoder/Decoder — Encode and decode Base64 in your browser, including URL-safe Base64 and UTF-8 text. Handles files and data URIs locally with nothing uploaded.

Frequently Asked Questions

Which security headers matter most?

Content-Security-Policy and Strict-Transport-Security do the heavy lifting, followed by X-Content-Type-Options, Referrer-Policy and frame protection through CSP's frame-ancestors.

Why does my CSP not stop XSS?

Almost certainly unsafe-inline for scripts, which permits exactly the injection CSP exists to block. Use nonces or hashes for legitimate inline scripts instead.

How should I roll out CSP?

Report-only first, collecting violations for a couple of weeks. Every non-trivial site finds dependencies its authors had forgotten, and enforcing an untested policy breaks several integrations at once.

Is X-XSS-Protection still needed?

No. Every major browser removed the auditor it controlled, and in some configurations it introduced vulnerabilities. Omit it or set it to 0, whatever older scanners say.

Do security headers fix vulnerabilities?

No, they limit impact. A strong CSP reduces what an XSS flaw can do but does not remove it. Input validation, output encoding and current dependencies remain the primary work.

Privacy & Security

Headers analyzed locally.

Data: None
Client-side-Side
Active
v1.0

About This Tool

This tool runs entirely in your browser. No data is sent to any server, ensuring complete privacy. Simply use the interface above to get started — no registration or login required.

Disclaimer: This tool is provided "as is" without warranty of any kind. Results are for educational and utility purposes.