Website Security Headers Explained (and How to Add Them)

Security headers are one of the highest-impact, lowest-effort improvements you can make to a website. They’re instructions your server sends with every page telling the browser how to behave safely — and adding them is usually a config change, not a rebuild. Yet most sites still skip them: only around one in five pages ships a Content-Security-Policy, the single strongest defence against cross-site scripting (HTTP Archive Web Almanac 2025). This guide explains each header in plain English, what it actually prevents, and how to roll them out without breaking your site. (To see which your site is missing right now, run our free Website Security Check.)

What are HTTP security headers, exactly?

HTTP security headers are response headers your server sends with every page, telling the browser how to behave defensively — which scripts to trust, whether to allow framing, whether to force HTTPS. They’re free, need no code rewrite, and form a defence-in-depth layer in front of your app. Think of them as standing instructions your website gives every visitor’s browser.

They don’t replace secure code, patched software or a firewall. What they do is neutralise whole categories of attack at the browser, before any damage reaches your users. A good baseline is published by the OWASP Secure Headers Project, the community standard most teams work from. Because headers are set at the server or platform edge, the same policy protects every page on the site at once — there’s no per-page code to maintain.

Why should a Singapore SME care about headers?

Because the threat is rising and the legal exposure is real. Singapore recorded a 49% surge in reported phishing cases and a 67% jump in infected infrastructure in 2024, with professional-services SMEs disproportionately targeted (CSA Singapore Cyber Landscape 2024/2025, 2025). Headers won’t stop every attack, but they close common, cheap-to-exploit gaps.

The compliance angle matters too. The PDPA applies to all private-sector organisations regardless of size: a five-person shop carries the same breach-notification duty as a bank. A breach affecting 500 or more individuals, or one likely to cause significant harm, must be reported to the PDPC within three calendar days of assessing it as notifiable (PDPC). Penalties currently reach up to S$1 million, or 10% of annual turnover for larger organisations. Security headers are a low-cost, demonstrable “reasonable security arrangement” — the kind of control that reads well in a vendor questionnaire or a Protection Obligation narrative. Our PDPA compliance checklist puts that obligation in context.

The security headers reference table

Here’s the whole picture on one screen: what each header does in plain English, the attack it stops, and a sensible starting value drawn from the OWASP Secure Headers Project. Treat these as starting points, not blind copy-paste — a strict Content-Security-Policy in particular needs tuning to your own site.

Source: recommended values adapted from the OWASP Secure Headers Project (accessed Jun 2026) and MDN Web Docs. Adjust to your own site; test a strict CSP in Report-Only mode before enforcing it.

The headers, one by one

Each header below does one job. We’ve kept the explanations plain but technically correct, with the values most teams start from. Where a header is widely misunderstood — X-Frame-Options especially — we’ve flagged it, because most listicles still get that one wrong.

HSTS (Strict-Transport-Security)

HSTS tells browsers to only ever connect over HTTPS and to auto-upgrade any HTTP attempt. That blocks protocol-downgrade and man-in-the-middle attacks, and stops users clicking through fake-certificate warnings. max-age sets how long, in seconds, the browser remembers this; includeSubDomains extends it to subdomains. Add preload only once you’re certain HTTPS works everywhere — it bakes your domain into browsers and is slow to reverse.

Content-Security-Policy (CSP)

CSP is an allowlist of where the browser may load scripts, styles, images and frames from; anything not listed is blocked. It’s the single most powerful header against cross-site scripting — an injected script simply won’t run. It’s also the easiest to break your own site with. Roll it out via Content-Security-Policy-Report-Only first, watch what it would have blocked, then enforce. That matters because injection-class flaws, which CSP mitigates, appeared in over 90% of applications tested for the OWASP Top 10 (2021).

X-Frame-Options (now obsolete)

