Securing your websites security headers

I understand how end-to-end security can be an oversite on websites and API endpoints. Perhaps you’ve just wrapped up a web application and placed all the files on a new server, generated the SSL certificate. You’ve thought you are done right? 

If you’re like some developers you would just deploy and go. Don’t do that. You will end up regreting it sooner or later. Always keep in mind the server response header information that is leaking out. If headers are overlooked, it can lead to an attack that you or another developer will have to mitigate against.

HTTP security headers you should be implementing

Header always set X-Frame-Options "SAMEORIGIN"

add_header X-Frame-Options SAMEORIGIN;

add_header X-Content-Type-Options nosniff;

Nginx:
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains;"

Header always set Referrer-Policy "strict-origin"

add_header Referrer-Policy "strict-origin";

Header always set Content-Security-Policy "default-src 'self';"

add_header Content-Security-Policy "default-src 'self';"

Header set X-XSS-Protection "1; mode=block"

add_header X-XSS-Protection "1; mode=block";

** It is not necessary to remove the X-Powered-By header but it is recommended. This header only exposes if you run PHP or not. Also if you run a PHP framework it will expose that as well, which leads to an attacker looking for vulnerabilities on your system.

Content-Security-Policy

Note: policy is simply a string of data and defines where data can be pulled from. 

If a browser doesn’t support CSP, no big deal. It will just write its own policy as same-origin, meaning the resources loaded into the browser will have to come from the same site. 

Use cases of a CSP:

• Allowing an external website to be an iFrame. The path of the external link will have to be entered into a policy.
• Allowing js, css and images from an external site
  

X-Frame-Options

The X-Frame-Options header determines whether or not the web browser should be allowing the following types: <frame>,<iframe>,<object> and <embed>.

Note: by implementing a CSP, you can use "frame-ancestors" to achieve the same result.

Options:

• DENY
• SAMEORIGIN

Another Note: don't set this header on the client-side within a <meta> tag. It will not work!

X-Content-Type-Options

This header indicates the MIME types that are cast in the Content-Type header are not to be tampered with. This header helps stop "MIME sniffing". MIME sniffing can lead to an XSS attack. This directive will look at the byte structure of the resource.

Note: Browsers each have their own implementation of MIME sniffing and if no MIME type is presented then the browser usually guesses as to which MIME type the resource is by either looking at the extension of the file or reading bytes in the header.  

Options:

• nosniff

Use cases:

• You want to block the transformation of a MIME non-executable to a MIME executable.

Permissions-Policy

This header indicates which features can be accessed by the browser.

Note: The permissions policy used to be called Feature-Policy. Features are often a good thing and can separate one web app to another. Be careful when using the permissions policy, as a misconfiguration can lead to bad user experience.

The permissions policy also doesn't have full browser support yet.

Use cases:

• You want to restrict access to the microphone.
• You want to block outdated APIs.

Strict-Transport -Security

Also called HSTS, this header tells the browser to only accept HTTPS connections on resources (images, files, etc).

Options:

• max-age=<seconds>
• includeSubDomains
• preload

X-XSS-Protection

This header will stop pages from loading if the browser detects the URL is tampered with from another site.

Note: This has been replaced by setting up a Content-Security-Policy. Firefox does not support this header.

Options:

• mode=block
  
• report=<report-uri>

By implementing these headers, you can help secure your server and prevent attacks.