When you want to visit a website, the internet browser you use receives some data from that site. As a result, a dialogue occurs between your device and the website. This happens with the protocol called HTTP. It is possible to take some additional security measures by intervening in this dialogue.

If you are running a website or aiming for career as a web developer, HTTP security headers are invaluable to you, because they play an active role in the security of both the user and the website.

What Is HTTP Strict-Transport-Security (HSTS)?

HTTP Strict Transport Security (HSTS) forces users to use HTTPS for every request they make in their browser. This is a solid way to combat cyberattacks like downgrades and to ensure the security of all traffic.

Activating HSTS is pretty easy. Consider the dialogue between the client and server. When you try to access a site via your browser, you are the client. The site you want to open depends on the server. Your goal is to tell the server, "I want to open this site". This is a request operation. The server, on the other hand, directs you to the site if you meet the desired conditions.

Keep this in mind in regards to this sample HTTP Header flag:

        Strict-Transport-Security: max-age=16070200;

When you add this flag to the header information of the HTTP response, all user-generated requests will become HTTPS. Whatever the user writes here, the browser will automatically evaluate the protocol as HTTPS and establish a secure connection.

How to Use HSTS

Instead of adding all this HTTP header information in the code layer, you can do it on Apache, IIS, Nginx, Tomcat, and other web server applications.

To enable HSTS in Apache:

        LoadModule headers_module modules/mod_headers.so
<VirtualHost *:443>
    Header always set Strict-Transport-Security "max-age=2592000; includeSubDomains"
</VirtualHost>

To enable HSTS in Nginx:

        add_header Strict-Transport-Security max-age=2592000; includeSubdomains

To enable HSTS with IIS web.config:

        <system.webServer>
   <httpProtocol>
       <customHeaders>
           <add name="Strict-Transport-Security" value="max-age=63072000"/>
       </customHeaders>
   </httpProtocol>
</system.webServer>

For Cloudflare Users

Cloudflare provides free HTTPS service for everyone with its Keyless SSL service; before applying for HSTS preload, you should know that your certificate does not belong to you. Lots of sites use SSL certificates because they're a simple way to keep data secure.

However, Cloudflare now supports the HSTS feature. You can activate all HSTS features, including preload, via the Cloudflare web interface without struggling with the configurations on the web server.

What Is X-Frame-Options?

Increasing the security of the website with HTTP headers

X-Frame-Options is a security header supported by all modern browsers. X-Frame-Options aims to protect against click theft such as Clickjacking. As the name suggests, it's about the working of a vulnerable inline frame, also known as an iframe. These are elements on a site that embed another HTML page within the "parent" site, so you can use content from other sources on your site. But attackers use iframes under their own control to make users carry out actions they do not want to.

For this reason, you need to prevent attackers from being able to find iframes on the site.

Where and How to Use X-Frame-Options?

What X-Frame-Options does, some developers try to do with languages like JavaScript. This is not entirely wrong. However, there is still a risk because the codes written in many aspects are not enough. So it would be wise to leave this task to the internet browser you are using.

However, as a developer, there are three parameters to know about X-Frame-Options:

  • Deny: Completely prevent the page from being called in any iframe.
  • SAMEORIGIN: Prevent any domain other than your own from calling within the iframe.
  • ALLOW-FROM uri: Accept iframe calls of URI given as parameter. Block others.

Here, the SAMEORIGIN feature stands out more. Because while you can call applications in your different subdomains with iframes within each other, you can prevent them from being called over the domain under the attacker's control.

Here are examples of how you can use SAMEORIGIN and X-Frame-Options with NGINX, Apache, and IIS:

Using X-Frame-Options SAMEORIGIN for Nginx:

        add_header X-Frame-Options SAMEORIGIN;

Using X-Frame-Options SAMEORIGIN for Apache:

        Header always append X-Frame-Options SAMEORIGIN

Using X-Frame-Options SAMEORIGIN for IIS:

        <httpProtocol>
   <customHeaders>
     <add name="X-Frame-Options" value="SAMEORIGIN" />
   </customHeaders>
 </httpProtocol>

