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 | Function | Mitigates Against | Usage Examples |
---|---|---|---|
X-Frame-Options | This tells the browser if you want to allow your website to be used in an iFrame. | Clickjacking | Apache:
Header always set X-Frame-Options "SAMEORIGIN"Nginx: add_header X-Frame-Options SAMEORIGIN; |
X-Content-Type-Options | This header tells the browser to follow MIME types as directed in the header. | Browser Sniffing | Apache:
Nginx:
add_header X-Content-Type-Options nosniff; |
Permissions-Policy | Helps control which features and API's can be used in the browser. | ||
Strict-Transport-Security | Forces the browser to use an HTTPS connection | Nginx: add_header Strict-Transport-Security "max-age=31536000; includeSubDomains;" | |
Referrer-Policy | Used for when to tell the browser to set Referrer headers. | Apache:Header always set Referrer-Policy "strict-origin"Nginx: add_header Referrer-Policy "strict-origin"; | |
Content-Security-Policy | This tells the browser to accept or reject resources based on the policy provided. | Cross Site Scripting |
Apache: Header always set Content-Security-Policy "default-src 'self';"Nginx: add_header Content-Security-Policy "default-src 'self';" |
X-XSS-Protection | Enables cross site script filtering | Cross Site Scripting | Apache:
Header set X-XSS-Protection "1; mode=block"Nginx: 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
A content security policy is a policy on the web server that mitigates against data theft, data injection and XSS (cross site scripting) attacks.
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.