Security Headers Every Business Website Needs

Many sites assume that switching on HTTPS is enough to call a connection secure. It is an excellent start, but it is not the whole story. The padlock in the address bar only tells the visitor that traffic between the browser and your server is encrypted. It says nothing about what the browser is allowed to do with your pages once they arrive. That second question is answered by a small set of HTTP response headers, and skipping them leaves the door open to several common attacks even though the padlock looks perfect.

The good news is that these headers are cheap. Adding them usually takes an afternoon, needs no new software, and permanently reduces the attack surface of your site. This guide explains what each header does, how to set it up, and the mistakes to avoid, so you can enable them with confidence instead of copying a snippet you do not understand.

How security headers work

Every time your server sends a page, it sends headers along with it: small instructions in the response that the browser reads before it renders anything. Security headers are instructions of the form "only ever use HTTPS for this domain", "do not let other sites frame this page" or "only run scripts that come from these sources". Browsers enforce them on the visitor's device, so they protect real people even when a bug in your code or a compromised third-party script would otherwise have caused harm.

Because they are enforced by the browser, they are a defense in depth measure. They do not replace secure code, updated software or strong passwords, which we cover in our website security checklist, but they limit the damage when something else goes wrong.

Strict-Transport-Security (HSTS)

HSTS tells the browser to connect to your site only over HTTPS, even if a visitor types http:// or follows an old link. Without it, the very first request can still travel over plain HTTP before your server redirects it, and that brief window is exactly what a man-in-the-middle attacker on a public network looks for.

The header carries a max-age in seconds. A common production value is two years (63072000 seconds). The optional includeSubDomains extends the rule to every subdomain, and preload allows you to request inclusion in the lists browsers ship with. Be careful with the last two: includeSubDomains will break any subdomain that does not have a valid HTTPS certificate, and preloading is difficult to undo. Start with a short max-age such as a few days, confirm nothing breaks, and then raise it.

Content-Security-Policy (CSP)

CSP is the most powerful and the most demanding header. It lets you list exactly which sources are allowed to provide scripts, styles, images, fonts and connections for your pages. If an attacker manages to inject a script tag, or a third-party script you rely on is compromised, a good policy stops the browser from loading or running it.

A minimal starting policy restricts everything to your own domain and then opens only what you need. Modern frameworks often need inline scripts to bootstrap, which is why many real-world policies begin with a looser script-src and are tightened later using nonces, unique values generated per request. The safest way to roll CSP out is in report-only mode first. In that mode the browser reports violations without blocking anything, so you can see what your site actually loads and fix the policy before enforcing it. Enforcing a strict policy blindly is a reliable way to break your contact form or your analytics on launch day.

X-Content-Type-Options

The value nosniff tells the browser to trust the declared content type of a file instead of guessing. Without it, a browser might decide that an uploaded text file is really a script and execute it. This header has no downside and takes one line to add.

Referrer-Policy

When a visitor clicks a link on your site, the browser may send the address of the page they came from to the destination. That address can contain information you would rather not share, such as internal paths or query strings. A sensible default is strict-origin-when-cross-origin, which sends the full address for requests within your own site but only the domain when leaving it, and nothing at all when the destination is less secure.

Permissions-Policy

This header controls access to powerful browser features such as the camera, microphone and geolocation. Even if your site never uses them, restricting them means a compromised script cannot quietly request them either. For most business websites the right setting is to disable everything you do not use.

Clickjacking protection: X-Frame-Options and frame-ancestors

Clickjacking works by loading your site invisibly inside another page and tricking the visitor into clicking your buttons. You prevent it by controlling who may put your pages in a frame. The older header is X-Frame-Options, with values such as SAMEORIGIN; the modern equivalent is the frame-ancestors directive inside CSP. Setting both is harmless and covers older browsers.

Setting the headers in Next.js

In a Next.js project you can define headers for all routes in next.config.ts:

async headers() {
  return [
    {
      source: "/(.*)",
      headers: [
        { key: "Strict-Transport-Security", value: "max-age=63072000; includeSubDomains" },
        { key: "X-Content-Type-Options", value: "nosniff" },
        { key: "Referrer-Policy", value: "strict-origin-when-cross-origin" },
        { key: "X-Frame-Options", value: "SAMEORIGIN" },
        { key: "Permissions-Policy", value: "camera=(), microphone=(), geolocation=()" },
      ],
    },
  ];
}

Setting the headers on Apache or cPanel hosting

If your site runs on shared hosting with Apache, you can usually add the same headers to the .htaccess file with the Header directive, as long as the mod_headers module is enabled:

<IfModule mod_headers.c>
  Header always set X-Content-Type-Options "nosniff"
  Header always set Referrer-Policy "strict-origin-when-cross-origin"
  Header always set X-Frame-Options "SAMEORIGIN"
</IfModule>

Cookies deserve the same care

Headers also control cookies. Any cookie that carries a session or an identity should be marked Secure so it is sent only over HTTPS, HttpOnly so scripts cannot read it, and SameSite so it is not attached to cross-site requests by default. These attributes are a few extra words in the cookie definition and block whole categories of session theft.

Test what you deploy

After enabling headers, verify them instead of assuming. Free scanners such as securityheaders.com and the Mozilla Observatory grade your response headers and explain each finding. Then click through your important flows in a real browser: forms, payments, embedded videos, chat widgets. A header that is too strict will show up as a console error, and it is far better to find it yourself than to hear about it from a customer.

Is there an SEO benefit?

Security headers are not a direct ranking factor, and it would be dishonest to claim otherwise. The benefit is indirect. Audit tools such as Lighthouse flag missing protections in their best-practices checks, a hacked site loses rankings and trust very quickly, and browsers increasingly warn visitors about insecure pages. Protecting the site protects the traffic you worked to earn. If you want this configured and monitored for you, our website support and maintenance service includes header reviews, and our web development service builds them in from the start.