Some security-related HTTP Response Headers

Modern browsers provide security-related response headers. To use these response headers, you only need to modify the server configuration, and do not need to modify the program code. The cost is very low. This article introduces some of the following response headers: 1. Strict-Transport-Security

HTTP Strict Transport Security (HSTS for short. It allows an HTTPS website and requires the browser to always access it through HTTPS. Currently, in addition to Chrome, Firefox4 +, and Firefox NoScript extensions, this response header is supported.

We know that HTTPS has better security than HTTP, and many HTTPS websites can also access it through HTTP. Errors made by developers or addresses entered by users may cause users to access the website over HTTP, reducing security. Generally, the Web Server sends 301/302 redirection to solve this problem. Now with HSTS, the browser can help you with this jump, saving an HTTP request.

To use HSTS, you only needHTTPSAdd the following line to the website Response Header:

Strict-transport-security: max-age = 16070400; includeSubDomains is optional, used to specify whether to act on subdomain names. When a browser that supports HSTS encounters this response header, the current website will be added to the HSTS list, and all requests of the current website will be redirected to https within the seconds specified by max-age. Even if the user actively enters http: // or does not enter the Protocol part, it will redirect to https: // address. Chrome has a built-in HSTS list, which includes services such as Google, Paypal, Twitter, and Linode by default. You can also enter Chrome: // net-internals/# hsts in chrome to enter the HSTS management interface. On this page, you can add/delete/query HSTS records. For example, if you want to access a website over https, you just need to add it through "add Domain.
View All HSTS lists built in Chrome, or click here to add your website to this list. 2. X-Frame-Options

X-Frame-Options, which has been converted to Frame-Options, but it is best to include X -. Chrome4 +, Firefox3.6.9 +, and IE8 + are supported. For more information about browser support, see here. The usage is as follows:

X-frame-options: SAMEORIGIN: The response header supports three configurations:

• DENY: cannot be embedded on any page;
• SAMEORIGIN: not allowed to be embedded on pages outside the current domain;
• ALLOW-FROM uri: Page embedding outside the specified domain name is not allowed (not supported by Chrome currently );

If a page is not allowed to be embedded in the form of <iframe> or <frame>, IE displays a message similar to "This content cannot be displayed in the framework, both Chrome and Firefox print information on the console. Because embedded pages are not loaded, Clickjacking is reduced.

3. X-XSS-Protection

As the name suggests, this response header is used to prevent XSS attacks. I first saw this in the article about IE8, which is now supported by mainstream browsers, and XSS protection is enabled by default. You can use this header to close it. It has several configurations:

• 0: Disable XSS protection;
• 1. Enable XSS protection;
• 1; mode = block: Enable XSS protection, and stop rendering pages when an XSS attack is detected (for example, in IE8, when an attack is detected, the whole page will be replaced by );

The XSS protection mechanism provided by the browser is not perfect, but it can still improve the attack difficulty after it is enabled. In short, there is no special reason to disable it.

4. X-Content-Type-Options

There are various types of resources on the Internet. Generally, the browser will distinguish their types based on the Content-Type field in the response header. For example, "text/html" indicates an html document, "image/png" indicates a PNG image, and "text/css" indicates a CSS document. However, the Content-Type of some resources is incorrect or undefined. In this case, Some browsers enable MIME-sniffing to guess the type of the resource, parse the content and execute it.

For example, if we specify the Content-Type as "text/plain" for an html document, this document will still be parsed as html in IE8. Using this browser feature, attackers can even resolve requests that should be parsed as images to JavaScript. The following response header can be used to disable browser type speculation:
X-Content-Type-Options: nosniff
The response header value can only be nosniff. In addition, it is also used by Chrome for extended download. See here

5. X-Content-Security-Policy

This response header is mainly used to define the resources that can be loaded on the page to reduce the occurrence of XSS. Previously, I have introduced it separately. Click to continue browsing: Content Security Policy introduction.

How Others use

Finally, let's take a look at several practical cases:

Google + uses the Response Headers mentioned in this article:

X-content-type-options: nosniff x-frame-options: SAMEORIGINx-xss-protection: 1; mode = blockTwitter uses these: strict-transport-security: max-age = 631138519 x-frame-options: SAMEORIGINx-xss-protection: 1; mode = blockPayPal: X-Frame-Options: SAMEORIGINStrict-Transport-Security: max-age = 14400Facebook uses these (with detailed CSP configured, XSS protection disabled): strict-transport-security: max-age = 60x-content-type-options: nosniffx-frame-options: DENYx-xss-protection: 0content-security-policy: default-src *; script-src https: // * .facebook.com http: // * .facebook.com https: // * .fbcdn.net http: // * .fbcdn.net * .facebook.net * .google-analytics.com * .virtualearth.net * .google.com 127.0.0.1: ** .spotilocal.com: * chrome-extension: // comment 'unsafe-inline' 'unsafe-eval' https: // * .akamaihd.net http: // * .akamaihd.net; style-src * 'unsafe-inline'; connect-src https: // * .facebook.com http: // * .facebook.com https: // * .fbcdn.net http: // * .fbcdn.net * .facebook.net * .spotilocal.com: * https: // * .akamaihd.net ws: // * .facebook.com: * http: // * Others https://fb.scanandcleanlocal.com :*;
Link: http://www.imququ.com/post/web-security-and-response-header.html