WebUtils
EN

Developer Workflow

Check security headers before launching a web app

Review HTTP security headers from curl, browser DevTools, CDN logs, or deployment output before launching a public web app.

Open Security Headers Checker

Problem

Security headers are easy to miss because they are usually added by several layers: application code, framework middleware, CDN rules, reverse proxies, and hosting defaults. A launch can look correct in the browser while HSTS, CSP, nosniff, frame protection, or referrer rules are absent or weaker than expected.

When to use this

  • You are preparing a public web app, API dashboard, documentation site, or admin surface for launch.
  • A CDN, proxy, or hosting migration may have changed headers that used to come from the application.
  • You need a paste-first review because the target URL is private, internal, or not ready for a remote scanner.
  • A pull request changes security middleware and you need a readable before-and-after header summary.

Steps

  1. Step 1

    Capture the deployed response headers

    Run `curl -I` against the deployed page or copy the response headers from browser DevTools, CDN logs, hosting logs, or reverse proxy output. Keep the status line if available.

  2. Step 2

    Paste the raw block into the checker

    Open Security Headers Checker and paste the complete response header block. The tool normalizes names locally and reports detected security headers, missing recommended headers, warnings, and informational findings.

  3. Step 3

    Review transport and framing first

    Check Strict-Transport-Security, frame protection, and Content-Security-Policy signals before reviewing lower-priority isolation or permissions hints.

  4. Step 4

    Follow CSP findings in the CSP analyzer

    If the response includes a long Content-Security-Policy value, open CSP Header Analyzer to inspect directives, source expressions, duplicate directives, and risky source patterns.

  5. Step 5

    Record the result with the release

    Copy the normalized findings into the release checklist or pull request so future middleware, CDN, or framework changes can be compared against the same baseline.

Example

Launch check for a production HTML response

Input

HTTP/2 200
strict-transport-security: max-age=63072000; includeSubDomains; preload
content-security-policy: default-src 'self'; frame-ancestors 'none'
x-content-type-options: nosniff
referrer-policy: strict-origin-when-cross-origin
permissions-policy: camera=(), microphone=(), geolocation=()

Output

Detected security headers: 5
Missing recommended headers: 0
Warnings: 0
Findings: strong HSTS, CSP detected, nosniff detected, frame protection detected, stricter Referrer-Policy detected

Common mistakes

Checking localhost instead of the deployed edge

Local development headers may not include CDN, proxy, or hosting headers. Capture the response from the deployed environment that users will actually reach.

Treating a checker result as a full audit

Header review is one launch check. It does not replace application security testing, dependency review, authentication checks, or threat modeling.

Ignoring where headers are set

The same header can be set by middleware, a framework config, a CDN rule, or a reverse proxy. Fix the layer that owns the deployed response.

FAQ

Can this check a private staging site?

Yes. Copy the headers yourself and paste them into the browser tool. The tool does not need to fetch the private URL or send the header block to a server.

Which headers should I check before launch?

Start with Strict-Transport-Security, Content-Security-Policy, X-Content-Type-Options, frame protection, Referrer-Policy, and Permissions-Policy. Cross-origin isolation headers depend on the application.

Does a clean header report mean the app is secure?

No. A clean report means common response header signals look reasonable. It does not prove the application, dependencies, authentication, or authorization are secure.