Check a site's security headers and CSP RAMPART

Why paste the headers instead of typing an address

A header-scanning website fetches the page from its own servers. That only works for a page on the public internet, and it tells the scanner, and whoever it shares its logs with, which address you were looking at. The pages whose headers matter most are usually the ones it cannot reach: the staging copy before launch, the internal admin panel, the application behind a login, the client's system you are testing under an agreement that says the findings stay private.

Headers are text. The server has already sent them to you. Reading them here means the audit covers exactly the response you have, from wherever you got it, and nothing about the site is sent anywhere.

What it checks, and how carefully

• Content-Security-Policy, the way a browser reads it. Most mistakes in a policy are silent: a missing semicolon turns the next directive into a host name, self without its quotes is a host called self, and a directive written twice keeps only its first copy. Each of those is found rather than trusted. Then the script policy is judged for what it actually lets run: inline script, eval, any host, data:, and hosts where anybody can publish a script or which serve something known to get round an allowlist. A nonce or hash with 'strict-dynamic' is recognised as the strong form it is, and 'unsafe-inline' beside a nonce is recognised as ignored.
• Strict-Transport-Security. Whether it is valid, whether the period is long enough to matter, and whether a site asking for the browsers' preload list would actually be accepted onto it.
• Framing. X-Frame-Options and frame-ancestors together, because the second overrides the first, and because ALLOW-FROM looks like protection and is ignored.
• Cookies. Secure, HttpOnly and SameSite on each one, the __Host- and __Secure- prefixes whose rules a browser enforces by quietly dropping the cookie, and a shared cache told it may keep a response that sets one.
• Cross-origin reads. Access-Control-Allow-Origin: null, and the wildcard-with-credentials pair browsers refuse, which tends to get "fixed" by echoing any origin back.
• The rest. X-Content-Type-Options, Referrer-Policy, Permissions-Policy, Cross-Origin-Opener-Policy, headers that name the server's software and version, and retired headers that do nothing now.

What one response cannot tell you

Headers are a promise about what the browser should do, not proof the application is safe. A strong policy on the login page says nothing about the headers on the API behind it, so check the responses that matter, not only the home page. Whether a server copies back any Origin it is sent shows up only by sending it one, and the page says how when it matters. There is no letter grade here, because a grade adds up things that are not the same size: a missing header on a static brochure and inline script allowed on a banking page do not belong on one scale.

For the certificate the site presents, CERTLENS takes it apart. For a token in one of these cookies, JOT reads it. For a copy of the traffic itself, WIRE reads a packet capture and INTERCEPT cleans the secrets out of one before it is shared.