Developer · THE NO-PANIC PLAN
Review security headers on an authorized site
This is a bounded review of HTTP response headers for a domain you administer or are authorized to assess. Capture the actual response for the relevant route, remove secrets, then inspect the returned values and response context. Nirmion HTTP Header Inspector parses text you provide; it does not contact the site or perform a security scan. Header presence alone does not establish security or compliance, and policy changes such as CSP or HSTS require review and testing by the application's owners.
MISSION Inspect sanitized HTTP response headers from a site the reviewer is authorized to assess, document context-specific findings and verify changes on the same routes.
Inspect response headersTHE REAL-WORLD BIT
What happens outside this browser tab?
Confirm authorization and scope; capture sanitized headers from actual HTTPS responses; parse the values with a local inspector; interpret policies by response type and enforcement mode; then record findings and recheck approved changes on the same routes.
YOUR CHECKLIST, WITH FEWER DRAMATIC SIGHES
One step at a time.
Follow the order below. If a step names a Nirmion tool, its link is right there with it.
- 01
Limit the review to a system you are authorized to inspect
Choose a domain and exact HTTPS page that you own or have explicit permission to review. Write down the host, path, test date, environment and whether the page is production, staging or behind a CDN, because different routes and layers can emit different responses. Do not probe third-party sites, bypass access controls or copy credentials. Security headers are response-level browser instructions, not a complete security assessment: OWASP notes that their relevance depends on the kind of response and how the application works. Define a small question, such as whether the intended document response includes expected controls, before collecting headers. This keeps the review bounded and prevents a parser result from being misrepresented as a penetration test or compliance certificate. (Source 1)
- 02
Capture the actual response from the relevant route
Use browser developer tools' Network panel or an approved command-line client to capture the response headers for the exact page and the final response after redirects. A HEAD request may behave differently from a normal page load, so compare it with the actual GET response when practical. Repeat for representative routes, such as HTML pages and API responses, only when in scope; note differences between staging and production or between CDN and origin. HSTS is meaningful when received over HTTPS; MDN explains that browsers ignore it over insecure HTTP and that includeSubDomains and preload can affect broader hostnames. Before sharing captured text, remove Set-Cookie, authorization tokens, internal hostnames and any sensitive values. (Sources 1, 2)
Evidence:MDN: Strict-Transport-Security - 03
Parse the response headers and mark what needs human review
Paste only the sanitized header block into Nirmion HTTP Header Inspector (tool 172), which parses supplied header values and highlights common security and delivery controls. It does not fetch the site, test exploitability, inspect application behavior or decide that a configuration is safe. Review the actual values and context for Content-Security-Policy, Strict-Transport-Security, X-Content-Type-Options, Referrer-Policy, Permissions-Policy and framing protections rather than counting present names. OWASP describes context-specific use, and HSTS settings can have broad effects; do not blindly copy a recommended value or enable includeSubDomains/preload without checking every affected host and certificate. Save the raw sanitized response, route and date alongside the parser output so another reviewer can reproduce the analysis. (Sources 1, 2, 3)
- 04
Interpret policy modes and response scope correctly
For CSP, distinguish Content-Security-Policy from Content-Security-Policy-Report-Only and inspect every policy instance returned. W3C defines report-only delivery for monitoring; it does not enforce the policy, and multiple enforced policies can combine restrictively. Check whether the response is HTML that executes content or a JSON/API response where a particular browser control may be irrelevant. Compare the observed values with the application's intended behavior, documented architecture and current guidance; do not call an absent header a confirmed vulnerability without explaining its route and threat context. If a policy change is needed, create a reviewed change proposal and test it in a controlled environment with application owners before rollout. (Sources 1, 3, 4)
- 05
Record findings, validate any fix and recheck production
Write a short record with authorized target, route, environment, capture method, sanitized header values, date, expected behavior, observed difference, owner and next action. Separate confirmed observations from risks that need code or infrastructure review. If a team changes configuration, test representative pages, redirects, subdomains and API responses in staging; watch CSP reports and browser behavior before promoting enforcement. Verify the new production response using the same route and method, then retain both before-and-after evidence. Do not treat the HTTP Header Inspector's indicator as a certification, and avoid HSTS preload or broad subdomain policies until the responsible owner has verified TLS and host coverage. OWASP, MDN and W3C describe controls whose effects depend on how browsers process the particular response. (Sources 1, 2, 3, 4)
THE HELPER CREW
Tools for the fiddly bits.
These are the currently published Nirmion tools matched to this guide. Open a tool page for its accepted inputs and limits.
RECEIPTS, PLEASE
Sources & review notes
Each source is linked to the steps it supports. Open it to check its scope and current guidance.
Source checked 2026-10-07