Skip to main content

Free HTTP Security Headers Generator – Nginx, Apache, Vercel & More

Generate HSTS, X-Frame-Options, Referrer-Policy, Permissions-Policy, and the Cross-Origin headers with explanations, then export as Nginx, Apache, Vercel, Netlify, or Express config.

Written & reviewed by Helperzy Editorial Team · Updated July 2026

9 Headers4 Server FormatsNginx · Apache · Vercel · NetlifyFree

Strict-Transport-Security

Forces browsers to only ever connect over HTTPS for the given duration, protecting against protocol-downgrade and cookie-hijacking attacks on the first HTTP request.

X-Frame-Options

Prevents clickjacking by controlling whether your page can be embedded in an <iframe> on another site. In modern browsers, the CSP frame-ancestors directive supersedes this header when both are present — set this as a fallback for older browsers.

X-Content-Type-Options: nosniff

Always on, fixed value. Stops the browser from "MIME-sniffing" a response into a different content type than the server declared — the classic attack this blocks is a file uploaded as an image that actually contains executable script, which some browsers used to sniff and run.

Referrer-Policy

Controls how much of your page's URL is leaked to the next site in the Referer header when a user clicks a link away from your site.

Permissions-Policy

Controls which browser features and APIs your page (and any embedded iframe) is allowed to use.

Camera
Microphone
Geolocation
Payment
Fullscreen

Cross-Origin-Opener-Policy

Isolates your page's browsing context from cross-origin popups/windows, closing off Spectre-style cross-origin data leaks.

Cross-Origin-Embedder-Policy

Requires every cross-origin resource your page embeds to explicitly opt in via CORP/CORS. This can break third-party embeds (widgets, some images) that haven't opted in — test thoroughly before enabling require-corp.

Cross-Origin-Resource-Policy

Declares who is allowed to load YOUR resources cross-origin — the other side of the COEP coin, and the main defense against cross-origin data-leak attacks like Spectre reading a resource's contents through timing.

This header controlled a legacy browser XSS filter that no modern browser ships anymore — Chrome, Edge, and Safari all ignore it, and Content-Security-Policy is the real replacement. It's included here only for completeness and is left off the generated output unless you explicitly enable it.

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
add_header X-Frame-Options "SAMEORIGIN" always;
add_header X-Content-Type-Options "nosniff" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header Permissions-Policy "camera=(), microphone=(), geolocation=(), payment=(), fullscreen=(self)" always;
add_header Cross-Origin-Opener-Policy "same-origin" always;
add_header Cross-Origin-Embedder-Policy "unsafe-none" always;
add_header Cross-Origin-Resource-Policy "same-origin" always;

Scope: Headers Only, Not CSP

This tool covers the non-CSP security headers. For Content-Security-Policy specifically — script/style sources, nonces, and the report-uri directive — use the companion CSP Header Generator.

100% Private

Every header value and config snippet is generated locally in your browser. Nothing you configure here is uploaded or sent anywhere.

How to Use HTTP Security Headers Generator

1

Configure Each Header

Set HSTS max-age and its options, choose X-Frame-Options, pick a Referrer-Policy, decide which features Permissions-Policy allows, and select the Cross-Origin policy values. Each header has an explanation of what it prevents and what it can break so your choices are informed.

2

Heed the Warnings

The tool flags high-impact choices like HSTS preload, which is hard to undo, and COEP require-corp, which can break third-party embeds. Read these before enabling them, and start conservative on an existing site so legitimate functionality keeps working.

3

Export in Your Server's Format

Switch the output to Nginx, Apache .htaccess, vercel.json, Netlify _headers, or Node/Express and copy the generated block straight into your configuration. Getting the exact syntax right avoids the silent non-enforcement a typo in a header name causes.

Which HTTP Security Headers Matter and How to Deploy Them

