Security

Security Headers Generator

Create security header configurations to protect your web application. From Content Security Policy to HSTS, generate ready-to-use code for your server.

⚡Instant🔒In your browser✓No signup
Live
    View as text

    Content-Security-Policy: first line of defense against XSS

    Content-Security-Policy (CSP) is the most powerful and complex header. It defines where your page can load resources from (scripts, styles, images, fonts). Basic example: default-src 'self' only allows resources from the same origin. To allow specific CDNs: script-src 'self' https://cdn.example.com. The most common mistake is using 'unsafe-inline' and 'unsafe-eval', which eliminate much of the XSS protection.

    Recommended strategy: start with CSP-Report-Only during development to see what breaks without blocking anything. Monitor reports (configure report-uri /csp-endpoint) and adjust directives until there are no legitimate violations. Then switch to Content-Security-Policy enforcement. For sites with legacy inline scripts/styles, use nonces: generate a random token per request and add it as nonce="random123" attribute to each <script>, allowing it with script-src 'nonce-random123'.

    Critical directives: default-src (fallback for everything), script-src (where to load JS from), style-src (CSS), img-src (images), connect-src (fetch/XHR/WebSocket), frame-ancestors (who can embed your page in iframe, replaces X-Frame-Options), upgrade-insecure-requests (auto-upgrade HTTP to HTTPS), block-all-mixed-content (blocks HTTP on HTTPS pages). A well-configured CSP prevents 99% of XSS attacks even if you have vulnerabilities in code.

    HSTS: forcing HTTPS permanently

    Strict-Transport-Security (HSTS) tells the browser: 'always use HTTPS for this domain, never HTTP, not even if the user explicitly types http://'. Format: max-age=31536000; includeSubDomains; preload. The max-age in seconds indicates how long the browser will remember this rule (31536000 = 1 year). includeSubDomains applies the rule to all subdomains (critical, but make sure all support HTTPS).

    The preload directive is optional but powerful: it submits your domain to Chromium's HSTS Preload List (shared by Chrome, Firefox, Safari, Edge). This means browsers will NEVER try HTTP on your domain, not even on first visit. Benefit: eliminates attack window on first connection. Risk: if you break HTTPS on any subdomain, users can't access until you fix it. Requirements for preload: minimum 1-year max-age, includeSubDomains present, HTTPS working on all subdomains.

    Common mistakes: setting HSTS without having HTTPS configured (header is ignored on HTTP), using too short max-age in production (less than 6 months isn't effective), forgetting includeSubDomains and leaving subdomains vulnerable. Safe rollout strategy: start with max-age=300 (5 minutes), monitor for days, gradually increase to 86400 (1 day), then to 31536000 (1 year). If everything works, consider preload.

    Isolation headers: COEP, COOP, CORP

    Cross-Origin headers (COEP, COOP, CORP) work together to create strong isolation between origins, necessary for features like SharedArrayBuffer. COEP (Cross-Origin-Embedder-Policy) require-corp says: 'only load cross-origin resources if they have appropriate CORP or CORS header'. This prevents your page from reading data from other origins without explicit permission. Required to use powerful APIs like performance.measureUserAgentSpecificMemory().

    COOP (Cross-Origin-Opener-Policy) same-origin prevents popup windows or tabs opened by your site from accessing window.opener. Protects against 'reverse tabnabbing' attacks where a malicious site opened from your app can manipulate the original page. same-origin-allow-popups is more permissive: allows popups but not cross-origin. unsafe-none is the default (no protection).

    CORP (Cross-Origin-Resource-Policy) controls who can load YOUR resources. same-origin: only your origin. same-site: your site and subdomains. cross-origin: anyone (useful for public CDNs). These three headers combined create 'cross-origin isolation', enabling sensitive performance features. If your resources (images, scripts) are legitimately embedded on other sites, you need CORP: cross-origin or appropriate CORS headers.

    Platform-specific configuration: Nginx, Apache, Node.js

    In Nginx, add headers in the server or location block: add_header Strict-Transport-Security 'max-age=31536000; includeSubDomains; preload' always;. The always directive is crucial: without it, Nginx doesn't send the header on error responses (4xx, 5xx). For multiline CSP, escape or use a variable. Example: set $csp "default-src 'self'; script-src 'self' https://cdn.com"; then add_header Content-Security-Policy $csp always;.

    In Apache, use mod_headers. In .htaccess or config: Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload". For CSP: Header always set Content-Security-Policy "default-src 'self'; script-src 'self'". If you have issues, verify mod_headers is enabled: a2enmod headers and restart Apache.

    In Node.js/Express, use middleware like helmet: app.use(helmet()) sets several secure headers by default. To customize: app.use(helmet.contentSecurityPolicy({ directives: { defaultSrc: ["'self'"], scriptSrc: ["'self'", "'nonce-..."] } })). For dynamic nonces: generate with crypto.randomBytes(16).toString('base64') on each request, store in res.locals.nonce, and reference in CSP and templates. In Next.js, configure headers in next.config.js under async headers() return.

    FAQ

    Can I use all these headers simultaneously?

    Yes, and it's recommended for maximum security. There are no conflicts between them; each protects against different attack vectors.

    Do security headers affect site performance?

    Minimal impact: just extra bytes in the HTTP response. Browsers process headers quickly. CSP can prevent loading malicious resources, improving performance.

    What do I do if CSP breaks existing functionality?

    Use CSP-Report-Only first, analyze violations, adjust directives. For legacy inline scripts/styles, migrate to external files or use nonces/hashes.

    How do I test if my headers are configured correctly?

    Use SecurityHeaders.com or Mozilla Observatory. Browser DevTools → Network tab shows response headers. For CSP, Console shows violations.

    Was this generator useful?