Website Security Headers Checklist: 6 Headers to Set

November 4, 2026 · Lizzard Solutions

Website SecuritySecurity HeadersHTTPSContent Security PolicySmall BusinessWeb Development

By Nemanja Vukmirović, Lizzard Solutions. Last updated November 4, 2026.

Your website shows a padlock, so it's secure, right? Not quite. HTTPS encrypts the connection, but it doesn't tell the browser how to protect your visitors from clickjacking, injected scripts or leaked URLs. That's the job of a few lines most small business sites never send.

This website security headers checklist covers the six headers worth setting, safe starting values you can copy, how to test them in two minutes, and the mistakes that break a site. As a worked example, we'll show the real headers our own site sends.

---

What Are Website Security Headers?

Website security headers are HTTP response headers that a web server sends alongside each page to tell the browser how to behave securely: always use HTTPS, which scripts may run, whether the page may be framed by other sites, and how much information to share with external links.

Visitors never see them, and they don't change your design. The OWASP Secure Headers Project keeps a vendor-neutral list of recommended headers, and MDN Web Docs documents how each one works in every major browser.

Action for today: make sure your whole site loads over HTTPS. If it doesn't, a free certificate from Let's Encrypt or your host comes first.

---

The 6 Security Headers Every Small Business Site Needs

Here's the short list, what each header prevents, and a sensible starting value. Every value is documented on MDN, linked in the sections below.

1. Strict-Transport-Security (HSTS)

HSTS tells the browser to use HTTPS for your domain for a set period, even if someone types http:// or clicks an old link. MDN's HSTS reference explains max-age (in seconds, so 31536000 is one year) and includeSubDomains. Only add preload after reading the requirements on hstspreload.org, because removing a domain from the preload list is slow.

2. Content-Security-Policy (CSP)

CSP is the most powerful header and the easiest to get wrong. It lists which sources may load scripts, styles, images and frames. Anything not listed is blocked, which stops many injected-script attacks. See MDN's CSP guide for every directive.

3. Clickjacking protection: frame-ancestors

The CSP directive frame-ancestors controls which sites may embed your pages in a frame. MDN notes it supersedes the older X-Frame-Options header, but sending both is harmless and covers older browsers.

4. X-Content-Type-Options

A single value, nosniff, tells the browser to trust the declared file type instead of guessing. It's almost never risky to add.

5. Referrer-Policy

When a visitor clicks an external link, the browser can send the page address they came from. Referrer-Policy with strict-origin-when-cross-origin sends only your domain to other sites, not full URLs that might contain search terms or order IDs.

6. Permissions-Policy

Permissions-Policy switches off browser features your site doesn't use, such as camera, microphone and geolocation. If a third-party script is ever compromised, it can't quietly ask for them.

Action for today: list which of these six headers your site sends today. The test in the next section takes two minutes.

---

How to Check Your Security Headers in 2 Minutes

1. Enter your homepage in securityheaders.com. It lists missing headers and gives a letter grade.
2. Run Mozilla's HTTP Observatory for a second opinion with explanations for each test.
3. In Chrome or Firefox, open DevTools, go to the Network tab, reload the page, click the first request and read the Response Headers.
4. From a terminal, run curl -I https://yourdomain.com to see the raw headers.

Action for today: save a screenshot of your current result so you can compare after changes.

---

Worked Example: The Headers Our Own Site Sends

Here's what curl -I https://lizzardsolutions.com returned on November 4, 2026. We shortened the script list in the CSP, which in reality names each analytics and booking service the site uses.

strict-transport-security: max-age=31536000; includeSubDomains; preload
content-security-policy: default-src 'self'; script-src 'self' https://www.googletagmanager.com ...; frame-ancestors 'self'; base-uri 'self'; form-action 'self'; object-src 'none'
x-content-type-options: nosniff
referrer-policy: strict-origin-when-cross-origin
permissions-policy: geolocation=(), microphone=(), camera=()
x-frame-options: SAMEORIGIN

