Skip to main contentSkip to navigation

Security Headers Analyzer

Analyze HTTP response headers for security best practices

HTTP Response Headers

Paste raw response headers (from your server, curl -I, or browser devtools).

Analysis

HSTS
Header not present
Forces HTTPS and protects against protocol downgrade attacks.
CSP
Header not present
Mitigates XSS by whitelisting sources.
X-Frame-Options
Header not present
Prevents clickjacking in iframes.
X-Content-Type-Options
Header not present
Prevents MIME sniffing.
Referrer-Policy
Header not present
Controls referer leakage.
Permissions-Policy
Header not present
Restricts powerful browser features.
COOP
Header not present
Isolates browsing context for security.
COEP
Header not present
Required for certain isolation models.
CORP
Header not present
Restricts cross-origin resource loading.

Security Headers Analyzer - Check HTTP Response Headers

HTTP security headers serve as the first line of defense against web vulnerabilities, instructing browsers to enforce security policies that protect users from XSS, clickjacking, MITM attacks, and data exfiltration. This analyzer evaluates your site's response headers against security best practices, identifies missing protections, and provides actionable recommendations to harden your web application. Proper security header configuration is essential for compliance, user trust, and defense against evolving web threats.

Essential security headers and their protection mechanisms

Content-Security-Policy (CSP) prevents XSS by controlling resource loading sources and inline script execution. Strict-Transport-Security (HSTS) enforces HTTPS connections and prevents protocol downgrade attacks. X-Frame-Options and frame-ancestors directive prevent clickjacking by controlling iframe embedding. X-Content-Type-Options prevents MIME type sniffing attacks. Referrer-Policy controls information leakage in HTTP referrer headers. Permissions-Policy restricts access to browser APIs like camera, microphone, and geolocation. These headers work together to create defense-in-depth protection against common attack vectors.

Content Security Policy: advanced configuration and best practices

CSP requires careful configuration to balance security with functionality. Start with a restrictive policy like 'default-src self; img-src self data:; style-src self unsafe-inline; script-src self' and gradually relax as needed. Use nonces or hashes for inline scripts rather than 'unsafe-inline'. Implement CSP gradually: start with report-only mode to identify violations, fix compatibility issues, then enforce. Monitor CSP reports to detect both attacks and misconfigurations. For complex applications, consider multiple CSP policies for different page types or use strict-dynamic for better script security with less maintenance overhead.

HSTS implementation and subdomain considerations

HSTS headers prevent SSL stripping attacks by forcing browsers to use HTTPS for future connections. Implement with appropriate max-age values: start with shorter durations (weeks) for testing, then increase to months or years for production. Include 'includeSubDomains' directive to protect all subdomains, but ensure all subdomains support HTTPS first. Consider 'preload' directive for inclusion in browser preload lists, providing protection on first visit. Remember that HSTS is 'sticky'—browsers remember the policy even after header removal, so test thoroughly before deployment.

Common security header pitfalls and troubleshooting

Overly permissive CSP policies (script-src '*' or unsafe-eval) negate security benefits. Missing HSTS on login pages leaves authentication vulnerable to downgrade attacks. Incorrect X-Frame-Options configuration can break legitimate iframe usage or fail to prevent clickjacking. Conflicting headers (both X-Frame-Options and CSP frame-ancestors) can cause unexpected behavior. Always test headers across different browsers and user flows. Use browser developer tools to identify CSP violations, validate HSTS effectiveness, and ensure headers are present on all sensitive pages.

Security headers for API endpoints and SPAs

APIs need different security header configurations than traditional web pages. CORS headers control cross-origin access for APIs, while CSP may be less relevant for JSON endpoints. Single-page applications require careful CSP configuration to allow dynamic content loading while preventing XSS. Consider headers like Cross-Origin-Embedder-Policy and Cross-Origin-Opener-Policy for enhanced isolation. API gateways and CDNs should preserve security headers from origin servers. Implement security headers consistently across all environments (development, staging, production) to catch configuration issues early.

Monitoring, compliance, and header management at scale

Implement security header monitoring using tools like Security Headers, Observatory by Mozilla, or automated scanning in CI/CD pipelines. Log CSP violations and HSTS reports to detect attacks and misconfigurations. For large applications, use configuration management tools to ensure consistent header deployment across servers. Consider security header policies as code, version-controlled alongside application code. Regular audits should verify header effectiveness, check for header drift, and evaluate new security header standards. Compliance frameworks (SOC 2, PCI DSS) often require security header implementation as part of security controls.

Further reading

Security headers provide essential protection against web vulnerabilities with minimal performance impact. Implement progressively, monitor violations, test thoroughly across browsers and user flows, and maintain policies as your application evolves. Regular security header audits should be part of your security maintenance routine.