If you want to have a lot of information about Information Security, be sure to follow my Youtube Channel.

Introduction

Dozens of websites are hacked because of misconfiguration or a lack of protection.

You can indeed see on the OWASP Top 10, which are the Top 10 identified flaws on web servers and services from the OWASP (Open Web Application Security Project), that the Security Misconfiguration is the most identified cause of vulnerabilities on web services.
This is commonly a result of insecure default configurations, incomplete or ad-hoc configurations, open cloud storage, misconfigured HTTP headers, and verbose error messages containing sensitive information.
Not only must all operating systems, frameworks, libraries, and applications be securely configured, but they must be patched/upgraded in a timely fashion.

Let's deep dive on the weaknesses and impacts of it.

In this post, we are going to go through the headers and configuration you should use on your project in order to secure your server.
At first, we consider that all requests and responses are transmitted over https.
And that all the logging and information from the server configuration are hidden.

Before you start :

• Don't forget to backup your current configuration before making any change to your configuration.
• Moreover some headers may not be compatible regarding on the browser. I encourage you to check out the browser compatibility on the compatibility matrix that is available on that page.
• Mod-Headers must be enabled in Apache to implement these headers. Ensure the line is uncommented in httpd.conf file.

Let us review the HTTP headers list that we are going to cover :

1. X-XSS-Protection
2. X-Frame-Options
3. X-Content-Type-Options
4. Content-Security-Policy
5. Referrer-Policy
6. HTTP Strict Transport Security
7. SameSite
8. HttpOnly
9. Secure
10. Conclusion
11. Annexes

Note : If you want to have the sum up and the Apache and NGinx configurations, you can go to the "Conclusion".

1. X-XSS-Protection

The X-XSS-Protection header can prevent some level of XSS (CrosSite-Scripting) attacks.
XSS attacks enable attackers to inject client-side scripts into web pages viewed by other users.

Browser Support

There are 4 possible ways you can configure that header.

What we recommend to implement : 1;mode=block

2. X-Frame-Options

The X-Frame-Options header prevents Clickjacking vulnerability on your website.
By implementing this header, you instruct the browser not to embed your web page in frame/iframe.

Browser Support

There are 3 possible ways you can configure that header.

What we recommend to implement : DENY

3. X-Content-Type-Options

The X-Content-Type-Options header prevents MIME types security risk by adding this header to your web page’s HTTP response. Having this header instruct browser to consider files types as defined and disallow content sniffing.

Browser Support

There are 1 possible way you can configure that header.

What we recommend to implement : nosniff

4. Content Security Policy

The Content Security Policy prevent XSS, clickjacking, code injection attacks by implementing the Content Security Policy (CSP) header in your web page HTTP response.
CSP instruct browser to load allowed content to load on the website.
Nevertheless, if you implement CSRF, in some framework (like AngularJS) the browser retrieves the CSRF cookie and add a custom header XSRF-HEADER to the response in order to implement a CSRF prevention method. So you have to be very careful about how you implement that header. You can find a lot of great methods to prevent CSRF on the OWASP website.

Browser Support

There are 23 possible ways you can configure that header.

What we recommend to implement : default-src on self with reporting enabled

5. Referrer Policy

The Referrer-Policy HTTP header governs which referrer information, sent in the Referer header, should be included with requests made.

Browser Support

There are 8 possible ways you can configure that header.

What we recommend to implement : no-referrer

6. HTTP Strict Transport Security

HTTP Strict Transport Security (HSTS) is a web security policy mechanism which helps to protect websites against protocol downgrade attacks and cookie hijacking. It allows web servers to declare that web browsers (or other complying user agents) should only interact with it using secure HTTPS connections, and never via the insecure HTTP protocol.

Browser Support

There are 2 possible ways you can configure that header.

What we recommend to implement : max-age=31536000; includeSubDomains

7. Cookies

