# Secure Headers Analyzer > Paste an HTTP response and get a graded breakdown of its security headers, cookie flags, and cross-origin policy, checked against OWASP, RFC 6797, CSP Level 3, and RFC 6265bis. - Tool: https://ronutz.com/en/tools/secure-headers - Family: Security & WAF --- ## What it does Paste a raw HTTP response and the tool grades its security posture: the security headers it sets (and the ones it is missing), the flags on its cookies, and its cross-origin policy. Each finding is checked against the relevant standard and the OWASP Secure Headers recommendations, and the result is a graded breakdown you can act on. It runs entirely in your browser. ## The headers it checks Modern browser security is largely opt-in through response headers, and the tool looks at the ones that matter: - **Strict-Transport-Security** (HSTS, RFC 6797) tells the browser to use HTTPS only; the tool reads its `max-age` and `includeSubDomains`. - **Content-Security-Policy** (CSP Level 3) restricts where scripts, styles, and frames may come from, and is the strongest defense against cross-site scripting; the tool notes weakening keywords like `unsafe-inline`. - **X-Content-Type-Options: nosniff** stops the browser from guessing content types, and **X-Frame-Options** (or CSP `frame-ancestors`) defends against clickjacking. - **Referrer-Policy** and **Permissions-Policy** control what the page leaks in the Referer header and which browser features it may use. - The **cross-origin policies** (COOP, COEP, CORP) that govern isolation between origins. ## Cookies and their flags A cookie's security lives in its attributes, and the tool checks them against the current cookie specification (RFC 6265bis): **Secure** (sent only over HTTPS), **HttpOnly** (hidden from JavaScript, which blunts theft via cross-site scripting), and **SameSite** (which limits cross-site sending and mitigates CSRF). It also recognizes the `__Host-` and `__Secure-` name prefixes, which enforce some of those properties by name. ## Reading the grade The point of the grade is prioritization: it tells you not just what is present but what is missing or weak, and why each header matters, so you can fix the highest-impact gaps first. The checks follow OWASP's recommended set and the underlying specifications rather than one tool's opinion. ## Using it Paste an HTTP response, including its headers, and read the graded analysis of headers, cookies, and cross-origin policy. The analysis is deterministic and local, so it is safe to run on a response captured from any site. ## Standards and references - [OWASP Secure Headers Project](https://owasp.org/www-project-secure-headers/) - the recommended response-header set, recommended values, and rationale - [MDN - HTTP headers reference](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers) - per-header syntax, directives, and browser semantics - [RFC 6797 - HTTP Strict Transport Security (HSTS)](https://www.rfc-editor.org/rfc/rfc6797) - Strict-Transport-Security: max-age, includeSubDomains semantics - [Content Security Policy Level 3 (W3C)](https://www.w3.org/TR/CSP3/) - CSP directives, source expressions, frame-ancestors, the unsafe keywords - [draft-ietf-httpbis-rfc6265bis - HTTP State Management (Cookies)](https://datatracker.ietf.org/doc/draft-ietf-httpbis-rfc6265bis/) - Set-Cookie attributes: Secure, HttpOnly, SameSite, and the __Host-/__Secure- prefixes - [RFC 7034 - HTTP Header Field X-Frame-Options](https://www.rfc-editor.org/rfc/rfc7034) - X-Frame-Options DENY / SAMEORIGIN; ALLOW-FROM is obsolete - [Referrer Policy (W3C)](https://www.w3.org/TR/referrer-policy/) - Referrer-Policy tokens and their referrer-trimming behaviour - [Permissions Policy (W3C)](https://www.w3.org/TR/permissions-policy/) - Permissions-Policy allow-list syntax (successor to Feature-Policy) - [HTML Standard (WHATWG) - Cross-Origin-Opener-Policy](https://html.spec.whatwg.org/multipage/browsers.html) - COOP values (same-origin, same-origin-allow-popups, unsafe-none) - [Fetch Standard (WHATWG)](https://fetch.spec.whatwg.org/) - Cross-Origin-Embedder-Policy and Cross-Origin-Resource-Policy; nosniff MIME checks ## Related reading - [Clickjacking and Frame Control](https://ronutz.com/en/learn/clickjacking-and-framing.md): What clickjacking is, how framing makes it possible, the difference between the legacy X-Frame-Options header and the modern CSP frame-ancestors directive, why ALLOW-FROM is obsolete, and how the two controls interact. - [Content Security Policy, Directive by Directive](https://ronutz.com/en/learn/content-security-policy.md): How CSP works as a control against cross-site scripting and injection: the shape of a policy, why default-src matters, what 'unsafe-inline' and 'unsafe-eval' give away, how nonces and hashes allow specific inline code safely, and what report-only mode is for. - [Cookie Security Flags](https://ronutz.com/en/learn/cookie-security-flags.md): How Secure, HttpOnly, and SameSite protect session cookies, what each SameSite value means, why SameSite=None requires Secure, and how the __Host- and __Secure- prefixes enforce those guarantees at the browser level. - [HSTS and HTTPS Enforcement](https://ronutz.com/en/learn/hsts-and-https.md): How Strict-Transport-Security closes the HTTP downgrade window, what max-age, includeSubDomains, and preload each do, the trust-on-first-use gap that preloading removes, and the configuration mistakes that quietly disable it. - [HTTP Security Headers: The Defense-in-Depth Layer](https://ronutz.com/en/learn/secure-headers-overview.md): What HTTP security headers are, why they form a layer of defense on top of secure code rather than a replacement for it, the headers that carry the most weight, and how to read a response's posture at a glance.