What are headers and encryption?
When a browser requests a page, the server sends a few lines of extra information before the actual content. These HTTP headers state things like the file type or caching details. Some of them serve security. They decide whether the browser may use encrypted connections only, which sources it may load scripts from and whether another site may embed your website.
The encryption itself runs over HTTPS. Germany's Federal Office for Information Security (BSI) recommends transport encryption for web applications as a matter of principle. Headers build on that: according to MDN, some only take effect at all when the server delivers them over HTTPS.
Headers replace neither updates nor clean code. They add an extra layer of protection that does a lot for little effort. The OWASP Secure Headers Project collects recommendations on them. In the OWASP Top 10:2025, missing headers fall under Security Misconfiguration, which ranks second there.
How do security headers work?
The web server attaches the headers to every response. Your browser reads them and applies the rules to the page. If a Content-Security-Policy says, for example, that scripts may only come from your own domain, the browser blocks any injected third-party script.
Where you set the headers depends on how your website is built. On Apache you do it in the server configuration or in .htaccess, on nginx with the add_header directive. Many CDNs let you define your own rules for response headers, which helps if you have no access to the server. Some hosting providers and website builders offer a field for this in the customer menu. WordPress has extensions for it, though the web server is usually the better place, because the headers then also apply to images and files. Set each header in one place only.
The key building blocks
Strict-Transport-Security (HSTS)
HSTS tells the browser to open a domain over HTTPS only from now on. The max-age value states in seconds how long the browser remembers this, and includeSubDomains extends the rule to all subdomains. Raise max-age in stages, for example from 300 to 604800 and then 2592000 seconds, as the operators of the HSTS preload list recommend. With max-age=0, browsers forget the rule again.
Content-Security-Policy (CSP)
The CSP defines the sources from which the browser may load scripts, images, fonts and other resources. It is the most important protection against XSS. With upgrade-insecure-requests, the browser switches HTTP addresses to HTTPS automatically. MDN recommends starting with the Content-Security-Policy-Report-Only header, which reports violations without blocking anything.
Protection against embedding
In clickjacking, an attacker loads your page invisibly into a frame on their own site. X-Frame-Options with DENY or SAMEORIGIN prevents this. The CSP directive frame-ancestors is more comprehensive, and its value 'none' works roughly like DENY. According to MDN, frame-ancestors only works as a real header and has no effect in a meta tag.
X-Content-Type-Options
The value nosniff forbids the browser from guessing the file type on its own. An uploaded text file therefore cannot suddenly run as a script. The header has practically no side effects and belongs on every website.
Referrer-Policy and Permissions-Policy
The Referrer-Policy controls how much a browser reveals about where a visitor came from when they click an external link. With strict-origin-when-cross-origin, other sites only receive the domain. The Permissions-Policy decides whether the page and embedded content may use the camera, microphone or location.
Common mistakes
- HSTS with a long lifetime from the start: a subdomain without a valid certificate then stays blocked for visitors until max-age runs out.
- preload without a plan: being added to the preload list is hard to undo, and removal takes months.
- A CSP enforced straight away: forms, maps or the cookie banner stop working.
- 'unsafe-inline' for scripts: the CSP then loses a large part of its XSS protection.
- Headers on the home page only: subpages, error pages and redirects stay unprotected.
- Duplicate headers from server and CDN that contradict each other.
- X-XSS-Protection copied from old tutorials: browsers have removed the filter behind it, and MDN advises using CSP instead.
How to check
The quickest way is the terminal with curl -I https://example.com. Its response lists all headers of the home page. Without a terminal, open the browser's developer tools with F12, switch to "Network", reload and click the first document. Under "Response headers" you will find the same information.
Look for Strict-Transport-Security, Content-Security-Policy, X-Content-Type-Options, Referrer-Policy and protection against embedding. Also check whether every http:// address redirects to https:// and whether the certificate is valid. The console shows mixed content warnings and CSP violations while the policy runs in test mode. Repeat the check on a few subpages and after every change to your server, CDN or hosting.
Articles on this topic
Frequently asked questions
Which security headers does every website need?
The basic set is Strict-Transport-Security, Content-Security-Policy, X-Content-Type-Options, Referrer-Policy and protection against embedding through X-Frame-Options or frame-ancestors.
Does HTTPS make a website secure?
HTTPS protects the transfer between browser and server. It does not fix gaps in plugins, weak passwords or exposed files.
What does HSTS preload mean?
The domain is added to a list that browsers have built in. To qualify, you need a max-age of at least 31536000 seconds and includeSubDomains.
Do security headers slow down loading?
Headers make hardly any difference to loading time. You can read more about speed in the article Improve website speed.
Sources: Germany's Federal Office for Information Security (BSI); MDN Web Docs; OWASP Secure Headers Project; OWASP Top 10:2025; operators of the HSTS preload list.