Security Headers: The Six Lines of Text That Protect Your Visitors

Your site has a padlock. Good. That is one protection, and it only covers the journey between the visitor and your server.

There are five more, and on most Kenyan business websites every one of them is switched off, because nothing switches them on by default. They are not plugins and they do not cost anything. Each one is a single line of text your server sends along with every page, invisible to visitors, read by their browser.

This guide explains what each line does in plain words, what it actually prevents, the exact text to add, and the one you should save for last because it breaks pages when rushed.

What a Header Is, Without the Jargon

When somebody opens your website, your server sends two things: the page, and a short set of notes about the page. Those notes are called response headers. The browser reads them before it draws anything.

Most headers are housekeeping, such as the file type and how long to keep a copy. A handful are instructions about safety: always use the encrypted version of this site, do not let another website put my pages inside theirs, do not guess what this file is, do not hand my addresses to other sites. Those are security headers.

Nobody sees them. That is exactly why they are missing from so many sites: nothing on the screen looks wrong without them.

The Six That Matter, and What Each Prevents

The weightings below are the ones our own free checker uses, out of 100, because not all six carry the same risk. What each header does is documented on MDN's HTTP headers reference, which is the source we built the tool from.

A note on the first one. HSTS is strong medicine: once a browser has seen it, it refuses the plain http address for as long as the max-age says. Only set it when every part of your site, and every subdomain, genuinely works over HTTPS. Our checker treats anything under six months as a half measure, because browsers forget a short lifetime quickly.

The Lines to Copy

For a normal business website, these are sensible values:

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

That is five of the six, and none of them will break a normal site. SAMEORIGIN rather than DENY because your own pages may legitimately frame each other. The sixth, Content-Security-Policy, has a section of its own below.

Where to Put Them: Cloudflare, Apache, Nginx, WordPress

Headers are set by whatever serves your site, so the place depends on your setup.

Cloudflare Pages or Workers

A _headers file at the root of your project, with a path and the headers indented beneath it:

/*
  X-Content-Type-Options: nosniff
  Referrer-Policy: strict-origin-when-cross-origin
  Strict-Transport-Security: max-age=31536000

This is how our own site does it, generated at build time.

Apache, including most cPanel hosting

In .htaccess, inside a mod_headers block:

<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"
</IfModule>

If editing .htaccess by hand makes you nervous, our free .htaccess generator has a "basic security headers" option that writes those three for you, and a separate HSTS option, in the right order and with a warning about what each one can break. It runs entirely in your browser and sends nothing anywhere.

Nginx

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;

WordPress on shared hosting

Use .htaccess if you can. If you cannot, a security plugin can send them for you, though a plugin is one more thing to keep updated and one more place for the setting to be lost in a theme change. Whichever route you take, check the result rather than trusting the plugin's tick mark.

The One That Breaks Pages

Content-Security-Policy is the most valuable of the six and the only one that can take your site down if you get it wrong. It lists where scripts, styles, images and fonts may load from, and the browser refuses everything else. Miss out the address your fonts come from and the fonts vanish. Miss out your analytics and it stops reporting.

So do it in this order:

Our checker tells the difference: a report-only policy is reported as being tested, not as protection, because it blocks nothing.

Two Things Our Checker Also Looks For

Beyond the six, two details come up on almost every site we test in Kenya.

Headers that announce your software version. A response that says X-Powered-By: PHP/7.4.3 tells anybody scanning exactly which known weaknesses to try. There is no benefit to a visitor, so our checker takes points off for it. Remove the header, or at least the version number. If you want the wider context on why an old PHP version is a problem rather than a detail, we covered that in our piece on October's PHP security wave.

Cookies without Secure and HttpOnly. Without Secure a cookie can travel over plain http; without HttpOnly any script on the page can read it. Both flags belong on every cookie that your own scripts do not need to read, and that includes the login cookie on a WordPress site.

What a Grade Does Not Tell You

Any checker, ours included, can only read what your server sends. It cannot judge whether what you send is any good. That gap is worth understanding before you treat a letter as a verdict.

The clearest example is the Content-Security-Policy. Two sites can both send one and be in completely different positions. A policy that lists the handful of places your scripts genuinely come from is doing the job. A policy that permits every address, or that never mentions scripts at all, is a line of text that protects nobody. Plenty of checkers award the same marks to both, which is why a good grade on a weak policy is so common.

The other trap is 'unsafe-inline'. It is the setting that lets code written directly into the page run, and most sites need it because their pages are built that way. It is also the exact door an injected script walks through, so a policy that keeps it is doing much less than it appears to. Ours flags it rather than waving it through, and the fix is to move that code into separate files.

So treat any grade, from any checker, as a list of the things that are missing, not as a certificate that you are safe. Headers close whole categories of attack in the visitor's browser. They do not patch an out-of-date plugin, and they do not make up for a weak password.

Check Yours in a Minute

Our free security headers checker reads what your site sends right now, grades it A to F, shows the exact value of each header you have, flags the ones that give away your software version or leave cookies exposed, and prints the line to add for each one that is missing. No signup, nothing stored on your site, and it changes nothing.

Two sibling tools are worth running in the same sitting: the SSL checker for the certificate itself, redirects and mixed content, and the website checkup for the broader picture including speed and meta tags. If you would rather work through the whole list at once, we set it out in ten things you can check about your own website in ten minutes.

Frequently Asked Questions

What are security headers?

They are short instructions your server sends with every page, alongside the page itself, telling the visitor's browser how to protect them. Six matter: Strict-Transport-Security, Content-Security-Policy, X-Frame-Options, X-Content-Type-Options, Referrer-Policy and Permissions-Policy. Visitors never see them, and most websites send none of them.

Will security headers stop my website being hacked?

No, and anyone who says so is selling something. They do not patch an out-of-date plugin or guard a weak password. What they do is limit the damage when something does get in, and block whole categories of attack that run in the visitor's browser, such as clickjacking and injected scripts.

Which security header should I add first?

Strict-Transport-Security, if your site is fully on HTTPS, then X-Content-Type-Options, X-Frame-Options and Referrer-Policy. Those four are one line each and almost never break anything. Leave Content-Security-Policy until last, because a wrong policy stops your own scripts and styles from loading.

Does adding security headers slow a website down?

No. They are a few hundred bytes of text sent with each response, and HSTS usually makes repeat visits slightly faster because the browser goes straight to HTTPS instead of being redirected.

How do I check the security headers on my site?

Use a checker that reads your live response. The free WPfoss security headers checker grades a site from A to F, shows the value of every header you send, flags headers that announce your software version, and gives the exact line to add for each one that is missing. No signup, and nothing is changed on your site.