Security Headers Analyzer

Understand the current analyzer before trusting the grade

This security headers analyzer currently renders a demonstration checklist; it does not inspect the URL in the field. For every nonempty value, the component assigns grade A and displays Content Security Policy, Strict-Transport-Security, X-Content-Type-Options, and X-Frame-Options as configured, with Referrer-Policy marked missing. Clearing the field removes the grade and list.

No request is sent to GitHub, the entered website, a DevsTool backend, or a scanning API. There is no fetch call, URL validation, redirect traversal, TLS check, or response-header parser. The default https://github.com is sample text, and the output is fixed React state. Do not cite this grade as a live security assessment, compliance artifact, or evidence that a deployment has those headers.

The useful role of the page today is educational: it names five important response-header families and provides a visual checklist format. The sections below explain how to assess those controls accurately with real response data.

A header review is response-specific

Security headers are delivered in HTTP responses. A policy seen on / may be absent from /login, an error generated by a CDN, a static asset host, or an API response. Redirects have their own headers, and a final page can pass through several origins. A meaningful review records the exact URL, method, status code, redirect chain, timestamp, and network vantage point.

Use browser DevTools on an authorized site or retrieve headers with an HTTP client:

curl -sS -D - -o /dev/null https://example.com/

Inspect without -L first so a redirect does not hide the initial response. Then follow redirects deliberately and examine each block. A HEAD request via curl -I is convenient, but some applications treat HEAD differently; GET with the body discarded better matches normal navigation.

Content Security Policy: evaluate directives, not presence

Content-Security-Policy restricts where documents can load and execute resources. A plausible starting policy might be:

Content-Security-Policy: default-src 'self'; script-src 'self' 'nonce-random'; object-src 'none'; base-uri 'self'; frame-ancestors 'none'

Simply finding a CSP field is insufficient. default-src * 'unsafe-inline' 'unsafe-eval' offers little script protection. Review script-src, nonces or hashes, object-src, base-uri, frame-ancestors, form destinations, mixed-content directives, and fallbacks. Confirm that each response receives a fresh unpredictable nonce if nonces are used.

Content-Security-Policy-Report-Only collects violations without enforcing them. It is valuable during rollout but should not be scored as equivalent to enforcement. Reports can contain sensitive URLs and should be sent to a controlled endpoint with retention and access policies.

CSP is defense in depth, not permission to leave injection flaws unfixed. Test application behavior, eliminate unsafe patterns, and monitor violations rather than chasing a superficial grade.

HSTS: only meaningful over HTTPS

Strict-Transport-Security tells a browser to use HTTPS for future requests to a host. A common value is:

Strict-Transport-Security: max-age=31536000; includeSubDomains

Browsers ignore HSTS received over insecure HTTP. Check the HTTPS response, ensure max-age fits the rollout plan, and confirm every covered subdomain supports HTTPS before adding includeSubDomains. The preload token alone does not place a domain on browser preload lists; submission and eligibility steps are separate.

Long-lived HSTS can cause outages if certificates or HTTPS service fail, especially with includeSubDomains. Roll out cautiously, inventory legacy hosts, automate certificate renewal, and understand recovery constraints. Presence is not automatically “good” without those operational prerequisites.

MIME-sniffing and framing defenses

X-Content-Type-Options: nosniff asks browsers not to reinterpret certain resources as a different MIME type. Pair it with correct Content-Type values. It will not repair a server that labels CSS, JavaScript, fonts, or downloads incorrectly; strict MIME enforcement may expose those mistakes.

X-Frame-Options: DENY prevents framing, while SAMEORIGIN allows same-origin frames in supporting browsers. CSP frame-ancestors is the modern, more expressive mechanism and can name permitted origins. Deploy compatible policies where legacy support matters. The obsolete ALLOW-FROM directive has inconsistent support and should not be the foundation of a new configuration.

Framing controls reduce clickjacking risk for documents. They do not govern outbound frames loaded by the page; CSP frame-src addresses that different direction. They also do not replace CSRF protections, authorization, or confirmation for sensitive actions.

Referrer-Policy is a data-flow decision

Referrer-Policy controls how much source URL information accompanies navigation and subresource requests. strict-origin-when-cross-origin is a common balance: same-origin requests receive the full referrer, secure cross-origin requests receive the origin, and HTTPS-to-HTTP downgrades receive none. no-referrer is stricter, while unsafe-url can disclose paths and query strings broadly.

