Most of the security vulnerabilities can be corrected by implementing certain headers in the server response header. HTTP security headers provide yet another tier of security by helping to mitigate intrusions and security vulnerabilities.
We will examine some of them to help you better know their purpose and how to implement them.
What are HTTP security headers?
Whenever a browser requests a page from any web server, the server responds with the content along with HTTP response headers. These HTTP security headers tell the browser how to behave while handling the website content.
Listed below are some of the security headers you should be aware of and their uses. We highly recommend you to implement them if you are a website owner.
Content Security Policy
The Content Security Policy header implements an additional layer of security. This policy helps prevent attacks such as Cross-Site Scripting (XSS) and other code injection attacks by limiting content sources that are approved and thus permitting the browser to load them.
This uses the whitelisting method which tells the browser from where to fetch the images, scripts, CSS, etc.
The majority of the browsers currently offer full or partial support for CSP.
The name of the header is Content-Security-Policy and its value can be set with the following directives: default-src, script-src, media-src, img-src. They define the sources from where the browser should load those types of resources.
Implementation
Content-Security-Policy: default-src 'self'; media-src beagle.com beaglesecurity.com;
script-src beagle.com; img-src *;
This is interpreted by the browser as:
- default-src ‘self’; - load everything from current domain
- media-src beagle.com beaglesecurity.com; - load media only from beagle.com and beaglesecurity.com
- script-src beagle.com; - load script only from beagle.com
- img-src *; - load image from anywhere
Server Implementation
Apache
Add the following to the httpd.conf file and restart the server.
Header set Content-Security-Policy "default-src 'self';"
Nginx
Add the following in the nginx.conf file under the server block.
add_header Content-Security-Policy "default-src 'self';";
IIS
Add the following in IIS Manager:
Open IIS Manager
Select the Site you need to enable the header for
Go to “HTTP Response Headers.”
Click “Add” under actions
Enter name, value and click Ok
Example
X-Frame-Options
The X-Frame-Options HTTP response header is used to indicate if a browser is permitted to execute a page in a “frame”, “iframe” or “object” HTML tag. Sites and applications can use this to dodge clickjacking attacks, by ensuring their content cannot be embedded into other sites.
The header either set to “SAMEORIGIN”, or to “DENY”. “SAMEORIGIN” allows only resources that are the element of the same-origin policy to frame the protected resource. “DENY” rejects any resource (local or remote) from trying to frame the resource that is also supplied.
Implementation
X-Frame-Options: SAMEORIGIN - The frame can only be displayed in a frame on the specified origin.
X-Frame-Options: DENY - This will not allow the page to be loaded in a frame on any website.
Server Implementation
Apache
Add the following to the httpd.conf file and restart the server.
Header always append X-Frame-Options DENY
Nginx
Add the following in the nginx.conf file under the server block.
add_header X-Frame-Options "DENY";
IIS
Add the following in IIS Manager:
- Open IIS Manager
- Select the Site you need to enable the header for
- Go to “HTTP Response Headers.”
- Click “Add” under actions
- Enter name, value and click Ok
Example
X-XSS-Protection
X-XSS-Protection header is intended to protect against Cross-Site Scripting attacks.
The optimal configuration is to set this header to a value, which will enable the XSS protection and tell the browser to block the response if a malicious script has been included from user input.
Implementation
X-XSS-Protection: 0; - Condition 0 will disable the XSS filter. X-XSS-Protection: 1; - Condition 1 will enable the filter, in case the XSS attack is identified. X-XSS-Protection: 1; mode=block - Condition 1 used with block mode will block the rendering of the page if an XSS attack is identified.
Server Implementation
Apache
Add the following to the httpd.conf file and restart the server.
Header set X-XSS-Protection "1; mode=block"
Nginx
Add the following in the nginx.conf file under the server block.
add_header X-XSS-Protection "1; mode=block";
IIS
Add the following in IIS Manager:
- Open IIS Manager
- Select the Site you need to enable the header for
- Go to “HTTP Response Headers.”
- Click “Add” under actions
- Enter name, value and click Ok
Example
X-Content-Type-Options
The X-Content-Type-Options header is used to indicate that the MIME types recorded in the Content-Type headers should not be changed. This protects you from MIME type sniffing.
MIME sniffing is speculating what content type the server response will be, rather than trusting what the header’s content type value states. Based on that assumption, browsers can be tricked to execute malicious code.
The header can be used to prevent this from happening by fixing the value of this header to “nosniff”.
Implementation
X-Content-Type-Options: nosniff - the browser will no longer ‘sniff’ the content of the file received but use the value from the Content-Type header.
Server Implementation
Apache
Add the following to the httpd.conf file and restart the server.
Header set X-Content-Type-Options nosniff
Nginx
Add the following in the nginx.conf file under the server block.
add_header X-Content-Type-Options nosniff;
IIS
Add the following in IIS Manager:
- Open IIS Manager
- Select the Site you need to enable the header for
- Go to “HTTP Response Headers.”
- Click “Add” under actions
- Enter name, value and click Ok
Example
HTTP Strict Transport Security
A Strict Transport Security header (HSTS) enables the application to inform browsers that it should be only accessed using HTTPS instead of HTTP.
If the website or application allows connection through HTTP before redirecting to HTTPS, visitors can communicate with the non-encrypted version of the site before the redirect which creates an opportunity for man-in-the-middle attacks.
Upon the first interaction with a website, the browser won’t be aware of an HSTS Policy for the host, therefore the initial communication is taking place over HTTP.
To resolve this problem, browsers contain a preloaded list of sites that are configured for strict transport security. HSTS is generally set to a “max-age” value that is high enough to keep the website cached in the HSTS account for the entire duration that is specified.
Implementation
Strict-Transport-Security: max-age=31536000; - cache the domain for 1 year
Server Implementation
Apache
Add the following to the httpd.conf file and restart the server.
Header set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
Nginx
add_header Strict-Transport-Security 'max-age=31536000; includeSubDomains; preload';
IIS
Add the following in IIS Manager:
- Open IIS Manager
- Select the Site you need to enable the header for
- Go to “HTTP Response Headers.”
- Click “Add” under actions
- Enter name, value and click Ok
Example
Conclusion
As you can see HTTP security headers can support in hardening the security of your server. Thus, there is no reason not to use them.
Do you have any thoughts on HTTP security headers? If so, do leave us a comment below.
