Security headers
Security headers for a business website.
A few lines in every server response tell browsers to use HTTPS, not to guess file types and not to load your pages inside other sites. This guide shows which headers our own website sends, why, and what we have not set yet.
What they are
Instructions the browser follows on your behalf.
Security headers are part of the HTTP response, not of the page content. Visitors do not see them, but browsers apply them before showing anything. You can list them with curl -I followed by the address, or in the Network tab of the browser’s developer tools.
They do not replace updates, backups or strong passwords. They close a few common gaps that a website would otherwise leave open by default. The OWASP Secure Headers Project keeps an overview of the headers and their recommended values.
What we send
Five headers on every page.
01
Strict-Transport-Security
The browser connects only over HTTPS for the stated period, even if someone types or follows an http:// address.
02
X-Content-Type-Options: nosniff
The browser uses the file type the server declares and does not guess, so an uploaded file cannot be run as a script.
03
X-Frame-Options: SAMEORIGIN
Other websites cannot show your pages inside a frame, which blocks tricks that hide your buttons under someone else’s page.
04
Referrer-Policy
With strict-origin-when-cross-origin, other sites learn only your domain when a visitor follows a link, not the full address of the page.
05
Permissions-Policy
The site does not use the camera, microphone, location, payments or USB, so the header switches those features off for every page.
HSTS in steps
Raise the period only when you are sure.
A browser remembers Strict-Transport-Security for the whole period you set. If HTTPS stops working during that time, visitors cannot fall back to HTTP. That is why we raised it in steps: one day first, then six months, then a year, each time after checking that the site and its certificate work.
includeSubDomainsapplies the rule to every subdomain. Add it only when every subdomain you own, now and later, works over HTTPS. Other projects run on subdomains of our domain, so we left it out.- The preload list builds HTTPS into browsers themselves. It requires
includeSubDomains, and removal takes a long time, so it is a decision for the whole domain, not for one website.
Want help applying this to your website? See Website security or tell us about your project ↗
Where to set them
One place per header.
Our HTTPS, frame, file type and referrer headers come from the CDN in front of the server, so they also cover images, styles and scripts. The Permissions-Policy comes from the WordPress theme, because it only matters for pages.
Whichever place you choose, write it down and check that each header appears once. Two different values for the same header, one from the server and one from a plugin, make it hard to tell which one the browser follows.
What is still missing
A content security policy needs its own project.
A Content-Security-Policy lists the sources a page may load scripts, styles and images from. It is the strongest of these headers and also the easiest to get wrong: a missing source breaks a form or a menu without any warning to the site owner.
We started with the report-only variant, which shows in the browser what would be blocked without blocking anything. We list our own sources, check every type of page and switch to the enforcing header only when no page reports a problem.
Checklist
For your own website.
- Does every page and every static file return the HTTPS header?
- Did you raise the HSTS period in steps, after checking that HTTPS works everywhere?
- Is includeSubDomains set only if every subdomain works over HTTPS?
- Do pages send nosniff, a frame rule and a referrer policy?
- Does Permissions-Policy switch off features the site does not use?
- Is it written down where each header is set, and does each appear once?
- Do responses avoid revealing server or CMS versions?
- Did you start a content security policy in report-only mode and check every page type?
Headers are one part of regular care. Our WordPress maintenance checklist covers the checks before and after updates.
Want your headers checked?
Our WordPress care includes basic security checks. If you are planning a new website, the headers can be part of the agreed setup.
More guides
Keep reading.
Last updated:
Related services: Website security · WordPress care · Website development