如何设置安全的header

0 – 关闭对浏览器的xss防护

1 – 开启xss防护

1mode=block – 开启xss防护并通知浏览器阻止而不是过滤用户注入的脚本。

1report=http://site.com/report – 这个只有chrome和webkit内核的浏览器支持，这种模式告诉浏览器当发现疑似xss攻击的时候就将这部分数据post到指定地址。

通常不正确的设置

0mode=block– 记住当配置为0的时候，即使加了mode=block选项也是没有效果的。需要指出的是，chrome在发现这种错误的配置后还是会开启xss防护。

1 mode=block– 数字和选项之间必须是用分号分割，逗号和空格都是错误的。但是这种错误配置情况下，IE和chrome还是默认会清洗xss攻击，但是不会阻拦。

如何检测

如果过滤器检测或阻拦了一个反射性xss以后,IE会d出一个对话框。当设置为1时，chrome会隐藏对反射性xss的输出。如果是设置为 1mode=block ,那么chrome会直接将user-agent置为一个空值:, URL 这种形式。

参考文献

Post from Microsoft on the X-XSS-Protection Header

Chromium X-XSS-Protection Header Parsing Source

Discussion of report format in WebKit bugzilla

2. X-Content-Type-Options

目的

这个header主要用来防止在IE9、chrome和safari中的MIME类型混淆攻击。firefox目前对此还存在争议。通常浏览器可以通过嗅探内容本身的方法来决定它是什么类型，而不是看响应中的content-type值。通过设置 X-Content-Type-Options：如果content-type和期望的类型匹配，则不需要嗅探，只能从外部加载确定类型的资源。举个例子，如果加载了一个样式表，那么资源的MIME类型只能是text/css，对于IE中的脚本资源，以下的内容类型是有效的：

application/ecmascript

application/javascript

application/x-javascript

text/ecmascript

text/javascript

text/jscript

text/x-javascript

text/vbs

text/vbscript

对于chrome，则支持下面的MIME 类型：

text/javascript

text/ecmascript

application/javascript

application/ecmascript

application/x-javascript

text/javascript1.1

text/javascript1.2

text/javascript1.3

text/jscript

text/live script

正确的设置

nosniff – 这个是唯一正确的设置，必须这样。

通常不正确的设置

‘nosniff’ – 引号是不允许的

: nosniff – 冒号也是错误的

如何检测

在IE和chrome中打开开发者工具，在控制台中观察配置了nosniff和没有配置nosniff的输出有啥区别。

参考文献

Microsoft Post on Reducing MIME type security risks

Chromium Source for parsing nosniff from response

Chromium Source list of JS MIME types

MIME Sniffing Living Standard

3. X-Frame-Options

目的

这个header主要用来配置哪些网站可以通过frame来加载资源。它主要是用来防止UI redressing 补偿样式攻击。IE8和firefox 18以后的版本都开始支持ALLOW-FROM。chrome和safari都不支持ALLOW-FROM，但是WebKit已经在研究这个了。

正确的设置

DENY – 禁止所有的资源（本地或远程）试图通过frame来加载其他也支持X-Frame-Options 的资源。

SAMEORIGIN – 只允许遵守同源策略的资源（和站点同源）通过frame加载那些受保护的资源。

ALLOW-FROM http://www.example.com – 允许指定的资源（必须带上协议http或者https）通过frame来加载受保护的资源。这个配置只在IE和firefox下面有效。其他浏览器则默认允许任何源的资源（在X-Frame-Options没设置的情况下）。

通常不正确的设置

ALLOW FROM http://example.com – ALLOW和FROM 之间只能通过连字符来连接，空格是错误的。

ALLOW-FROM example.com – ALLOW-FROM选项后面必须跟上一个URI而且要有明确的协议（http或者https）

如何检测

可以通过访问test cases 来查看各种各样的选项 和浏览器对这些frame中的资源的响应。

参考文献

X-Frame-Options RFC

Combating ClickJacking With X-Frame-Options

4. Strict-Transport-Security

目的

Strict Transport Security (STS) 是用来配置浏览器和服务器之间安全的通信。它主要是用来防止中间人攻击，因为它强制所有的通信都走TLS。目前IE还不支持 STS头。需要注意的是，在普通的http请求中配置STS是没有作用的，因为攻击者很容易就能更改这些值。为了防止这样的现象发生，很多浏览器内置了一个配置了STS的站点list。

