HTTP Security Headers Generator

Security headers are a simple yet effective layer of protection: they guard against clickjacking, enforce HTTPS and limit the impact of XSS attacks. Select the headers, set the format for your server (Apache or Nginx) and paste the result into your configuration. Everything is computed in your browser. This complements WordPress security and HTTPS configuration.

Forces HTTPS for a set time. Enable it only once the site reliably works on HTTPS — enforcement is hard to undo during the max-age period.

Protects against clickjacking by blocking embedding of the page in an iframe.

Sets nosniff — the browser does not guess the MIME type, which limits some attacks.

Disables access to sensitive browser features (camera, microphone, geolocation) if the site does not use them.

The strongest but trickiest header — it controls where scripts, styles and media load from. Misconfigured, it can break the site. Start in report-only mode.


                    
⚠ Test after deploying. HSTS and CSP can break the site if misconfigured. CSP is best deployed gradually: first Report-Only, then enforcing. After changes, check the site at securityheaders.com.
For Apache paste into .htaccess or the virtual host configuration. For Nginx paste into the server { } block and reload the configuration (nginx -t && systemctl reload nginx).

What HTTP security headers are

Security headers are additional headers the server attaches to every response, telling the browser how to handle the page safely. They do not change the look, but they close whole classes of attacks: they enforce an encrypted connection, block embedding the page in a frame, limit the sources scripts can load from, and control what information leaks in the referrer header. It is one of the easiest to deploy, yet very worthwhile layers of WordPress security. The generator assembles a ready-made set in Apache or Nginx format, and below we explain the role of each header.

What each header does

Strict-Transport-Security (HSTS) Forces the browser to use HTTPS-only connections for a set time. Protects against downgrade attacks and interception over an insecure connection. Enable it only with stable HTTPS, as it is hard to reverse.
X-Frame-Options Blocks embedding your page in an iframe on another domain, which protects against clickjacking (luring users into clicking a hidden element). SAMEORIGIN allows frames only within your own domain.
X-Content-Type-Options The nosniff value tells the browser to stick to the declared file type and not guess it, which limits some attacks based on spoofing the content type.
Referrer-Policy Controls how much information about the source address the browser passes when moving to another site. The strict-origin-when-cross-origin setting is a good compromise between privacy and analytics.
Permissions-Policy Disables access to sensitive browser features (camera, microphone, geolocation) if the site does not use them, limiting abuse by injected code.
Content-Security-Policy (CSP) The strongest header: it specifies which sources scripts, styles and media can load from, blocking unauthorized code (XSS). It is also the hardest, so deploy it gradually, starting with Report-Only mode.

How to deploy safely

Most headers (X-Frame-Options, X-Content-Type-Options, Referrer-Policy) can be enabled right away, as they rarely break anything. Be careful with HSTS and CSP. Enable HSTS only once the site works confidently on HTTPS, and deploy CSP in stages: first the Content-Security-Policy-Report-Only mode, which blocks nothing but lets you observe what would be blocked; after analysis, switch to the enforcing header. After each change, verify the site in the free securityheaders.com tool and in the Network tab of your browser's developer tools.

Frequently asked questions about security headers

Server response headers telling the browser how to treat the page safely: enforce HTTPS, block frames, limit script sources and control the referrer. They protect against clickjacking and XSS.

Same headers, different syntax. Apache: Header always set in .htaccess or vhost (mod_headers). Nginx: add_header in the server block. The generator produces both formats. Server differences are covered in our article on Apache, Nginx and LiteSpeed.

HSTS forces HTTPS-only in the browser for a set time. Enable it only with stable HTTPS, as during max-age you cannot access over HTTP and reverting is hard. Use preload only if you meet the preload list requirements.

Yes, an overly strict CSP will block scripts, styles or fonts. Deploy it gradually: first Report-Only (blocks nothing), then switch to the enforcing header after analyzing reports.

After deploying, check the site at securityheaders.com or in the Network tab of developer tools, where the response headers and their values are visible.

Tool and write-up: Marcin Szewczyk-Wilgan, WebOptimo. Header sets based on practical hardening of Apache and Nginx servers for WordPress. The generator runs in the browser, with no data sent.

We will take care of your site's security

We deploy security headers, HTTPS, WAF and hardening of Apache and Nginx servers for WordPress. No obligation — a concrete proposal after a short conversation.

Phone

+48 608 271 665

Mon–Fri, 8:00–16:00

E-mail

kontakt@weboptimo.pl

We reply within 24h

Company

WebOptimo

VAT ID: PL6391758393