HTTP security headers are response headers that instruct the browser to enforce protections against common web attacks: protocol downgrades, clickjacking, MIME-sniffing, referrer leakage, and cross-origin data theft. Unlike Content-Security-Policy, which is a large topic of its own, these headers are mostly single-value switches, but each closes a specific and well-understood attack surface. This generator builds the recommended set with a plain-language explanation of what each header prevents and what it can break, then exports the result in five deployment formats so you can paste it straight into whatever server or platform you run. The core headers are Strict-Transport-Security (HSTS), which forces browsers to use HTTPS for a set duration and protects against downgrade and cookie-hijacking attacks; X-Frame-Options, which prevents your page being framed by another site as a clickjacking defense; X-Content-Type-Options: nosniff, which stops the browser from second-guessing a response's declared content type; Referrer-Policy, which controls how much of your URL leaks to the next site; and Permissions-Policy, which decides whether features like camera, microphone, geolocation, and payment are allowed. The Cross-Origin trio — COOP, COEP, and CORP — isolates your page's browsing context and controls cross-origin resource loading, closing off Spectre-style side-channel leaks. The tool outputs each as Nginx add_header lines, Apache Header set directives, a Netlify _headers block, a vercel.json headers array, and a Node/Express middleware snippet. Configure HSTS with a one-year max-age of 31536000 and includeSubDomains, and the generated header reads max-age=31536000; includeSubDomains. Set X-Frame-Options to SAMEORIGIN and Referrer-Policy to strict-origin-when-cross-origin, turn camera, microphone, and geolocation to none in Permissions-Policy, and the tool renders the exact syntax for each. Switch the output format to Nginx and you get a line like add_header X-Frame-Options "SAMEORIGIN" always; switch to Apache and the same header becomes Header set X-Frame-Options "SAMEORIGIN". The deprecated X-XSS-Protection header is left off by default, since modern browsers ignore it and CSP is its real replacement, and it appears only if you explicitly opt in. A developer launching a new site drops the generated Nginx block into their server configuration to earn a strong grade on header-scanning services and, more importantly, to close real attack surfaces before going live. A team on Vercel or Netlify copies the platform-specific config into vercel.json or a _headers file, since those platforms do not use a traditional server. An engineer retrofitting an established application starts with a conservative HSTS max-age and X-Frame-Options set to SAMEORIGIN so existing legitimate iframes keep working, then tightens the policy once they confirm nothing broke. In each case the value is getting the exact syntax right the first time, since a typo in a header name means silent non-enforcement. Two cautions matter most. HSTS preload submits your domain to a hardcoded list baked into browsers and is genuinely hard to undo — removal can take months — so the tool warns before you enable it and advises turning it on only when you are certain every subdomain will serve HTTPS indefinitely. Second, X-Frame-Options is superseded by the CSP frame-ancestors directive in modern browsers when both are present, so treat X-Frame-Options as a fallback for older clients rather than your primary clickjacking defense, and build the CSP part with the companion CSP generator. A third thing worth checking is that a header is only enforced if its name is spelled exactly right, since browsers silently ignore an unknown header rather than reporting an error, so a single typo can leave you believing a protection is active when it is not. Copy the generated block verbatim rather than retyping it to avoid exactly that trap. Everything here is assembled locally in your browser and nothing you configure is transmitted anywhere, so you can prepare hardening for production infrastructure without exposing any of its details.

Examples: HTTP Security Headers Generator

Input

HSTS: 1 year, includeSubDomains

Result

Strict-Transport-Security: max-age=31536000; includeSubDomains

31536000 seconds is one year; includeSubDomains extends the HTTPS-only rule to every subdomain. Preload is left off unless explicitly enabled because it is hard to reverse.

Input

X-Frame-Options SAMEORIGIN in Nginx format

Result

add_header X-Frame-Options "SAMEORIGIN" always;

The Nginx add_header directive with the always flag ensures the header is sent even on error responses, providing a clickjacking fallback for older browsers.

Input

Permissions-Policy with camera and microphone off

Result

Permissions-Policy: camera=(), microphone=(), geolocation=(), payment=(), fullscreen=(self)

Empty parentheses disable a feature entirely; (self) allows it only for your own origin — here fullscreen is permitted for the site but camera and microphone are blocked.

Frequently Asked Questions – HTTP Security Headers Generator

HSTS (Strict-Transport-Security) forces browsers to use HTTPS for your domain for a set duration, preventing downgrade attacks. Preload adds your domain to a list hardcoded into browsers, which is hard to undo and can take months to reverse, so enable it only once you are sure every subdomain will serve HTTPS permanently.