Security headers and trust boundaries

Review response declarations, not a security grade

This tool explains a bounded set of security-related response fields that you supply. It does not contact the target, test authentication or rate the safety of a website. Copy one response header block from browser developer tools or a trusted capture, preserve repeated fields and remove unrelated secrets first. The analysis runs locally in the already loaded document. Unknown fields are counted and discarded from results; the pasted input stays in page memory until Clear, reload or a page lifecycle transition removes it. Edits invalidate previous results.

Keep separate Content Security Policies separate

Several enforcing CSP policies apply together; a later field is not a replacement for an earlier restrictive policy. Report-only declarations are listed separately and do not count as enforcing blocking. Within an individual policy, a repeated directive keeps its first declaration. The review records recognized directive names, duplicates, script-element and script-attribute fallback choices, and selected token patterns. It does not validate every source expression, nonce, hash or browser extension. A displayed unsafe-inline token is therefore a review flag, not a claim that an inline script can actually run.

Interpret transport and framing context carefully

Select whether the supplied response arrived over HTTPS, HTTP or an unknown transport. HSTS is only processed over secure transport, and its first separate field controls the declaration. A zero max-age requests removal of dynamically learned state; a preload token does not establish membership of a browser preload list. This tool cannot inspect certificate trust or cached ancestor policies. Framing observations distinguish DENY and SAMEORIGIN from conflicting or obsolete values, and flag when an enforcing CSP declares frame-ancestors. That flag still does not validate the ancestor source list or test an actual frame.

Avoid conflating cross-origin declarations with successful access

The inspector recognizes bare COOP, COEP and CORP tokens. Parameterized forms are explicitly not evaluated in this version instead of being guessed valid or invalid. Report-only fields are monitoring evidence, and no combination of copied headers proves crossOriginIsolated in a live context. Access-Control-Allow-Origin and Allow-Credentials receive syntax observations, including the credentialed-wildcard incompatibility and the special null origin. A complete CORS check also needs the requesting origin, credentials mode, method and other response or preflight details. CORS is not authentication and does not necessarily prevent sending a request.

Read statuses and preserved uncertainty

Analysed means the input fit this diagnostic profile; it is not a security PASS. Invalid means a particular declaration did not fit the recognized syntax. Not observed means the field was absent from the supplied block, not that a browser or application has no protection. Partial marks an explicitly unevaluated form, such as a parameterized cross-origin policy. Nosniff uses its first member, whereas Referrer-Policy selects the last recognized member. Browser defaults, element attributes, document meta policies, protected responses and other captures can change the application behavior and require separate inspection.

Limits, local processing and evidence export

Input is limited to 32 KiB, 128 field lines and 8192 characters per line. One optional HTTP status line is accepted; folded fields, HTTP/2 pseudoheaders, non-ASCII captures, bodies and multiple response blocks are rejected. CSP processing is capped at sixteen supplied policies, sixty-four directive segments per policy and 128 source tokens per directive. Overflow is rejected rather than silently truncated. There are no processing requests, telemetry calls, storage writes or clipboard reads. An explicit JSON export contains enumerated findings and bounded counts or parameters, never raw header blocks, cookies, credentials, nonce values or hostnames. Exported evidence remains user-supplied and unverified.

Method references and related tools

W3C Content Security Policy, RFC 6797 HSTS, Referrer Policy, and the WHATWG HTML and Fetch specifications define the underlying browser mechanisms. This diagnostic covers a bounded structural subset, not full conformance.

Cookie policy inspection · All tools · Overall measurement methodology