HTTP Security Headers Generator

Configure and generate HTTP security headers for your website. Export ready-to-use configs for Nginx, Apache, Node.js, and PHP.

Recommended
max-age
X-Frame-Options
Recommended
Referrer-Policy
Cross-Origin Policies
Generated Output 
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains";
add_header X-Frame-Options "SAMEORIGIN";
add_header X-Content-Type-Options "nosniff";
add_header Referrer-Policy "strict-origin-when-cross-origin";
add_header X-XSS-Protection "1; mode=block";
add_header Permissions-Policy "camera=(none), microphone=(none), geolocation=(none), payment=(none), usb=(none)";
add_header X-Permitted-Cross-Domain-Policies "none";

Paste inside your server {} block in nginx.conf.

Security Checklist
HSTS enabled
X-Frame-Options set
X-Content-Type-Options
Referrer-Policy set
Permissions-Policy
CSP configured
Cross-Origin policies

About HTTP Security Headers

What Are HTTP Security Headers?

HTTP security headers are response headers sent by your web server that instruct the browser on how to behave when handling your website's content. They help protect against a wide range of common web attacks including cross-site scripting (XSS), clickjacking, MIME-type sniffing, and data injection attacks.

Why Security Headers Matter

Without proper security headers, browsers may execute malicious scripts, allow your site to be embedded in iframes on attacker-controlled sites, or leak sensitive information through referrer headers. Implementing the right headers is one of the easiest and most impactful security improvements you can make.

How to Use This Generator

  1. Toggle each header on or off based on your requirements
  2. Configure the values for each enabled header
  3. Select your server platform (Nginx, Apache, Node.js, PHP)
  4. Copy the generated config and paste it into your server configuration
  5. Test your headers using a security scanner after deployment

Most Important Headers

  • HSTS — Forces HTTPS connections, preventing downgrade attacks
  • CSP — Controls which resources the browser is allowed to load
  • X-Frame-Options — Prevents clickjacking by blocking iframe embeds
  • X-Content-Type-Options — Stops MIME-type sniffing attacks
  • Permissions-Policy — Restricts browser feature access (camera, mic, etc.)

Header Reference

Strict-Transport-Security (HSTS)

max-age=31536000; includeSubDomains

Tells browsers to always use HTTPS for the specified duration. The includeSubDomains directive applies the policy to all subdomains. Adding preload registers the domain for browser HSTS preload lists.

Content-Security-Policy (CSP)

default-src 'self'; script-src 'self'

Defines which content sources are trusted. Prevents XSS attacks by blocking inline scripts and unauthorized external resources. Start with a strict policy and loosen as needed based on your application's requirements.

X-Frame-Options

SAMEORIGIN

Prevents your page from being embedded in iframes on other domains. DENY blocks all framing; SAMEORIGIN allows framing by pages on the same origin. Helps prevent clickjacking attacks.

X-Content-Type-Options

nosniff

Prevents browsers from MIME-type sniffing — guessing a file's content type different from what the server declares. This stops attackers from tricking browsers into executing non-script files as scripts.

Referrer-Policy

strict-origin-when-cross-origin

Controls how much referrer information is included with requests. strict-origin-when-cross-origin sends full URL for same-origin requests but only the origin for cross-origin requests, and nothing when downgrading to HTTP.

Permissions-Policy

camera=(), microphone=(), geolocation=()

Restricts which browser APIs and features your page and embedded iframes can use. Empty parentheses () deny the feature for all origins. Use (self) to allow only for the same origin.

Cross-Origin-Embedder-Policy (COEP)

require-corp

Prevents a document from loading cross-origin resources that do not explicitly grant permission. Required (along with COOP) to enable cross-origin isolation, which allows use of SharedArrayBuffer and precise timers.

Cross-Origin-Opener-Policy (COOP)

same-origin

Ensures a top-level document does not share a browsing context group with cross-origin documents. Helps isolate your origin from attackers and enables cross-origin isolation features.

Frequently Asked Questions

Will adding security headers break my website?

Some headers, especially CSP and Permissions-Policy, can restrict functionality if configured too strictly. Start with more permissive values and tighten them gradually. HSTS, X-Content-Type-Options, and X-Frame-Options are generally safe to add without side effects for most sites.

How do I test my security headers after deployment?

You can use browser DevTools (Network tab → select a request → Headers) to inspect response headers. Online scanners like securityheaders.com give you a graded report with recommendations.

Should I add these headers to every response?

Yes — most security headers should be applied to all HTML responses. For API endpoints returning JSON, you may want to omit X-Frame-Options and CSP but keep HSTS, X-Content-Type-Options, and CORS headers.

What is HSTS preloading?

HSTS preloading adds your domain to a list built into browsers that forces HTTPS from the very first connection — before any HTTP response is received. This eliminates a small window of vulnerability during the first visit. Once preloaded, it is very hard to undo, so only use it on production domains.

What's the difference between COEP, COOP, and CORP?

These three headers work together to enable cross-origin isolation. COOP prevents your page from sharing a browsing context with cross-origin pages. COEP requires all loaded resources to explicitly opt-in to cross-origin loading. CORP limits which origins can load your resources. Together they enable SharedArrayBuffer and high-resolution timers.