Configuring HTTP headers to make your application more secure

Initially, during communication between an application on the web server and the client browser, the server and the client exchange messages that travel over the Internet. We generically call the exchanged messages “packets”, and each application packet contains, at its beginning, markers called “headers” or HTTP protocol header fields [1]. Thus, these fields define how a web communication operation will occur. In this post, we will talk about how to improve the security of your applications by implementing some adjustments to the HTTP headers .

Is this enough?

Obviously, simply implementing HTTP headers does not make an application secure. However, when implemented correctly, they can significantly improve the protection of applications against certain types of attacks.

Despite being a simple configuration, large applications still often do not implement HTTP headers correctly; therefore, we encounter many of these errors. Or they have them implemented, but configured incorrectly. Furthermore, it is worth remembering that even with the increased use of version 2.0 of the HTTP protocol, developers will still use these HTTP headers a lot.

How to configure headers?

All the headers we will mention here can be set in two ways: directly on the web server or via the application. Therefore, you will need to consult the appropriate documentation for your case. We recommend that you set these headers directly on the web server , for example in the Apache, Nginx, Microsoft IIS or equivalent configurations.

But after all, what are these headers?

Inserting HTTP headers in the response of HTTP requests will help prevent some attacks on your application. In addition, we will explain a little about each header , and also talk about the policy of each one. Finally, we will give an example of use.

1. X-XSS-Protection Header:

This header informs modern browsers that they should apply filters against Cross Site Scripting or XSS attacks [2]. Newer browsers, such as Google Chrome and Internet Explorer, already have tools that seek to filter the content of a page, thus preventing Cross Site Scripting (XSS) attacks from occurring.

Example:
X-XSS-Protection: 1; mode=block;

2. Header X-Content-Type-Options:

This header prevents browsers from interpreting the content of the page and, as a result, prevents the execution of possible malicious code. A good example to illustrate the use of this header is when we upload a text file containing JavaScript code , and the browser interprets and executes the code even though it is just a text file.

Example:
X-Content-Type-Options: nosniff;

3. Strict-Transport-Security HTTP Header

This header is used to force the application to use the SSL/TLS secure communication protocol [3] . This prevents the application from having mixed content, i.e., the application’s pages will not transmit or consume resources from pages that use the HTTP protocol without encryption . This header also requires verification of the SSL/TLS certificate , to ensure that everything is correct. Using this header prevents Man in the Middle attacks [4]. Therefore, you can only implement this header if 100% of the application uses SSL/TLS.

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

An important note about the preload option: for it to work properly, you must first enter your domain address in a form provided by the Google search engine. Upon receiving this information, Google inserts your domain into a list of domains that should only be loaded if they are using the HTTPS protocol. This list is ultimately shared between the Google Chrome, Mozilla Firefox and Safari browsers. In reference [5] you can find both the form and the correct settings that the header must have for the domain to be included in the list.

4. X-Frame-Options Header:

This header prevents the browser from displaying certain types of content based on elements defined in the Document Object Model (DOM ) [6]. In other words, by not allowing the rendering of certain external content, we protect the application against Clickjacking attacks [7].

5. Header Content Security Policy (CSP):

This header implements policies that serve to validate the rendering of the page and protect against content injection attacks, such as Cross Site Scripting (XSS) [2]. This header has many policies [8] that must be studied individually so that no problems occur in the application.

Example:
Content-Security-Policy: default-src ‘self’ http://example.com; connect-src: ‘none’;

Final Observation:

Some more exotic browsers do not support the headers mentioned here. However, this will not cause any problems for the application, that is, if the browser does not support a certain header, it will simply ignore the header and the application will continue to function normally.

If you want to understand more about the topic, get in touch with Resh.