What are HTTP Security Headers ?
When we visit any website in the browser, the browser sends some request headers to the server and the server responds with HTTP response headers. These headers are used by the client and server to share information as a part of the HTTP protocol. Browsers have defined behavior of the web page according to these headers during communication with the server. These headers are mainly a combination of key-value pairs separated by a colon
:. There are many HTTP headers, but here I'm covering some very useful web security headers, which will improve your website security.
Why HTTP Security Headers are necessary ?
As you know, nowadays too many data breaches are happening, many websites are hacked due to misconfiguration or lack of protection. These security headers will protect your website from some common attacks like XSS, code injection, clickjacking, etc. Additionally these headers increases your website SEO score.
1. Enforcing HTTPS (HTTP Strict Transport Security (HSTS))
HTTP Strict Transport Security security header helps to protect websites against man-in-the-middle attacks and cookie hijacking. Let's say, you have one website
www.example.com and you have purchased SSL certification for migrating your website from HTTP to HTTPS. Now suppose old users are still opening your website using the HTTP, so they may redirect your HTTP users to HTTPS via redirection as a solution. Since visitors may first communicate with the non-encrypted version of the site before being redirected. This creates an opportunity for a man-in-the-middle attack. The HTTP Strict Transport Security header informs the browser that it should never load a site using HTTP and should automatically convert all attempts to access the site using HTTP to HTTPS requests.
Strict-Transport-Security: max-age=<expire-time> Strict-Transport-Security: max-age=<expire-time>; includeSubDomains Strict-Transport-Security: max-age=<expire-time>; preload
HSTS directives :
||This directive allows us to specify the amount of time (in seconds) that the content of the header will be stored in the browser cache.|
||If this optional parameter is specified, this rule applies to all of the site's subdomains as well.|
||This is not part of the specifications. Please see the Preloading Strict Transport Security|
2. Cross-Site Scripting Protection (X-XSS)
X-XSS-Protection: 0 X-XSS-Protection: 1 X-XSS-Protection: 1; mode=block X-XSS-Protection: 1; report=<reporting-uri>
||Disable the XSS Filtering|
||Enable the XSS Filtering and remove the unsafe part|
||Browser prevents the entire page from rendering when an XSS attack is detected.|
||When a cross-site scripting attack is detected, the browser will remove the unsafe parts from the page and report the violation on the reporting URL.|
3. Website IFrame Protection
The X-Frame-Options HTTP response header can be used to instruct the browser whether a web page should be allowed to render a
<frame>, <iframe>, <embed> or <object> element on website or not.
This header protects users against ClickJacking attacks. An attacker uses multiple tricks to trick the user into clicking something different than what they think they’re clicking.
X-Frame-Options: DENY X-Frame-Options: SAMEORIGIN
X-Frame-Options directives include the following:
||This will not allow to page rendering in the
||This will allow the page to only be displayed in a
4. Preventing Content-Type Sniffing
X-Content-Type-Options response header prevents the browser from MIME-sniffing a response away from the declared content-type. A MIME-sniffing vulnerability allows an attacker to inject a malicious resource, such as a malicious executable script, Suppose an attacker changes the response for an innocent resource, such as an image. With MIME sniffing, the browser will ignore the declared image content type, and instead of rendering an image will execute the malicious script.
nosniff - Blocks a request if the request destination is of type:
6. Content Security Policy
Content-Security-Policy header is used to instruct the browser to load only the allowed content defined in the policy. This uses the whitelisting approach which tells the browser from where to load the images, scripts, CSS, applets, etc. If implemented properly, this policy prevents the exploitation of Cross-Site Scripting (XSS), ClickJacking, and HTML injection attacks.
Content-Security-Policy: <policy-directive>; <policy-directive>
More information about the Content Security policy can be found on Mozilla’s website .
As a web developer, you can follow this guide for adding security headers to your website. HTTP headers can be configured on the server to enhance the overall security of the web application. You can easily validate your website security headers. Multiple free online tools are available to check the same:
These headers reduce the potential vulnerabilities of the application. Alongside these headers will add one layer of security still we need to add more layer's of security in our web application