Security Header Checker

HTTP security headers tell browsers how to handle risky behavior such as framing, mixed content, content injection, cross-origin access, and transport security. Missing headers do not prove a site is vulnerable, but they often show where browser-side protections have not been configured.

• Headers such as Content-Security-Policy, Strict-Transport-Security, X-Frame-Options, Referrer-Policy, and Permissions-Policy can reduce exposure from common browser attack paths.
• Weak or inconsistent headers can appear after CDN, proxy, framework, or deployment changes.
• Header checks are fast configuration checks that help teams catch drift before a manual review or release signoff.

• Requests the target URL and records the response headers returned by the origin, CDN, or edge layer.
• Checks for the presence of common browser security headers and flags values that are missing, empty, contradictory, or obviously weak.
• Reports the endpoint and observed header value so a developer can compare the finding with the intended application or CDN policy.
• This is a basic external scan. It does not replace manual testing of application flows, exploitability, or business logic.

• No Content-Security-Policy header on public HTML responses.
• Strict-Transport-Security missing on HTTPS responses.
• X-Frame-Options or frame-ancestors not configured for pages that should not be embedded.
• Referrer-Policy left to browser defaults.
• Permissions-Policy missing for features the site does not use.

• Define the intended header policy at the application, reverse proxy, CDN, or hosting platform layer.
• Start with report-only CSP if the application has many third-party scripts, then tighten the policy after reviewing reports.
• Serve HSTS only on HTTPS and include subdomains only when every required subdomain is ready for HTTPS.
• Apply headers consistently to HTML responses and avoid conflicting policies from multiple edge layers.