Security headers

Security headers are lines in the response of your web server that tell the browser what it must refuse: guessing file types, showing your pages inside foreign frames, passing full addresses to other sites, falling back to HTTP or loading scripts from unknown hosts. Hive writes them for you, generates the matching web server configuration and checks what really reaches a visitor. This page explains every header, the three ways it can take and what to do when the check reports a problem.

What is included in which plan

All header settings sit under Protection Settings → Firewall & Bots → Security Headers. The master switch Send security headers is off after installation; the quickstart recommendation switches it on. The three basic headers are part of the free plugin. The advanced set comes with the Pro add-on from the Professional plan on and works in Local Shield as well as in the Community Network.

Every header is only sent while Send security headers is on. When a plan ends, Hive stops sending the advanced headers and keeps the basic three. Headers you have copied into the web server configuration are not affected by either: the web server keeps sending them until you remove them there.

Three ways to the visitor

The panel How the headers reach your visitors above the header rows shows the state of each route on your site.

1. Web server configuration. nginx or Apache add the headers to every response: pages from a page cache, images, CSS and JavaScript files, the sign-in page and error pages. This is the most compatible route. Hive generates the configuration from your settings.
2. Extended protection. The firewall that runs before WordPress (see Firewall and WAF) sends the headers as well. It reaches pages a caching plugin delivers through PHP, for example from advanced-cache.php. It works on front-end requests through index.php only, not in wp-admin, and sends HSTS only over HTTPS.
3. WordPress alone. Hive adds the headers to every front-end page WordPress builds. Pages from a page cache, static files and everything the web server answers itself go out without them.

Whatever you choose, set each header in one place only. A header the web server sets on its own is invisible to WordPress, so Hive cannot skip it, and it then arrives twice. The header check finds this.

Setting it up step by step

Every header in detail

What the headers look like in a response:

X-Content-Type-Options: nosniff
X-Frame-Options: SAMEORIGIN
Referrer-Policy: strict-origin-when-cross-origin
Strict-Transport-Security: max-age=31536000; includeSubDomains
Permissions-Policy: geolocation=(), camera=(), microphone=(), payment=(), usb=()
Cross-Origin-Opener-Policy: same-origin
Cross-Origin-Resource-Policy: same-origin

HSTS. Once a browser has seen the header, it connects over HTTPS only for as long as max-age says, and you cannot take that back for visitors who already have it. Turn it on only when every page and every file loads over HTTPS. The stored default is 63072000 (two years), which is also the upper limit; start with 300 (five minutes). HSTS includeSubDomains extends the rule to every subdomain, mail and shop subdomains included. HSTS preload asks the browsers to ship your domain in their built-in list (hstspreload.org); it needs includeSubDomains and at least one year, and getting off the list takes months. Hive sends HSTS only over HTTPS. Behind a proxy that ends TLS, WordPress has to recognise the request as HTTPS, otherwise Hive leaves HSTS out.

Permissions-Policy. feature=() turns a feature off, feature=(self) allows it for your own pages only. The default turns off payment; a shop with Apple Pay or Google Pay buttons needs payment=(self) or has to remove the entry, otherwise the buttons do not appear.

X-Frame-Options and the CSP. Current browsers follow the frame-ancestors directive of an enforced Content-Security-Policy first. X-Frame-Options stays for older browsers; keep both on the same line, for example SAMEORIGIN and frame-ancestors 'self'.

Content-Security-Policy step by step

A CSP is a list of sources the browser may load scripts, styles, images, fonts, frames and connections from. Everything else is refused. It is the strongest header and the one that breaks the most, so it has two modes: Report only sends the policy as Content-Security-Policy-Report-Only, nothing is blocked and every violation appears in the browser console. Enforce sends Content-Security-Policy and blocks.

1. Start with the WordPress starter policy. Set Content-Security-Policy mode to Report only and paste the policy below into Content-Security-Policy. It fits a WordPress site without external services. Most themes need 'unsafe-inline' for scripts and styles, so it is included.
2. Open every page type. Home page, a post, a page, the contact form, the shop, the cart and the checkout, with the cookie banner accepted, because tracking and embeds often load only after consent. Open the browser console with F12; every source the policy does not allow is listed there with the directive it violates.
3. Add each external source to its directive. A script host belongs in script-src, a host the page sends data to in connect-src, a video or map frame in frame-src, a font host in font-src. Separate directives with semicolons and hosts with spaces. Save, reload and repeat until the console stays quiet.
4. Switch to Enforce. Set the mode to Enforce, open the page types once more and keep an eye on forms and checkout for a few days.

The WordPress starter policy from the plugin:

default-src 'self'; script-src 'self' 'unsafe-inline'; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:; font-src 'self' data:; connect-src 'self'; frame-src 'self'; object-src 'none'; base-uri 'self'; form-action 'self'; frame-ancestors 'self'

Example: Google Tag Manager with Google Analytics 4. The tag manager loads its script from www.googletagmanager.com, and Analytics sends its measurements to two Google host families. Add them to script-src and connect-src:

