Group
  • Deployment

    Set HTTP security headers on every response

    Turn on the free browser-level protections your app is probably shipping without.

    • Improve quality
    • Plan & validate
    • Beginner
    • General

Free Prompt

Add security headers to every HTTP response my app serves. These are free protections the browser will enforce for you, and they're the ones that scanners flag first. Set these headers: 1. Content-Security-Policy: start with a strict-but-workable policy for my actual asset sources (self, my CDN domain, any third parties I really use). Report violations to a report-uri (or the error tracker's CSP report endpoint) before enforcing, so I can find things I missed. Then move from report-only to enforcing. 2. Strict-Transport-Security: already covered in the SSL prompt; confirm it's set. 3. X-Content-Type-Options: nosniff. Stops the browser from guessing content types (which is a source of XSS via uploaded files). 4. X-Frame-Options: DENY (or SAMEORIGIN if I need iframes on my own site). Alternatively use frame-ancestors in the CSP. Prevents clickjacking. 5. Referrer-Policy: strict-origin-when-cross-origin. Stops leaking full URLs (with tokens in query strings) to third-party sites. 6. Permissions-Policy: disable browser features I don't use (camera, microphone, geolocation, USB) so a compromised script can't ask for them. 7. Cross-Origin-Opener-Policy: same-origin and Cross-Origin-Embedder-Policy: require-corp only if I need Spectre isolation (probably not for a normal web app). Skip if it breaks things. Also: 8. Verify with a real scanner: securityheaders.com or the equivalent. Aim for at least an A grade before launch. 9. Cookies: HttpOnly, Secure, and SameSite=Lax (or Strict for anything sensitive) on every session/auth cookie. This is more of an app-level fix but scanners will flag it too. Don't ship a CSP you haven't tested; a wrong one silently breaks the site for users while looking fine in your local browser. The deliverable is headers set on every response, CSP moved from report-only to enforcing after a soak, cookies flagged correctly, and a scanner grade recorded before and after.

What This Does / How This Helps

This adds the browser-enforced security headers (CSP, HSTS, nosniff, X-Frame-Options, Referrer-Policy, Permissions-Policy) and sets cookies with the right flags, so entire classes of XSS/clickjacking/data-leakage bugs get blocked at the browser instead of relying on you never making a mistake. Security headers are the closest thing to free protection you get. A single afternoon moves your app from 'F on the scanner' to 'A', kills a bunch of attack shapes outright, and won't affect legitimate users. CSP is the finicky one, which is why you roll it out in report-only mode first and enforce after you've fixed the noise.

Want to skip doing this by hand?

Fortivibe audits your app for all of the areas these prompts cover (and more).

See What We Check

Related Prompts