Every time someone visits your website, their browser and your server exchange a series of messages before the page even appears. These messages include HTTP headers -- small bits of text that give the browser instructions about how to handle the page content. Some of these headers are purely functional, telling the browser what type of content is being sent. Others are there specifically for security, telling the browser to enable protections that prevent common attacks.
Security headers are not optional extras. They are a fundamental layer of website defence, and most small business websites we scan are missing at least two or three of them. Let's walk through what they are and why they matter.
What are HTTP headers in simple terms?
Think of HTTP headers like the instructions on a parcel. When your website sends a page to a visitor's browser, it sends it as a package. The headers are the labels on that package saying things like "handle with care" or "do not open unless the recipient matches." Without the right labels, the delivery person (the browser) does not know to take extra precautions.
Security headers are a specific group of these instructions that tell browsers to activate built-in protections against known attack types. They are set on your web server and sent automatically with every page load. You do not need to change your website code to add them.
The six security headers your website needs
There are dozens of HTTP headers in existence, but six of them are specifically designed to protect your website and its visitors. Here is what each one does.
1. Strict-Transport-Security (HSTS)
When a visitor types your website address into their browser, the browser first tries to connect over plain HTTP before redirecting to HTTPS. That brief moment before the redirect is an opportunity for an attacker to intercept the connection. HSTS tells the browser to always use HTTPS, skipping that vulnerable first step entirely.
Without HSTS, every visit to your site starts with an insecure connection that can be hijacked. The NCSC recommends enabling HSTS on all websites that can be hijacked. This is called a "downgrade attack" and it is surprisingly easy to execute on public Wi-Fi networks -- the kind your customers use in coffee shops and hotels every day.
2. X-Frame-Options
This header prevents your website from being loaded inside a frame (an iframe) on someone else's website. Why does that matter? Because an attacker can load your site invisibly inside their own page, position it under a fake button, and trick your users into clicking things they did not intend to click. This is called clickjacking, and it can be used to perform actions on your site while the victim thinks they are clicking something completely different.
Setting X-Frame-Options to DENY or SAMEORIGIN stops this attack dead.
3. X-Content-Type-Options
Browsers sometimes try to be clever. If you serve a file and say it is plain text, the browser might look at the content and decide it is actually a script, then execute it. This is called MIME-type sniffing, and it can turn an innocent uploaded file into a running script on your site.
Setting this header to nosniff tells the browser to trust the content type you declared and never guess. It is a single line of configuration that closes a genuine attack vector.
4. Content-Security-Policy (CSP)
CSP is the most powerful security header, and the one most often missing or misconfigured. It tells the browser exactly which sources are allowed to load content on your page. You can specify which domains are allowed to serve scripts, stylesheets, images, fonts, and more.
Without CSP, an attacker who finds a way to inject a script tag into your page can load malicious JavaScript from any domain. With a properly configured CSP, the browser will block that script because it comes from a domain you did not authorise. CSP is your strongest defence against cross-site scripting (XSS) attacks.
5. Referrer-Policy
When a visitor clicks a link on your site to go to another website, the browser normally sends the full URL of your page as the "referrer." That URL might contain sensitive information like search queries, session tokens, or user IDs. The Referrer-Policy header controls how much referrer information is shared.
Setting it to strict-origin-when-cross-origin means your full URL is only sent when the visitor stays on your site. When they go to an external site, only your domain name is shared -- no paths, no queries, no sensitive data leaking to third parties.
6. Permissions-Policy
Modern browsers can access device features like the camera, microphone, location, and speakers. Permissions-Policy lets you declare which features your site is allowed to use -- and, more importantly, which ones it is not. Even if an attacker manages to inject a script into your page, they cannot activate the camera or microphone if you have explicitly denied those permissions.
For most business websites, you do not need camera or microphone access at all. Denying them by default is a straightforward security win.
What happens when security headers are missing?
Missing headers do not cause visible errors. Your website will load normally and look fine to you and your visitors. The problem is that the browser's built-in security protections are not activated, leaving known vulnerabilities open for exploitation.
In practical terms, missing headers mean:
- Connections can be intercepted on public networks (no HSTS)
- Your site can be embedded in attack pages (no X-Frame-Options)
- Uploaded files can be executed as scripts (no X-Content-Type-Options)
- Injected scripts run freely from any source (no CSP) — the OWASP testing guide covers these attack vectors
- Sensitive URL data leaks to third-party sites (no Referrer-Policy)
- Device features like camera and microphone can be silently accessed (no Permissions-Policy)
None of these issues show up in your analytics or error logs. The only way to know is to check.
How to check your security headers
The quickest way to find out which headers your site is sending is to use an automated scanner. A PulseShield free scan checks all six security headers plus your SSL configuration, cookie settings, email authentication records, and more. You get a full PDF report showing exactly what is present, what is missing, and what each issue means for your security.
If you want a quick manual check, open your browser's developer tools (press F12), go to the Network tab, reload your page, and click on the first request to your domain. Look at the Response Headers section. If you do not see the headers listed above, they are not set.
Adding security headers to your site
Security headers are configured on your web server, not in your website code. The exact method depends on your hosting setup:
- Apache: Add headers to your
.htaccessfile using theHeader always setdirective - Nginx: Add headers to your server block using the
add_headerdirective - WordPress: Many security plugins handle header configuration, or you can add them to your
.htaccessfile - Managed hosting: Some hosts provide header settings in their control panel
The configuration is not complicated, but getting the values right matters. A misconfigured CSP can break parts of your site, while an HSTS header that is too aggressive can make your site inaccessible if your SSL certificate expires. It is worth getting right, and worth checking after any changes. Our monitoring plans track your headers continuously so you know immediately if anything changes.