Nginx配置各种响应头防止XSS,点击劫持，frame恶意攻击

X-Content-Security-Policy响应头

===================================================================================================

W3C 的 Content Security Policy，简称 CSP。顾名思义，这个规范与内容安全有关，主要是用来定义页面可以加载哪些资源，减少 XSS 的发生。

Chrome 扩展已经引入了 CSP，通过 manifest.json 中的 content_security_policy 字段来定义。一些现代浏览器也支持通过响应头来定义 CSP。下面我们主要介绍如何通过响应头来使用 CSP，Chrome 扩展中 CSP 的使用可以参考 Chrome 官方文档。

HTTP 响应头Content-Security-Policy允许站点管理者控制用户代理能够为指定的页面加载哪些资源。

除了少数例外情况，设置的政策主要涉及指定服务器的源和脚本结束点。

Content-Security-Policy响应头的缺失使得目标URL更易遭受跨站脚本攻击。

浏览器兼容性

=============================================================================

早期的 Chrome 是通过 X-WebKit-CSP 响应头来支持 CSP 的，而 firefox 和 IE 则支持 X-Content-Security-Policy，

Chrome25 和 Firefox23 开始支持标准的 Content-Security-Policy

如何使用

===========================================================================

要使用 CSP，只需要服务端输出类似这样的响应头就行了：

Content-Security-Policy: default-src ‘self’

default-src 是 CSP 指令，多个指令之间用英文分号分割；‘self’ 是指令值，多个指令值用英文空格分割。目前，有这些 CSP 指令：

从上面的介绍可以看到，CSP 协议可以控制的内容非常多。而且如果不特别指定 ‘unsafe-inline’ 时，页面上所有 inline 样式和脚本都不会执行；不特别指定 ‘unsafe-eval’，页面上不允许使用 new Function，setTimeout，eval 等方式执行动态代码。在限制了页面资源来源之后，被 XSS 的风险确实小不少。

当然，仅仅依靠 CSP 来防范 XSS 是远远不够的，不支持全部浏览器是它的硬伤。不过，鉴于低廉的开发成本，加上也没什么坏处。

StrictTransportSecurity响应头

======