Website security headers, explained simply

By the FarSec team · Updated 2026-11-12

In short: security headers are short instructions your web server sends with every page, telling the visitor's browser how to protect them. They cost nothing, need no new software and are usually set in one place (your hosting panel, .htaccess, Nginx config or Cloudflare). In our review of 130 well-known Pakistani companies, 54% had no Content-Security-Policy, 41% had no clickjacking protection and 38% had no HSTS. Start with HSTS, X-Frame-Options and X-Content-Type-Options, then add a Content-Security-Policy carefully.

Why this matters for a business website

Your website is often the first thing a customer, bank or supplier checks. If an attacker can inject a script into it, frame it inside a fake page, or push visitors onto an unencrypted connection, they can steal form data, show fake payment details or damage trust in your name. Security headers close several of these doors at once, and auditors, banks and enterprise customers increasingly look for them in vendor reviews.

The six headers to know

Strict-Transport-Security (HSTS): tells browsers to always use HTTPS for your site, so a visitor on public Wi-Fi cannot be quietly downgraded to an unencrypted connection. Start with max-age=31536000 (one year).
Content-Security-Policy (CSP): lists where scripts, styles, images and fonts may load from. If a hacker injects a script from another site, the browser refuses to run it. This is the most powerful header and the one that needs the most care.
X-Frame-Options (or CSP frame-ancestors): stops other sites from showing your pages inside a hidden frame, which is how clickjacking tricks users into clicking buttons they cannot see. DENY or SAMEORIGIN is enough for most sites.
X-Content-Type-Options: nosniff: stops browsers from guessing file types, which blocks some tricks that turn an uploaded file into a script.
Referrer-Policy: controls how much of your page address is shared with other sites when visitors click a link. strict-origin-when-cross-origin is a sensible default.
Permissions-Policy: switches off browser features your site does not use, such as camera, microphone and location, so injected code cannot ask for them.

Check your site in one minute

Open your website in Chrome or Edge, press F12, go to the Network tab and reload the page.
Click the first item (your page) and look at Response Headers.
Look for the six names above. Anything missing is a quick win.

Free online checkers that read the same public headers also exist. While you are there, check that http:// redirects to https:// and that the server does not announce its exact software version (for example Apache/2.4.41), which helps attackers find known flaws.

A safe order to switch them on

Week 1: add X-Content-Type-Options, Referrer-Policy and X-Frame-Options. These almost never break anything.
Week 1: make sure every page and image loads over HTTPS, then add HSTS with one year. Only add includeSubDomains once you are sure every subdomain (mail, portal, old test sites) works over HTTPS.
Week 2: add Permissions-Policy for features you do not use.
Weeks 2-4: start CSP in report-only mode (Content-Security-Policy-Report-Only), watch the browser console for what it would block, list the outside services you really use (analytics, chat widget, payment page, fonts), then switch to the enforcing header.

Where to set them

cPanel / Apache hosting: a few Header always set lines in the site's .htaccess file.
Nginx: add_header ... always; lines in the server block.
Cloudflare: HSTS under SSL/TLS settings; other headers with a Transform Rule (response headers).
WordPress: the hosting or Cloudflare route is better than a plugin, because it also covers files that WordPress does not serve.

Always test on a staging copy or at a quiet time, and keep a copy of the old settings so you can roll back in minutes.

Common mistakes

Copying a strict CSP from another site: it blocks your own chat widget, analytics or payment page. Use report-only first.
Turning on HSTS preload too early: it is hard to undo. Leave it until everything has run on HTTPS for months.
Setting headers only on the home page: they must apply to every page and file.
Forgetting old subdomains and microsites, which are often the weakest part of a company's web presence.

Headers are one part of a secure website. Pair them with patching (see our VAPT guide), email protection (DMARC guide) and good backups.

Free check for Pakistani businesses

Send your domain to info@farsec.com.pk and we will reply with a free one-page check of your email protection (SPF, DKIM, DMARC) and website basics, including these headers. We use public information only; nothing is tested without your written permission. If you would like us to set the headers for you and confirm nothing breaks, ask in the same email.

Want a second pair of eyes? FarSec checks businesses in Pakistan for exactly these gaps and helps fix them. Email info@farsec.com.pk and tell us what worries you.