HTTP Response Headers

HTTP response headers can protect your website against attack. Here are the response headers that I consider to be the most important.

The Strict-Transport-Security HTTP response header lets a website tell browsers that it should only be accessed using https for a set period of time, instead of using http.

Recommended setting: Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

See Mozilla Strict-Transport-Security
Note: The max-age in seconds is subjective.

The X-Frame-Options HTTP response header can be used to indicate whether or not a browser should be allowed to render a page in a frame, iframe or object. Sites can use this to avoid framejacking attacks, by ensuring that their content is not embedded into other sites.

Recommended setting: X-Frame-Options: SAMEORIGIN

See Mozilla X-Frame-Options

The X-XSS-Protection response header is a feature of Internet Explorer, Chrome and Safari that stops pages from loading when they detect reflected cross-site scripting (XSS) attacks.

Recommended setting: X-XSS-Protection: 1; mode=block

Note: Newer browsers have disabled XSS filtering, making this header irrelevant. It has generally been replaced by Content-Security-Policy, which can break inline scripts. Therefore, I don't use the Content-Security-Policy header. See Mozilla X-XSS-Protection

The X-Content-Type-Options response header is a marker used by the server to indicate that the Multipurpose Internet Mail Extensions (MIME) types advertised in the Content-Type headers should not be changed by the browser.

Recommended setting: X-Content-Type-Options: nosniff

See Mozilla Content-Type

MIME sniffing is a technique used by some web browsers to examine the content of a particular asset. This is done for the purpose of determining an asset's file format. (E.g. is the file type jpg or html?)

MIME type examples: Content-Type: image/jpg Content-Type: text/html

If your web server is a Debian/Ubuntu type, then enter the following command to begin entering these settings:


Now enter the following code:


Afterwards, go to /etc/apache2/sites-available and find your ssl.conf file. Enter the following code:


You can check the status of your website's HTTP headers by using the WebTracker.one whois search.

A search done for this site returns these results:

More on Content-Security-Policy

The whole idea behind the Content-Security-Policy header is that inline JavaScript is dangerous. An attacker might insert malicious JavaScript into a form and cause issues. The attacker's code is blocked by not allowing inline code.

The problem, however, is that JavaScript must sometimes be run inline to work properly. I have some scripts that simply don't work if placed in an external file.

It is possible to enable inline scripts in the Content Security Policy, but this goes against the purpose of this http header. As such, I don't use the policy. Instead, I concentrate on removing scripting language from any web forms. Here is an example:


The following is an example of a Content Security Policy that allows a site to use inline code, allows images from all sources, and permits youtube, twitter, Bitchute, Rumble and Brighteon.

#Content-Security-Policy <IfModule mod_headers.c> Header set Content-Security-Policy default-src 'unsafe-inline' 'unsafe-eval' https://mywebsite.com https://cdn.syndication.twimg.com platform.twitter.com; img-src *; frame-src *.youtube.com *.bitchute.com *.rumble.com *.brighteon.com https://cdn.syndication.twimg.com platform.twitter.com; </IfModule>
The following site will check your header for validity - CSP Validator

Note: There are more sophisticated methods of dealing with the inline code issue, but I chose not to bother because my sites have no real need for the Content-Security-Policy - Allow Inline Scripts using a Nonce or Hash.