Free tool, runs in your browser
Generate security headers for your deployment
Pick where you deploy, choose the protections you want, and copy config that is ready to paste. Start with a report-only Content-Security-Policy so nothing breaks.
next.config.ts
const securityHeaders = [
{ key: "Strict-Transport-Security", value: "max-age=63072000" },
{ key: "X-Content-Type-Options", value: "nosniff" },
{ key: "Referrer-Policy", value: "strict-origin-when-cross-origin" },
{ key: "Permissions-Policy", value: "camera=(), microphone=(), geolocation=(), payment=()" },
{ key: "Content-Security-Policy-Report-Only", value: "default-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline'; img-src 'self' data:; connect-src 'self'; object-src 'none'; base-uri 'self'; form-action 'self'; frame-ancestors 'none'" },
];
const nextConfig = {
async headers() {
return [{ source: "/:path*", headers: securityHeaders }];
},
};
export default nextConfig;Everything runs in your browser. Nothing you type is sent anywhere. Test the result on a staging copy first: a strict CSP can block scripts, fonts or widgets your app needs.
What each header does
| Header | What it protects against | Risk of setting it |
|---|---|---|
| Strict-Transport-Security | Browsers reaching your site over plain HTTP, which lets someone on the network tamper with pages | Low, but includeSubDomains breaks any subdomain that lacks HTTPS |
| Content-Security-Policy | Injected scripts running, and data being sent to unknown domains | High until tuned: it can block analytics, fonts, widgets and inline scripts |
| X-Content-Type-Options | Browsers guessing a file's type and running it as a script | Very low |
| Referrer-Policy | Your full page addresses leaking to other sites when users click away | Low |
| Permissions-Policy | Pages using the camera, microphone, location or payment APIs unless you allow it | Low, but blocks features you may use |
| frame-ancestors (in the CSP) | Other sites embedding your pages in a frame to trick users into clicking | Low, unless you embed your own pages |
Roll out a Content-Security-Policy safely
- 1Generate it in report-only mode and deploy to a staging copy.
- 2Load every important page and read the browser console for blocked resources.
- 3Add only the origins you recognise and actually need, such as your payment or analytics provider.
- 4Repeat until the console is quiet, then switch the header to enforcing.
Check what your site actually sends
After deploying, read the live response headers from a terminal. Only run this against a site you own.
curl -sI https://your-app.example | grep -iE "strict-transport|content-security|x-content-type|referrer-policy|permissions-policy"Frequently asked questions
Is my data sent to a server when I use this tool?
No. The generator runs entirely in your browser. The values you type stay on your device and are not sent, stored or logged anywhere.
Why start with Content-Security-Policy-Report-Only?
A strict policy can silently block scripts your app needs. Report-only mode logs violations in the browser console without blocking anything, so you can tune the policy before enforcing it.
Do I need includeSubDomains on HSTS?
Only if every subdomain you own serves HTTPS. Setting it too early can make an HTTP-only subdomain unreachable in browsers that have cached the rule.
Will these headers stop my app being hacked?
No single header does that. They lower the damage from certain attacks such as script injection and clickjacking. Database rules, secret handling and server-side access checks matter more.