Choose a policy after checking analytics, federated login, payment flows, partner integrations, and URL design. Secrets should never be placed in URLs regardless of policy. A missing Referrer-Policy does not necessarily mean full URLs are always leaked because browsers have defaults, but an explicit field makes intended behavior clearer and more stable.

Important controls beyond the sample five

Permissions-Policy can limit features such as camera, microphone, geolocation, and fullscreen for the document and embedded contexts. It needs application-specific design; disabling a required feature is not a security win.

Cross-origin isolation involves Cross-Origin-Opener-Policy, Cross-Origin-Embedder-Policy, and sometimes Cross-Origin-Resource-Policy. These can unlock capabilities such as SharedArrayBuffer while isolating browsing contexts, but they affect popups, OAuth, embedded resources, and third-party integrations. Test before deployment.

Cookie security is evaluated on each Set-Cookie: consider Secure, HttpOnly, SameSite, scope, prefixes, lifetime, and partitioning where applicable. The fixed demonstration does not inspect cookies. CORS response fields are also not a generic security score; they must be judged against which origins, methods, headers, and credentials an API intends to permit.

Headers such as X-XSS-Protection, Public-Key-Pins, and Expect-CT are obsolete or superseded in modern deployment guidance. More headers do not inherently mean better protection. Correct, tested controls that match the application are preferable to copying a long template.

A release-review playbook

First inventory response classes: HTML documents, authenticated pages, APIs, redirects, errors, static resources, uploads, and alternate hostnames. Capture real headers for representative URLs at the origin and through the production CDN. Compare them because reverse proxies often add or remove policy.

Next inspect values semantically. For CSP, use browser violation reporting and exercise application flows. For HSTS, test certificate automation and every included subdomain. Attempt authorized framing tests for sensitive pages. Verify MIME declarations while nosniff is active. Follow cross-origin and referrer-dependent workflows.

Then test failure paths. A custom 404 may have the normal policy while a proxy-generated 502 does not. Authentication redirects can cross origins. Cached responses may retain an old header set after deployment. Document expected policy in automated integration tests and periodically validate production from more than one edge location.

Finally, classify findings by exploitability and coverage rather than letter grade. A weak CSP with a green badge can be less useful than no CSP accompanied by strong contextual encoding and Trusted Types work in progress. A grade is a communication aid, not a threat model.

Privacy and authorization

Entering a URL here does not contact it because the component is static. Even so, avoid pasting signed URLs, reset tokens, internal hostnames, or customer identifiers into browser tools. URLs can leak through unrelated browser features, extensions, screen sharing, and general site telemetry.

When using curl or DevTools for the real assessment, restrict testing to systems you own or have permission to review. Header retrieval creates traffic and logs. Do not attempt authentication bypass, injection, framing of third-party accounts, or automated crawling without explicit scope.

Sanitize captured output before sharing. Set-Cookie, correlation IDs, server names, internal routes, CSP report endpoints, and location headers may reveal operational or personal information. Store security evidence according to organizational policy.

Why the visible result never changes

Typing another nonempty URL triggers the same effect and reconstructs the same five rows. The grade always becomes A, not A+, despite the initial state being initialized to A+ before the effect runs. There is no Scan button behavior, loading indicator, error handling, or clipboard action in the rendered interface. Imported icons and button code do not create network functionality.

If you see the five checks, that means only that the input string is nonempty. If you see nothing, the field is empty. Use real response inspection for every other conclusion.

Security-header questions

Is an A grade from this page valid for my domain?

No. The A is hard-coded demonstration behavior and independent of the domain.

Does the tool expose an internal URL to the target?

No component request occurs. Still avoid sensitive strings because broader browser and site behavior is outside this narrow logic.

Should every response use the same CSP?

Not necessarily. HTML applications, APIs, and static resources have different needs, but all relevant documents should receive a deliberate policy. Avoid accidental gaps on errors and alternate routes.

Can HSTS fix an invalid certificate?

No. It forces HTTPS use and generally makes bypass harder. Certificate validity, hostname coverage, trust, and renewal must already work.

Is CORS a security header like CSP?

CORS controls which browser origins may read responses; it is not authentication or a firewall. Its correctness depends on the API’s intended trust model, especially when credentials are allowed.

Why might an external scanner and DevTools disagree?

They may use different locations, IP versions, request headers, cookies, user agents, methods, redirect behavior, CDN edges, or authenticated state. Compare identical transactions before treating either as wrong.