X-Frame-Options stopped your pages being loaded inside an iframe on a malicious page — the clickjacking trick where users are fooled into clicking things they can’t see. The accuracy point most guides miss: it is now obsolete. MDN states plainly that modern browsers “will ignore the header completely” for the deprecated ALLOW-FROM directive (MDN Web Docs). The modern replacement is the CSP frame-ancestors directive. In practice, send X-Frame-Options: DENY for legacy coverage and set frame-ancestors 'none' for everything else.

X-Content-Type-Options

Set to nosniff, this stops the browser “guessing” a file’s type and, say, executing an uploaded text file as a script. There’s only one value, it almost never breaks anything, and it closes a genuine MIME-sniffing gap. If you add just one header today, make it this one — it’s the cheapest win on the list.

Referrer-Policy and Permissions-Policy

Referrer-Policy controls how much of your URL is sent to other sites when a user clicks away — without it, full URLs including query strings can leak. A sensible default is strict-origin-when-cross-origin. Permissions-Policy lets you switch off browser features (camera, microphone, geolocation) your site doesn’t use, shrinking the attack surface. Per the Web Almanac, Permissions-Policy ships on barely 3.7% of pages — setting it is an easy way to stand out.

Headers to remove

Some headers help attackers, so the fix is to delete them. Server, X-Powered-By, X-AspNet-Version and X-Generator leak your software and version numbers, handing attackers a shortlist of known exploits to try. Strip them at the server or CDN. The Cross-Origin family (Cross-Origin-Resource-Policy and friends) is worth a look once the basics are in place.

How do you actually add security headers?

Headers are set at the server or platform level, not in page code — which is why a non-developer can often add most of them in an afternoon. The Web Almanac 2025 puts adoption of the simplest header, X-Content-Type-Options, at roughly half of all pages, so being thorough genuinely sets your site apart. Where you configure them depends on your stack.

• Reverse proxy — Nginx (add_header), Apache (Header set) or Caddy. One config block covers every site behind it.
• CDN / edge — Cloudflare, Fastly or similar let you add response headers in the dashboard or via rules, with no server access needed.
• Host config — on Vercel or Netlify a small config file (vercel.json / _headers) sets them per route.
• App / framework — most frameworks have middleware or a helper (e.g. Helmet for Express) to set headers in code if you prefer.

The order you roll out in matters more than the tooling. A safe sequence: (1) add X-Content-Type-Options, X-Frame-Options and Referrer-Policy — these almost never break anything; (2) confirm HTTPS works on every page and subdomain; (3) add HSTS without preload; (4) deploy CSP in Report-Only, review the reports, then (5) enforce it. Skipping straight to a strict CSP is the classic way to take your own site down, so don’t.

How do you check your own headers?

Use a free grader: paste your URL and it reports which headers are present and how they’re set. You can use our free website security check or the Mozilla HTTP Observatory. Both grade in seconds and tell you exactly what’s missing. Re-run after every change.

If you’d rather get a plain-English readout aimed at SME owners, our Website Security Check runs the same checks and flags missing headers in language you don’t need a developer to translate. Headers are one line on a longer list, though — our website security checklist for SG SMEs covers the wider picture, and handling customer data securely goes deeper on what sits behind the header layer.

When to bring in help instead of DIY

For most sites, adding headers is a config change you can do yourself in an afternoon, and you shouldn’t pay someone for what a dashboard toggle handles. The point where it’s worth bringing in a team is when the headers expose a deeper problem: a strict CSP keeps breaking because the site loads scripts from a dozen ad-hoc sources, an older application can’t serve clean headers without code changes, or the real question is how your app stores and handles customer data end to end.

That’s the work we do — we build security in by default rather than bolting it on, across web, mobile and enterprise systems. If your headers are a symptom of an ageing codebase, our note on legacy system modernisation covers the rebuild decision, and our software development services page shows how we approach hardening a stack properly. When you want it handled, talk to us.

About AppTech System — AppTech System is a Singapore custom-software team and the people behind the Automiq and BooknGo platforms, building web, mobile, AI and enterprise software for businesses in regulated industries. Talk to us.