Toolypet
Security Tools/Security Headers

Security Headers

Generate HTTP security headers for your web server

Presets

Security Headers

Forces HTTPS connections for secure communication

Prevents clickjacking attacks by controlling iframe embedding

Prevents MIME type sniffing attacks

Legacy XSS filter (deprecated, use CSP instead)

Controls how much referrer information is sent

Controls browser features and APIs

Prevents loading cross-origin resources without permission

Isolates browsing context from cross-origin documents

Protects resources from being loaded by other origins

Generated Output

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
X-Frame-Options: DENY
X-Content-Type-Options: nosniff
Referrer-Policy: strict-origin-when-cross-origin
Permissions-Policy: geolocation=(), microphone=(), camera=()

5 headers enabled

Implementation Note

Add these headers to your web server configuration. For Nginx, add to the server block. For Apache, add to .htaccess or httpd.conf. Test thoroughly before deploying to production.

Security Headers Guide

Learn how to protect your web application with HTTP security headers

What are Security Headers?

HTTP security headers are directives sent by web servers to browsers that help protect against common web vulnerabilities. They control how browsers handle your site's content, preventing attacks like XSS, clickjacking, and data injection.

How to Use

  1. Choose a preset (Basic, Recommended, or Strict) based on your security needs
  2. Toggle individual headers on/off and customize their values
  3. Select your output format (Raw, Nginx, or Apache)
  4. Copy the generated configuration and add it to your web server

Best Practices

Frequently Asked Questions

Which headers are most important?

The essential headers are: Strict-Transport-Security (HSTS) for forcing HTTPS, X-Content-Type-Options to prevent MIME sniffing, and X-Frame-Options or CSP frame-ancestors to prevent clickjacking. These three provide significant protection against common attacks with minimal compatibility issues.

Will these headers break my website?

Most headers like HSTS, X-Content-Type-Options, and Referrer-Policy are safe and won't break functionality. However, strict COOP/COEP settings can affect cross-origin resources. Always test in a staging environment first, especially if your site uses third-party scripts, iframes, or cross-origin APIs.

What's the difference between X-Frame-Options and CSP frame-ancestors?

Both prevent clickjacking but CSP frame-ancestors is more flexible and modern. X-Frame-Options only supports DENY or SAMEORIGIN, while frame-ancestors allows specific domains. CSP frame-ancestors takes precedence when both are set. Use frame-ancestors if you need to allow specific sites to embed your content.

Should I use HSTS preload?

HSTS preload adds your domain to browsers' built-in HTTPS-only list. This provides maximum protection but is difficult to reverse. Before enabling preload: ensure all subdomains support HTTPS, commit to HTTPS permanently, and start with a shorter max-age. Only add the preload directive when you're certain.

What are COOP, COEP, and CORP headers?

These are isolation headers for advanced security: COOP (Cross-Origin-Opener-Policy) isolates your window from cross-origin popups. COEP (Cross-Origin-Embedder-Policy) ensures all resources are explicitly shared. CORP (Cross-Origin-Resource-Policy) controls who can load your resources. Together they enable powerful features like SharedArrayBuffer but require all resources to opt-in.