Web Application Security Headers Explained

Web application security headers. Some of you may have heard of them, some may not be aware of what they do – we will go through them in this blog.

Have you heard of HTTP headers? If you're a web developer, your answer is probably yes – an HTTP header is a part of the HTTP response that "informs" your browser about the metadata of the information that is being sent back and forth.

Security engineers have probably heard of web application security headers – or HTTP security headers – too. They are a similar thing – they are the same HTTP headers, it's just that they're security-based.

HTTP Security Headers

A couple of the most common HTTP security headers (or web security headers) are as follows:

• Content-Security-Policy – this is one of the most important security headers briefly outlining a set of directives that help define from where scripts are loaded, what images should be displayed, what styles should prevent from being loaded into the website, where forms should direct users to, etc. – it includes the following headers:
  • script-src which specifies the valid sources for javascript files: values include "self", "unsafe-eval", and "unsafe-inline."
  • style-src which specifies the valid sources for stylesheets: values include "self", "unsafe-inline", and "blob."
  • form-action which restricts the URLs that forms can direct users to. Very useful if you're concerned of your application being breached and the attacker modifying the code.
• Strict-Transport-Security header instructs browsers that the application bearing this security header should only be accessed in a secure manner (by using SSL – all attempts to access the website via http:// will automatically convert to https://.)
• X-Content-Type-Options lets browsers know that the MIME types in the headers should not be changed.
• X-Frame-Options lets users instruct the browser whether frames like <frame>, <iframe>, <embed>, and <object> should be used by the website or not. The primary purpose of this security header is to avoid clickjacking attacks.
• Referrer-Policy informs the server what referrer policy should be followed when the user visiting your website is visiting another website. You can let another site know what site the user is coming from, don't let it know anything at all, or let it know something.

Most HTTP security headers are defined like so:

1. The security headers itself are defined – that means choosing and utilizing any and all options for the security header that you wish to use. It may look something like this (the options are separated by a semicolon. Also the X-XSS-Protection header is used to protect the application against Cross-site Scripting attacks): Content-Security-Policy: default-src 'self'; X-Frame-Options: deny; X-XSS-Protection:1; mode = block;
2. The security headers are implemented into an application via Apache, Nginx, or the programming language that is being used itself. That might mean opening up /etc/nginx/nginx.conf and adding a couple of add_header lines like so: add_header X-Frame-Options 'deny'; That might also mean defining the security headers with the header() function in PHP like so: header("X-Frame-Options: 'deny'"); Or it may mean setting headers via Apache by defining them like so: Header always set x-xss-protection "1; mode=block"

Before using security headers, though, make sure to evaluate their capabilities, choose the security headers you need, and implement them carefully. Also, do note that you may not need all of the security headers and only need one or two – that's fine too since for some, the functionality of websites may break due to what the headers do to the application (for example, a security header blocking frames may not be a good idea if the site is loading in youtube clips by using <iframe> code blocks.)

Data Breach Search Engines and Security Headers

If you're considering implementing security headers into the website of the company you work at, there's no doubt that your boss is very concerned about security. Why not suggest him to use the BreachDirectory API and get some BreachDirectory API keys to enhance the security of the company by being able to scan through tens of billions of rows of breached data to conduct OSINT operations? API keys can be purchased at the main page of BreachDirectory, and once you have an API key, you can implement the data inside of the BreachDirectory data breach search engine into the application of the company you work for.

Doing so provides you with a couple of key benefits:

• It's possible to bulk-scan accounts to make sure they're not at risk of identity theft.
• It's possible to implement the data derived from the API into other projects run by the company to further strengthen its security capabilities.
• It's possible to conduct OSINT operations by using the tool.

The BreachDirectory API is well documented, too – everything's done in such a fashion that even a complete newbie could begin using the tool:

Make sure to give the bulk version of the API a try today – secure the entirety of the company you work at, and assist your boss in OSINT projects. It's easy!

Summary

In this blog, we've walked you through the functionalities of HTTP security headers. HTTP security headers are the same as HTTP headers, it's just that they're meant to enhance the security capabilities of the application they're built into.

Aside from using HTTP security headers, though, you might also want to consider using data breach checkers and data breach scanners like the one provided by BreachDirectory – the BreachDirectory data breach search engine will not only provide you with the necessary information to secure yourself, but also provide an API capability that lets you protect both yourself, your teammates, and people that are using the product your company is building.

We hope you've enjoyed reading this blog, stick around and follow us on Twitter, LinkedIn, and Facebook for more information, and until next time!