正确的设置

注意下面的值必须在https中才有效，如果是在http中配置会没有效果。

max-age=31536000 – 告诉浏览器将域名缓存到STS list里面，时间是一年。

max-age=31536000includeSubDomains – 告诉浏览器将域名缓存到STS list里面并且包含所有的子域名，时间是一年。

max-age=0 – 告诉浏览器移除在STS缓存里的域名，或者不保存此域名。

通常不正确的设置

直接将includeSubDomains设置为 https://www.example.com ，但是用户依然可以通过 http://example.com 来访问此站点。如果example.com 并没有跳转到 https://example.com 并设置 STS header，那么访问 http://www.example.com 就会直接被浏览器重定向到 https://www.example.com 。

max-age=60 – 这个只设置域名保存时间为60秒。这个时间太短了，可能并不能很好的保护用户，可以尝试先通过http来访问站点，这样可以缩短传输时间。

max-age=31536000 includeSubDomains – max-age 和 includeSubDomains 直接必须用分号分割。这种情况下，即使max-age的值设置的没有问题，chrome也不会将此站点保存到STS缓存中。

max-age=31536000, includeSubDomains – 同上面情况一样。

max-age=0 – 尽管这样在技术上是没有问题的，但是很多站点可能在处理起来会出差错，因为0可能意味着永远不过期。

在数据测试时基本都要涉及到跨域请求和提取header中的字段，网上有很多方法，但一定能成功，以下两段记录了本次网站前后端接口测试过程中两个主要的微小问题。

解决跨域调用服务并设置headers 主要的解决方法需要通过服务器端设置响应头、正确响应options请求，正确设置 JavaScript端需要设置的headers信息 方能实现。

此处手札 供后人参考~

1.第一步 服务端设置响应头

header('Access-Control-Allow-Origin:*') //支持全域名访问，不安全，部署后需要固定限制为客户端网址

header('Access-Control-Allow-Methods:POST,GET,OPTIONS,DELETE')//支持的http 动作

header('Access-Control-Allow-Headers:x-requested-with,content-type') //响应头 请按照自己需求添加。

2.第二部 了解IE chrome 等浏览器 对于 跨域请求并要求设置Headers自定义参数的时候的 "预请求" 就是如果遇到 跨域并设置headers的请求，所有请求需要两步完成！

A 第一步：发送预请求 OPTIONS 请求。此时 服务器端需要对于OPTIONS请求作出响应 一般使用202响应即可 不用返回任何内容信息。（能看到这份手稿的人，本人不相信你后台处理不了一个options请求）

B 第二步：服务器accepted 第一步请求后 浏览器自动执行第二步 发送真正的请求。此时 大多数人 会发现请求成功了，但是 有那么几个人会发现 请求成功了但是没有任何信息返回 why？因为你自定义的请求头在服务器响应中不存在！

查看console输出 会发现一个问题：

“Access-Control-Allow-Headers 列表中不存在请求标头 XXXXXX”【IE】，

request header field xxxxxx is not allowed by Access-Control-Allow-Header【chrome】

这是因为 你的XXXX请求头 没有在服务器端被允许哦~

遇到这个问题 只有通过修改服务器端来完成，举例：需要设置 requesttype这么一个自定义头，那么 你需要在 服务端里面 将header('Access-Control-Allow-Headers:x-requested-with,content-type，requesttype') 同学们自行体会吧 这种语法就是根据“,”分割 自己需要设置什么头，必须要在 服务端请求的响应头里面设置好，不然客户端永远永远提交不上去！

转自： http://www.cnblogs.com/cdemo/p/5158663.html

3）Access-Control-Expose-Headers

该字段可选。CORS请求时，XMLHttpRequest

对象的getResponseHeader()

方法只能拿到6个基本字段：Cache-Control、Content-Language、Content-Type、Expires、Last-Modified、Pragma

如果想拿到其他字段，就必须在Access-Control-Expose-Headers里面指定。上面的例子指定，getResponseHeader('FooBar')可以返回FooBar字段的值。

转自： http://www.ruanyifeng.com/blog/2016/04/cors.html