Skip to content

Home · Blog · HTTP security headers: what to configure on a site

Send a request

New format

HTTP security headers: what to configure on a site

HTTP headers are service fields in the server response: they tell the browser how to treat the page (content type, cache, redirect, security rules). Some of them directly cut XSS, clickjacking, and data-leak risks.

Below: a practical security-header set. The general request/response picture is in the HTTP protocol article; here the focus is protection. Before edits — config backup and a staging check.

Share
Telegram

What HTTP headers are

When a URL opens, the browser gets not only HTML but response metadata: `Content-Type`, `Location`, `Cache-Control`, cookie flags, security directives. Without them the protocol doesn’t know how to show the page safely.

Security headers don’t replace CMS updates and passwords. They’re a browser protection layer on top of normal server hygiene.

Before setup:

  • backup nginx/Apache/`.htaccess`
  • test on a site copy
  • list your domains, CDN, analytics, widgets

HTTP protocol HTTPS and SEO

HSTS: HTTPS only

`Strict-Transport-Security` tells the browser: for this host, use HTTPS only for a set time. It cuts risk of falling back to open HTTP and some downgrade attacks.

Enable after the certificate and redirects are stable. `includeSubDomains` and `preload` — on purpose: a bad preload is hard to undo.

Test yourself

Mini quiz: HTTP headers

Two checks.

1 HSTS without working HTTPS…
2 X-XSS-Protection as the base of protection…

Clickjacking and MIME: X-Frame-Options, X-Content-Type-Options

`X-Frame-Options` (and CSP `frame-ancestors`) limits embedding the site in other pages’ iframes — clickjacking protection. Typical values: `DENY` or `SAMEORIGIN`.

`X-Content-Type-Options: nosniff` stops the browser guessing a file type past the declared `Content-Type` — fewer surprises with script execution.

CSP: content policy

`Content-Security-Policy` sets where scripts, styles, images, and frames may load from. It’s the main modern tool against many XSS cases when set correctly.

Start by inventorying domains (your host, CDN, analytics, chat). Report-Only helps see violations without breakage. A sudden `default-src 'none'` without prep almost always breaks widgets.

Referrer-Policy and Permissions-Policy

`Referrer-Policy` limits how much URL goes into `Referer` on navigations — less path and query leakage. A common balance: `strict-origin-when-cross-origin`.

`Permissions-Policy` (formerly Feature-Policy) disables or limits powerful browser APIs (camera, mic, geolocation) when the site doesn’t need them.

Minimum set to start:

  • HSTS (after HTTPS)
  • X-Content-Type-Options: nosniff
  • frame-ancestors / X-Frame-Options
  • Referrer-Policy
  • a CSP draft in Report-Only

How to roll out and verify

Set headers in nginx/`add_header`, Apache/`Header set`, or the hosting panel. PHP in the template is a fallback — worse for static and cache.

After deploy check home, login pages, forms, and pages with widgets. Watch the console for CSP errors. Document the policy for the team so a new analytics script doesn’t break prod by surprise.

Site security .htaccess and 301

Practice

Security headers checklist

Staging first, then production.

0 / 7 done

FAQ

Where do you view headers?

DevTools → Network → document response, `curl -I https://site/`, online security-header scanners. Check the live HTTPS host.

Where do you set them?

In the web-server config (nginx, Apache/`.htaccess`), sometimes in the app (PHP `header()`, middleware). Prefer server/CDN — once for the whole site.

Is X-XSS-Protection still needed?

In modern browsers it’s outdated and can hurt. Rely on CSP, not the old XSS filter. Don’t treat it as the base of protection.

Will CSP break the site?

A strict CSP that ignores scripts — yes. Start with Report-Only or a soft policy, watch reports, then tighten.

Can you use HSTS without HTTPS?

No. First stable HTTPS and http→https redirect, then HSTS.

Does this affect SEO?

Indirectly: security and trust, less risk of hacks/spam. There’s no direct “header for page one.” Rankings follow site work; planned months after SEO starts.

Feature-Policy or Permissions-Policy?

The current name is Permissions-Policy (limits camera, geolocation, etc.). Older Feature-Policy still appears in guides.

HTTPS is on — and security headers are still empty?

We’ll add HSTS, nosniff, frame limits, and a CSP draft in Report-Only — staging first, widgets checked after deploy.

Discuss the task