default-src 'self'; script-src 'self' 'unsafe-inline' https://www.googletagmanager.com; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:; font-src 'self' data:; connect-src 'self' https://*.google-analytics.com https://*.analytics.google.com; frame-src 'self'; object-src 'none'; base-uri 'self'; form-action 'self'; frame-ancestors 'self'

Each further tag in the container brings its own hosts, which the console names. img-src already allows images from every HTTPS host in the starter policy, so tracking pixels need no entry there. In report-only mode browsers ignore frame-ancestors; X-Frame-Options covers that until you enforce.

CSP report URI. Optional. An HTTPS address that receives every violation as a JSON report. Hive sends it as report-uri and, for current browsers, as report-to csp-endpoint together with a Reporting-Endpoints header:

Content-Security-Policy-Report-Only: default-src 'self'; ...; report-uri https://example.com/csp-report; report-to csp-endpoint
Reporting-Endpoints: csp-endpoint="https://example.com/csp-report"

Privacy: every report contains the IP address of the visitor and the address they visited. An external reporting service therefore processes personal data on your behalf and needs a data processing agreement, and your privacy policy has to mention it. For most sites the browser console during the report-only phase is enough; leave the field empty then.

The generated web server configuration

Under Server configuration and header check Hive shows the configuration for nginx and for Apache, built from the saved settings, each with a Copy button. Save first after a change. With Send security headers off there is nothing to generate: switch it on, save, copy, then switch it off again once the configuration is live. Keep a copy of the lines, because you need the same steps after every later change. With the basic three and HSTS the output looks like this:

# ReportedIP Hive: security headers for nginx.
# Paste into the server { } block that serves HTTPS, then run: nginx -t && systemctl reload nginx
# A location { } block with its own add_header inherits none of these lines.
# Repeat them there, or keep them in one file and include it in both places.
# Afterwards switch off "Send security headers" in Hive, otherwise every header is sent twice.
add_header X-Content-Type-Options "nosniff" always;
add_header X-Frame-Options "SAMEORIGIN" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header Strict-Transport-Security "max-age=31536000" always;

# ReportedIP Hive: security headers for Apache (.htaccess or virtual host).
# Afterwards switch off "Send security headers" in Hive, otherwise every header is sent twice.
<IfModule mod_headers.c>
	Header always set X-Content-Type-Options "nosniff"
	Header always set X-Frame-Options "SAMEORIGIN"
	Header always set Referrer-Policy "strict-origin-when-cross-origin"
	Header always set Strict-Transport-Security "max-age=31536000" "expr=%{HTTPS} == 'on'"
</IfModule>

What to watch out for:

• always. Without it nginx adds headers only to successful responses. With it they also reach error pages and redirects.
• Location blocks do not inherit. nginx passes add_header lines down only to blocks that have none of their own. A location block that sets its own header, typically Cache-Control for images or the cache location of Rocket-Nginx, loses all security headers. Keep the lines in one file and include it in the server block and in every such location block.
• HTTPS server block. Paste the nginx lines into the block that serves port 443. A block that only redirects HTTP to HTTPS does not need them.
• Test before reload. nginx -t checks the syntax; reload only when it reports success.
• IfModule on Apache. If mod_headers is missing, Apache skips the block instead of answering every request with a 500 error. The check then shows the headers as missing, and the host has to enable the module.
• HSTS on Apache. The expr=%{HTTPS} == 'on' condition limits HSTS to HTTPS, so the same lines work in a .htaccess that serves both protocols.
• Switch off "Send security headers" afterwards. Otherwise WordPress adds every header a second time to the pages it builds.

The include file for nginx, as an example:

# /etc/nginx/snippets/security-headers.conf holds the generated add_header lines
server {
    listen 443 ssl;
    server_name example.com;
    include snippets/security-headers.conf;

    location ~* \.(css|js|jpg|jpeg|png|webp|svg|woff2)$ {
        add_header Cache-Control "public, max-age=2592000";
        include snippets/security-headers.conf;
    }
}

The header check

Check the headers of the home page loads the home page of your site three times from the server itself: twice like a visitor, so that the second request is answered by a page cache if there is one, and once with an extra query parameter that bypasses the cache. It then compares what arrives with your settings. Only your own address is requested; nothing is sent to reportedip.com. The check covers the home page; to look at other pages, files or the sign-in page use the network tab of the browser tools, curl -sI https://example.com/ or the free Security Headers tool.

Two further messages can appear instead of the table:

• "No security header arrives at the home page, neither from WordPress nor from the web server." Nothing is set anywhere. Switch on Send security headers and save, or check that your server configuration is active.
• "The home page could not be loaded" with an error message. The server cannot reach its own address: a password protection on a staging site, a firewall of the hosting that blocks requests from the server to itself, or a domain that points somewhere else. Check the headers from outside with the tools above.

The register on System Status raises the suggestion Cached pages miss the security headers when the headers are on, a page cache is active and Extended Protection is not running. It disappears once Extended Protection runs. If you use the web server configuration and have switched off Send security headers, it is not raised.

Troubleshooting

Last updated: 29. October 2026 · Maintained by the ReportedIP team