Simply adding the SAMEORIGIN header alone will provide greater security for your visitors.

What Is X-XSS-Protection?

Using X-XSS-Protection header information can protect users from XSS attacks. Firstly, you need to eliminate XSS vulnerabilities on the application side. After providing code-based security, further measures, i.e. X-XSS-Protection headers, are required against XSS vulnerabilities in browsers.

How to Use X-XSS-Protection

Modern browsers can detect potential XSS payloads by filtering application-generated content. It is possible to activate this feature with the X-XSS-Protection header information.

To enable the X-XSS-Protection header in Nginx:

        add_header X-Frame-X-XSS-Protection 1;

To enable the X-XSS-Protection header in Apache:

        Header always append X-XSS-Protection 1

To enable the X-XSS-Protection header in IIS:

        <httpProtocol>
   <customHeaders>
     <add name="X-XSS-Protection" value="1" />
   </customHeaders>
 </httpProtocol>

To prevent the code block with XSS attack by default from running, you can use something like this:

        X-XSS-Protection: 1; mode=block

This minor change needs to be made if there is a potentially dangerous situation and you want to prevent all content from being rendered.

What Is X-Content-Type-Options?

Browsers perform an analysis called MIME Type Sniffing on content presented to them by the web application. For example, if there is a request for access to a PDF file or PNG file, browsers that perform analysis on the HTTP response infer the file type.

Consider a file with a jpeg extension but which actually has Text/HTML content. After using the extensions and passing protections in the upload module, the file is successfully uploaded. The uploaded file is called via the URL and MIME Type sniffing returns Text/HTML as a result. It renders the content as HTML. That's when the XSS vulnerability occurs.

So you need to prevent browsers from deciding on content by MIME Type sniffing. To do this, you can use nosniff.

X-Content-Type-Options header for Nginx:

        add_header X-Content-Type-Options nosniff;

X-Content-Type-Options header for Apache:

        Header always X-Content-Type-Options nosniff

X-Content-Type-Options header for IIS:

        <httpProtocol>
   <customHeaders>
     <add name="X-Content-Type-Options" value="nosniff" />
   </customHeaders>
 </httpProtocol>

Web applications track users' sessions via session ID. Browsers will store this and automatically add it to every HTTP request within the cookie's scope.

It is possible to use cookies for purposes other than the transfer of the session key, however. Hackers could find out user data using the aforementioned XSS vulnerability or through a Cross-Site Request Forgery (CSRF) attack. So which cookies are most important in terms of security?

You can consider the information contained in the last image you clicked on in the image gallery as an example. In this way, HTTP traffic is less and a part of the load can be resolved by the user's internet browser with client-side scripting.

Use of HTTP headers to protect confidential information on the site

That's where HttpOnly comes in. Below is an example of how the cookie assignment should be:

        Set-Cookie: user=t=cdabe8a1c2153d726; path=/; HttpOnly

Notice the HttpOnly value sent in the Set-Cookie operation. The browser will see this and won't process values with the HttpOnly flag when the cookie is accessed through the document.cookie variable. Another flag used in the Set-Cookie process is the Secure flag. This indicates that the cookie value will be added to the header only for HTTPS requests. E-commerce sites usually use it because they want to reduce network traffic and increase performance.

Using this method, you can hide users' critical data such as usernames, passwords, and credit card information. But there is a problem. Users who complete the login process are assigned a cookie value without the Secure flag. The user can have the session key when they make a HTTP request to non-HTTPS links. Adding the secure flag is easy:

        Set-Cookie: user=t=cdabe8a1c2153d726; path=/; Secure

When shouldn't you use HttpOnly? If you rely on Javascript, you should be wary as this can make your site less secure instead.

Small Steps Work for Wider Web Security

You don't need advanced software and server knowledge to increase the security of web applications. By changing only a few lines, you can prevent some serious attacks. Of course, this is not enough. However, it is a small but effective step for website security. Knowledge is the best preventative, so it's also useful to know the subtle nuances of how HTTPS protects data during transfer.