Three things are worth copying. HSTS covers subdomains. The CSP sets object-src 'none', base-uri 'self' and form-action 'self', which close common injection paths at almost no cost. And frame-ancestors plus X-Frame-Options together block clickjacking in old and new browsers.

The trade-off is maintenance: every new tool, such as a chat widget or ad pixel, has to be added to the CSP or it simply won't load. That's why a CSP needs an owner, not a one-time setup.

Action for today: compare your own headers with this example and note the gaps.

---

Where to Add Security Headers (By Platform)

A starting set that rarely breaks anything looks like this. Note that the CSP is in report-only mode, so it logs problems without blocking them:

Strict-Transport-Security: max-age=31536000; includeSubDomains
X-Content-Type-Options: nosniff
Referrer-Policy: strict-origin-when-cross-origin
Permissions-Policy: geolocation=(), microphone=(), camera=()
Content-Security-Policy-Report-Only: default-src 'self'; frame-ancestors 'self'; object-src 'none'; base-uri 'self'; form-action 'self'

Action for today: find out where your site's headers are controlled: hosting panel, CDN or code.

---

Common Mistakes That Break Websites

• Enforcing CSP on day one. Analytics, fonts, maps and payment widgets stop loading. Use Content-Security-Policy-Report-Only for a week or two first.
• Adding preload too early. Preloading is close to permanent. Wait until HSTS has run without problems.
• Headers on the homepage only. Set them at server or CDN level so every page, including error pages and files, gets them.
• Copying someone else's CSP. It lists their tools, not yours. Build yours from what your site actually loads.
• Relying on outdated headers. MDN advises against X-XSS-Protection; a proper CSP replaces it.
• No retest after changes. Check forms, checkout, login and embedded videos after each change.

Headers are one part of the picture. Our website speed and security check guide covers the rest, and cybersecurity for small business covers passwords, updates and staff habits.

Action for today: pick the one header you're missing that carries the lowest risk, usually X-Content-Type-Options, and add it.

---

Website Security Headers Checklist

• ☑ The whole site and all subdomains load over HTTPS
• ☑ Strict-Transport-Security is set with a max-age of at least several months
• ☑ X-Content-Type-Options: nosniff is present
• ☑ Referrer-Policy is strict-origin-when-cross-origin or stricter
• ☑ Permissions-Policy disables features you don't use
• ☑ Clickjacking is blocked with frame-ancestors (and X-Frame-Options)
• ☑ A CSP is running, at least in report-only mode
• ☑ Headers are set at server or CDN level, not per page
• ☑ Forms, analytics and payments were retested after changes

Security headers rarely slow a site down, but changes to your CDN can, so it's worth rechecking load times with our website speed optimization guide. For the full picture of what to review, see the free website audit checklist.

Action for today: go through the nine boxes and plan the missing ones for this week.

---

Website Security Headers: FAQ

What are website security headers?

Website security headers are HTTP response headers a server sends with each page to tell the browser which protections to apply, such as forcing HTTPS, limiting which scripts may run, blocking framing by other sites and limiting referrer data. Visitors don't see them, and they don't change how the site looks.

Which security headers should a small business website have?

A practical baseline is Strict-Transport-Security, Content-Security-Policy (with frame-ancestors), X-Content-Type-Options, Referrer-Policy and Permissions-Policy. X-Frame-Options can be added for older browsers. Start with the low-risk ones and introduce CSP in report-only mode.

Can security headers break my website?

Yes, mostly Content-Security-Policy and HSTS. A strict CSP can block analytics, fonts or payment widgets, and HSTS breaks any subdomain that doesn't support HTTPS. Test in report-only mode, change one header at a time and retest key pages.

How do I check my website's security headers?

Enter your URL in securityheaders.com or Mozilla's HTTP Observatory, or open your browser's DevTools Network tab and read the response headers of the page. From a terminal, curl -I followed by your URL shows them directly.

---

A website security headers checklist takes an afternoon to work through and closes gaps HTTPS alone leaves open. Test, add the low-risk headers, introduce CSP carefully, and retest. Want a second pair of eyes? Our website security check reviews headers, HTTPS and other basics.