SecOps Toolkit

HTTP Security Headers & CSP Generator

Build, audit, and export hardened HTTP response headers including Content-Security-Policy (CSP Level 3), Strict-Transport-Security (HSTS), and Permissions-Policy. Select your third-party integrations, inspect real-time vulnerability warnings, and copy drop-in configurations for Nginx, Apache, or Cloudflare Workers.

Understanding HTTP Security Headers in Modern Web Architecture

HTTP security headers provide defense-in-depth at the browser layer against Cross-Site Scripting (XSS), Clickjacking, MIME-type confusion, and protocol downgrade attacks. When a web server responds to a client request, these headers instruct the user agent on which origins are trusted to execute code, render frames, or receive form submissions.

1. Content-Security-Policy (CSP) Directives Explained

A properly scoped Content-Security-Policy mitigates the impact of injection vulnerabilities by restricting where scripts, styles, images, and connections can originate:

  • default-src: Acts as the fallback directive for fetch directives that are not explicitly defined (such as script-src, style-src, img-src, connect-src, and font-src). Note that it does not cover base-uri, form-action, or frame-ancestors.
  • script-src: Controls valid sources for JavaScript execution. Avoid using 'unsafe-inline' or 'unsafe-eval' in production environments, as they neutralize XSS protections. Instead, rely on cryptographic nonces ('nonce-RANDOM') or SHA-256/384/512 hashes combined with 'strict-dynamic'.
  • frame-ancestors: Replaces the legacy X-Frame-Options header in modern browsers. Setting frame-ancestors 'none' or 'self' blocks unauthorized external domains from embedding your application inside an <iframe>, preventing UI Redressing (Clickjacking) attacks.
  • object-src 'none': Disables legacy browser plugins (Flash, Java applets, Silverlight) that historically served as common code execution vectors.
  • base-uri 'self': Prevents attackers from injecting a malicious <base> tag into the DOM to hijack relative URLs for scripts and stylesheets.

2. HSTS (HTTP Strict-Transport-Security)

The Strict-Transport-Security header forces browsers to interact with your domain exclusively over HTTPS for a specified duration (max-age in seconds). To qualify for the browser HSTS Preload list (hstspreload.org), your header must specify at least 1 year (max-age=31536000), include the includeSubDomains flag, and append the preload token.

3. Safe Deployment Strategy with Report-Only Mode

Deploying a strict CSP directly to production frequently breaks third-party analytics, payment gateways, or inline tag managers. Always start by deploying the header as Content-Security-Policy-Report-Only. In this mode, the browser logs policy violations to the developer console (and optionally to a reporting endpoint) without blocking any scripts or styles on the live site.

Frequently Asked Questions

Why does the validator warn against 'unsafe-inline' in script-src?
When 'unsafe-inline' is present in script-src, the browser cannot distinguish between legitimate inline scripts written by your developers and malicious scripts injected by an attacker via an XSS vulnerability. To secure inline scripts, generate a unique per-request cryptographic nonce on your server or calculate the SHA-256 hash of the script block.
Do I still need X-Frame-Options if I configure frame-ancestors in CSP?
frame-ancestors is part of CSP Level 2 and supersedes X-Frame-Options in all modern browsers, offering support for multiple allowed origins. However, including X-Frame-Options: SAMEORIGIN (or DENY) alongside frame-ancestors ensures backward compatibility with legacy HTTP clients and automated security scanners.
Why does my CSP break Google AdSense or Google Tag Manager?
Advertising networks and tag managers dynamically load scripts and iframes from multiple regional subdomains and rely on inline execution. Use the Quick Presets tab above to whitelist the core domains, and test your policy using Content-Security-Policy-Report-Only or a nonce-based 'strict-dynamic' configuration.
Can I deliver Content-Security-Policy via an HTML <meta> tag?
Yes, a <meta http-equiv="Content-Security-Policy"> tag works for basic fetch directives on static sites where you cannot modify server headers. However, the W3C specification prohibits frame-ancestors, sandbox, and report-uri inside meta tags, and Report-Only mode is not supported.
What is the recommended Permissions-Policy for a standard web application?
Unless your web app explicitly requires hardware access, disable sensitive browser APIs across all origins by setting Permissions-Policy: camera=(), microphone=(), geolocation=(), payment=(), usb=(). This prevents third-party scripts or embedded iframes from requesting hardware permissions.