When receiving an HTTP request, a server can send a Set-Cookie header with the response. The cookie is usually stored by the browser, and then the cookie is sent with requests made to the same server inside a Cookie HTTP header. An expiration date or duration can be specified, after which the cookie is no longer sent. Additionally, restrictions to a specific domain and path can be set, limiting where the cookie is sent.

The Set-Cookie and Cookie headers

The Set-Cookie HTTP response header sends cookies from the server to the user agent.
A simple cookie is set like this Set-Cookie: <cookie-name>=<cookie-value>.

Session cookies

The cookie created above is a session cookie: it is deleted when the client shuts down, because it didn't specify an Expires or Max-Age directive. However, web browsers may use session restoring, which makes most session cookies permanent, as if the browser was never closed.

Permanent cookies

Instead of expiring when the client closes,permanent cookies expire at a specific date (Expires) or after a specific length of time (Max-Age). Permanent cookies are set like this Set-Cookie: id=a3fWa; Expires=Wed, 21 Oct 2020 07:28:00 GMT;.

Browser Support

There are many possible cookies you can add to improve the security of your product.

"SameSite" Cookie

SameSite cookies let servers require that a cookie shouldn't be sent with cross-site requests, which somewhat protects against cross-site request forgery attacks (CSRF). SameSite cookies are still experimental and not yet supported by all browsers.

The same-site attribute can have one of two values:
|Value|Meaning|
|---|---|
|strict|If a same-site cookie has this attribute, the browser will only send cookies if the request originated from the website that set the cookie. If the request originated from a different URL than the URL of the current location, none of the cookies tagged with the strict attribute will be included.|
|lax|If the attribute is set to lax, same-site cookies are withheld on cross-domain subrequests, such as calls to load images or frames, but will be sent when a user navigates to the URL from an external site, for example, by following a link.|

The default behavior if the flag is not set, or not supported by the browser, is to include the cookies in any request, including cross-origin requests.

"Secure" Cookie

A secure cookie is only sent to the server with an encrypted request over the HTTPS protocol. Even with Secure, sensitive information should never be stored in cookies, as they are inherently insecure and this flag can't offer real protection. Starting with Chrome 52 and Firefox 52, insecure sites (http:) can't set cookies with the Secure directive.

"HttpOnly" Cookie

To prevent cross-site scripting (XSS) attacks, HttpOnly cookies are inaccessible to JavaScript's Document.cookie API; they are only sent to the server. For example, cookies that persist server-side sessions don't need to be available to JavaScript, and the HttpOnly flag should be set.

What we recommend to implement : Secure=True; HttpOnly=True, SameSite=strict

Apache

PHP

setcookie ( string $key [, string $value = "" [, int $expires = 0 [, string $path = "" [, string $domain = "" [, bool $secure = FALSE [, bool $httponly = FALSE ]]]]]] ) : bool

Node.JS

response.setHeader('Set-Cookie', 'key=value; secure; HttpOnly; SameSite=Strict');

Python

self.set_secure_cookie('key', value, secure=True, httponly=True)

Ruby on Rails

cookies["key"] = { :value => "value", :secure => true, :http_only => true, :same_site =>  }

Then you can test your website http response header against that website.

Conclusion

Let's sum up the server configuration you can use.

Apache

Nginx

Cookies

Browser Support

How to Test in Real Life

This is the easiest way to test security headers. Just open up a console and fire Curl;
Curl will grab the headers for you within seconds. We need to use Curl with parameters I and L. I switch will tell curl to grab the head and L parameter will help to follow the redirects, if our target has any.

curl -I -L --url <target domain or IP>

➜ curl -I -L --url example.fr/espace-client
HTTP/1.1 301 Moved Permanently
Location: https://www.example.fr/
Content-Length: 0
Connection: close
Date: Thu, 04 Jul 2019 13:18:30 GMT

