Generate HTTP security headers for Apache, Nginx, PHP, or WordPress in seconds. Pick your headers, configure the options, and copy a clean, commented config. Everything runs in your browser, nothing is stored or sent anywhere.
Why HTTP security headers matter
Most WordPress hardening advice focuses on the application layer: updating plugins, using strong passwords, limiting login attempts. That’s all valid. But there’s an entire layer above it that most sites ignore: HTTP response headers.
Security headers are instructions your server sends to the browser with every response. They tell the browser what it’s allowed to do: which domains can load scripts, whether the site can be framed, how long to enforce HTTPS. They cost nothing to implement and they stop entire categories of attacks before any code runs.
A site without security headers is like a secure building with the windows left open.
What each header does
Strict-Transport-Security (HSTS)
Tells the browser to always use HTTPS for your domain, even if a user types http:// directly. Once a browser has seen this header, it won’t make an insecure connection to your site for the duration of max-age. The includeSubDomains directive extends this to all subdomains. The preload flag submits your domain to the hstspreload.org list, which browsers ship with baked in, so even first-time visitors get HTTPS.
Start with a short max-age (30 days) to test, then extend to 1 year once you’re confident your entire site runs on HTTPS.
Content-Security-Policy (CSP)
The most powerful, and most complex, security header. CSP tells the browser exactly which origins are allowed to load scripts, styles, images, fonts, and other resources. A well-configured CSP stops XSS attacks cold: even if an attacker injects a script tag, the browser refuses to execute it if the source isn’t whitelisted.
Start with the Moderate preset. Test thoroughly. Tighten from there. A wrong CSP silently breaks your site: missing a CDN domain means a resource doesn’t load and you don’t always get a clear error.
X-Frame-Options
Prevents your page from being loaded inside an <iframe> on another domain. This kills clickjacking attacks, where an attacker overlays an invisible frame over a legitimate page to trick users into clicking something they didn’t intend to. Use DENY unless you have a specific reason to allow same-origin framing.
Note: CSP’s frame-ancestors directive does the same job and is the modern approach. Both are included here because X-Frame-Options covers older browsers that don’t support CSP.
X-Content-Type-Options
A single directive: nosniff. Stops the browser from trying to guess the MIME type of a response. Without this, a browser might execute a file uploaded as an image if it looks like JavaScript. Short, cheap, and worth always including.
Referrer-Policy
Controls what information is sent in the Referer header when a user follows a link from your site to another. strict-origin-when-cross-origin is the recommended default: it sends the full URL for same-origin requests (useful for analytics) but only the origin (not the path) for cross-origin requests. This prevents leaking sensitive URL parameters to third parties.
Permissions-Policy
Formerly Feature-Policy. Lets you explicitly disable browser APIs your site doesn’t need: camera, microphone, geolocation, payment, USB, and more. Even if a plugin or third-party script tries to access these features, the browser blocks it. A useful defense-in-depth measure.
Server and X-Powered-By removal
These aren’t headers you’re adding, they’re headers you’re removing. By default, Apache announces its version (Server: Apache/2.4.51) and PHP announces itself (X-Powered-By: PHP/8.1.0). Neither is needed by the browser. Both hand attackers a roadmap of what to exploit.
How to add security headers to WordPress
The fastest method for WordPress is the functions.php output. Use the WP functions.php tab in the generator above, copy the output, and paste it into your active theme’s functions.php or, better, into a site-specific plugin so it survives theme changes.
If you manage your own server, the Apache or Nginx output drops directly into your virtual host config or .htaccess. Pair this with the WordPress .htaccess Generator to cover both layers at once.
Want to lock down the REST API too? The Turn Off REST API plugin gives you fine-grained control over which endpoints are publicly accessible.
Testing your headers
After adding security headers, verify them with these free tools:
- securityheaders.com – paste your URL and get a grade with a full breakdown of what’s missing or misconfigured
- Browser DevTools – open the Network tab, click any request, and check the Response Headers section
- Mozilla Observatory – grades your headers alongside TLS configuration and other security signals
Aim for an A on securityheaders.com. The headers generated by this tool, all enabled, will get you there on most standard WordPress setups.
Things to watch out for
- CSP and page builders: If you use Elementor, Divi, or similar page builders, they often inject inline scripts and styles. The Strict CSP preset will break them. Start with Moderate and add
'unsafe-inline'tostyle-srcif needed. - HSTS and preload: Don’t add
preloaduntil your entire site, including all subdomains, is on HTTPS. Preloaded HSTS is very hard to undo. - Caching layers: If you’re behind Cloudflare or another CDN, set headers at the CDN level too. Server-level headers may be stripped or overridden.
- Managed WordPress hosts: WP Engine, Kinsta, and Flywheel often let you set headers through their dashboard rather than
.htaccessorfunctions.php. Check your host’s documentation.