πŸ“„
Webhosting

Setting up HTTP security headers for your website

πŸ“… 7 October 2026 ✏️ 7 October 2026 ⏱ 5 min leestijd

What are HTTP security headers, which ones do you need, and how do you set them up? A practical explanation with a step-by-step plan for a more secure website.

HTTP security headers are instructions that your server sends along with every page, so your visitor’s browser knows how to behave. They protect against common attacks such as clickjacking, cross-site scripting and the sneaky loading of content via insecure connections. In this article you’ll read which headers are important, what they do, and how to set them up via the .htaccess file or Plesk.

What are HTTP security headers?

Every time a browser requests your website, the server sends back a response containing not only the page itself, but also extra information in the form of headers. Security headers are a specific category of these: they tell the browser which resources may or may not be loaded, whether the page may be shown in a frame, and how strictly the browser should handle outdated security protocols.

Without these headers, the browser relies by default on fairly loose rules, which gives malicious actors room to, for example, load scripts from another website into your page. With properly configured headers, you close off that room as much as possible, without any cost to loading speed.

Serversends headers alongX-Frame, CSP…Browser applies rules

The server sends along the security rules, the browser enforces them.

The most important headers explained

You don’t need to know every existing header. A limited number covers most of the protection.

Content-Security-Policy (CSP) determines from which sources the browser may load scripts, styles and images. This is the most powerful header against cross-site scripting, but also the hardest to configure properly because you need to include all external resources (such as a CDN or analytics script).

X-Frame-Options prevents your website from being shown in an invisible frame on another site, a technique known as clickjacking. With the value SAMEORIGIN you only allow framing from your own domain.

X-Content-Type-Options with the value nosniff prevents the browser from guessing the file type of a download itself, which can be exploited to make malicious files appear harmless.

Referrer-Policy controls how much information about the originating page is sent along to external links, which can be privacy-sensitive.

Strict-Transport-Security (HSTS) forces browsers to always connect via HTTPS, even if someone accidentally types http://. Only set this up once you’re sure your entire site, including all subdomains, works properly over HTTPS.

πŸ’‘ Tip: Start with X-Frame-Options, X-Content-Type-Options and Referrer-Policy. These are easy to set up and almost never break anything. Build up CSP gradually afterwards.

Setting up headers: step-by-step plan

On an Apache server, you usually set up headers via the .htaccess file in your website’s root folder. If you use NGINX or LiteSpeed, this can also be done via the server configuration, but in Plesk you can often use the same .htaccess rules thanks to the Apache compatibility layer.

1

Open the .htaccess file

Go to your website’s file manager via Plesk and open (or create) the .htaccess file in the root folder.

2

Add the headers

Add the following lines to the file: Header set X-Frame-Options “SAMEORIGIN”, Header set X-Content-Type-Options “nosniff” and Header set Referrer-Policy “strict-origin-when-cross-origin”.

3

Test the website immediately

After saving, check whether your site still loads normally. If an embedded element suddenly stops working, this is usually due to an overly strict CSP rule.

4

Add CSP and HSTS later

Build up the Content-Security-Policy step by step by first testing in report-only mode, and only activate HSTS once you’re sure HTTPS works properly everywhere.

Testing and checking headers

After setting things up, you’ll want to know whether the headers really do reach the browser. Open your browser’s developer tools (usually with F12), go to the Network tab, reload your page and click on the main request. Under ‘Response Headers’ you’ll see exactly which headers are being sent.

Note that security headers are separate from your SSL certificate: HTTPS provides an encrypted connection, headers provide extra behavioral rules on top of that connection. Both together provide the best protection. If you’re unsure about your current hosting environment, take a look at the options for web hosting with Plesk, where you can manage these kinds of settings in a clear and organized way.

Frequently asked questions

Do security headers slow down my website?

No, headers are simple lines of text that have virtually no impact on your page’s loading time.

Can I set up headers without .htaccess?

Yes, depending on your server configuration this can also be done via the web server settings in Plesk or in your CMS, but .htaccess is the most direct method in Apache-like environments.

Does this also work with WordPress?

Yes, WordPress uses the same .htaccess structure, so the headers work just as well on a WordPress site as on a static website.

Is one incorrectly configured header dangerous?

An overly strict CSP can break parts of your site, but rarely leads to a security risk. Always test first before switching to a strict configuration.

Conclusion

HTTP security headers are an accessible way to add extra protection to your website against clickjacking, script injection and unwanted data sources. Start with the simple headers, test thoroughly, and then gradually build up a stricter Content-Security-Policy.

View web hosting β†’

Was dit artikel nuttig?