HTTP/2 200
content-type: text/html; charset=UTF-8
x-frame-options: SAMEORIGIN
strict-transport-security: max-age=15724800; includeSubDomains
cache-control: max-age=3600, public
link: <http://www.example.fr/>; rel="shortlink", <http://www.example.fr/>; rel="canonical"
link: </node/1>; rel="revision"
x-ua-compatible: IE=edge
content-language: fr
x-content-type-options: nosniff
x-frame-options: DENY
expires: Sun, 19 Nov 1978 05:00:00 GMT
last-modified: Thu, 04 Jul 2019 12:29:39 GMT
etag: W/"1562243379"
x-drupal-cache: HIT
x-xss-protection: 1; mode=block
access-control-allow-origin: *
content-security-policy: upgrade-insecure-requests
access-control-allow-methods: POST, GET, DELETE, PUT
access-control-max-age: 1000
access-control-allow-headers: Content-Type, origin, accept
referrer-policy: no-referrer
date: Thu, 04 Jul 2019 13:18:30 GMT
vary: cookie

Nmap can be used to test and validate security headers very easily. We can leverage an nmap script named “http-security-headers”. Download it from this link: https://svn.nmap.org/nmap/scripts/http-security-headers.nse

nmap -p 443,80 --script http-security-headers <target IP or Domain>

Refer to the below result: It gives a nice overview of implemented header values.

➜ nmap -p 443,80 --script http-security-headers example.fr
Starting Nmap 7.70 ( https://nmap.org ) at 2019-07-04 15:19 CEST
Nmap scan report for example.fr (92.223.124.199)
Host is up (0.012s latency).

PORT    STATE SERVICE
80/tcp  open  http
| http-security-headers:
|   Strict_Transport_Security:
|     Header: Strict-Transport-Security: max-age=15724800; includeSubDomains
|   X_Frame_Options:
|     Header: X-Frame-Options: SAMEORIGIN, DENY
|     Description: The browser must not display this content in any frame.
|   X_XSS_Protection:
|     Header: X-XSS-Protection: 1; mode=block
|     Description: The browser will prevent the rendering of the page when XSS is detected.
|   X_Content_Type_Options:
|     Header: X-Content-Type-Options: nosniff
|     Description: Will prevent the browser from MIME-sniffing a response away from the declared content-type.
|   Content_Security_Policy:
|     Header: Content-Security-Policy: upgrade-insecure-requests
|     Description: Instructs user agent to download insecure resources using HTTPS.
|   Cache_Control:
|     Header: Cache-Control: max-age=3600, public
|   Expires:
|_    Header: Expires: Sun, 19 Nov 1978 05:00:00 GMT
443/tcp open  https
| http-security-headers:
|   Strict_Transport_Security:
|     Header: Strict-Transport-Security: max-age=15724800; includeSubDomains
|   X_Frame_Options:
|     Header: X-Frame-Options: SAMEORIGIN, DENY
|     Description: The browser must not display this content in any frame.
|   X_XSS_Protection:
|     Header: X-XSS-Protection: 1; mode=block
|     Description: The browser will prevent the rendering of the page when XSS is detected.
|   X_Content_Type_Options:
|     Header: X-Content-Type-Options: nosniff
|     Description: Will prevent the browser from MIME-sniffing a response away from the declared content-type.
|   Content_Security_Policy:
|     Header: Content-Security-Policy: upgrade-insecure-requests
|     Description: Instructs user agent to download insecure resources using HTTPS.
|   Cache_Control:
|     Header: Cache-Control: max-age=3600, public
|   Expires:
|_    Header: Expires: Sun, 19 Nov 1978 05:00:00 GMT

Nmap done: 1 IP address (1 host up) scanned in 0.88 seconds

Annexes

OWASP Secure Headers Project - OWASP
HTTP Cookies Security - Mozilla Developer Network

Video produced by Wild & Secure, your consulting firm to all things security and real estate.
If you want to receive weekly quality content about security, subscribe to our newsletter on our website.