配置响应头 提高网页安全性 让跑分达到A+！
配置安全响应头可以有效地防止客户端被入侵
检测网址
介绍与配置
HTTP严格传输安全(HSTS)
http是明文传输，完全没有任何加密，这意味着任何人都可以从传输数据中获取浏览器到服务器间的所有内容。所以https使用的TLS加密十分值得推崇。然而，除非特殊指定https，否则每次用域名访问时，都会首先向服务器发送http请求，再由服务器发送重定向到浏览器，接着浏览器才会升级为https。
HSTS就是解决这一问题的方法。
当浏览器接收到https站点发送的Strict-Transport-Security头，浏览器便会遵守参数规定的时间执行https访问，当浏览器再次访问该站且未过规定时间时，浏览器便不会再发出HTTP请求，而是直接转用https连接，这防止了SSL剥离等针对尚未升级为https连接的攻击。
e.g.
Strict-Transport-Security: max-age=63072000; includeSubDomains; preload该头具有三个参数：max-age=63072000、includeSubDomains、preload。
max-age=表明保持HTTPS连接的时间，后跟秒数，如max-age=31536000含义为一年内仅使用https连接includeSubDomains表示该域名下所有子域名皆使用https访问
HSTS很好，但最原始最开始的那次连接始终是http，如果有个图谋已久的脚本小子渗透专家始终盯着一举一动，那该怎么办？
preload参数便是用于解决这一问题。浏览器会从Chrome或Firefox预加载列表里获取应直接使用https连接的站点。该列表可在HSTSpreload主动提交
该列表可用chrome://net-internals/#hsts在本地Chrome上查询和删改
X-Frame-Options
Content-Security-Policy 响应头有一个 frame-ancestors 参数可以完美替代X-Frame-Options响应头且具有更多特性X-Frame-Options HTTP 响应头是用来给浏览器指示允许一个页面可否在
<frame>、<iframe>、<embed>或者<object>中展现的标记。站点可以通过确保网站没有被嵌入到别人的站点里面，从而避免点击劫持攻击。
e.g.
X-Frame-Options: SAMEORIGIN该头仅有两个参数，SAMEORIGIN和DENY。
SAMEORIGIN表明该页面只允许同源域名展示frameDENY表明完全不允许任何frame
X-Content-Type-Options
该头的主要作用是要求客户端严格遵守响应头Content-Type中规定的文件MIME类型。否则浏览器会使用MIME-sniffing猜测返回文件的内容并执行
如果该头没有被配置，那么隐藏在图片或其他媒体文件中的javascript和css就可能被攻击者利用来渗透系统
e.g.
X-Content-Type-Options: nosniff该头仅有nosniff一个参数来提示客户端
nosniff将阻止请求与MIME类型不符的情况发生。
X-XSS-Protection
该头的作用和其名字一样一目了然，基于浏览器防护XSS攻击，因此不属于任何规范和草案中。
e.g.
X-XSS-Protection: 1; mode=block该头有四个参数~引用自Mdn~
-
0禁止 XSS 过滤。 -
1表明启用 XSS 过滤。如果检测到跨站脚本攻击，浏览器将清除页面（删除不安全的部分）。 -
1;mode=block表明启用 XSS 过滤。如果检测到攻击，浏览器将不会清除页面，而是阻止页面加载。 -
1; report=<reporting-URI>仅chrome 4-77版本支持。该参数表明启用 XSS 过滤。如果检测到跨站脚本攻击，浏览器将清除页面并使用 CSP report-uri 的功能发送违规报告。
Permissions Policy
该头可用来控制页面可访问的浏览器功能，这可以让站点先一步为自身划定可能使用权限范围
e.g.
Permissions-Policy: geolocation=()该头具有很多个参数，参数语法为<directive>=<allowlist>，前半部分表示权限，后半部分表示允许的白名单。
是否允许设置document.domain
是否允许使用加密媒体扩展API (EME)
任务在未呈现时是否应在框架中执行
任务在可见视口之外时是否应在帧中执行
是否允许使用Element.requestFullscreen()
是否允许使用Gamepad API
是否允许使用Geolocation API
是否允许通过界面收集有关设备方向的信息
是否允许使用WebHID API连接到不常见或奇异的人机界面设备，例如备用键盘或游戏手柄。
是否允许使用空闲检测 API来检测用户何时与他们的设备交互
是否允许收集有关用户本地安装字体的数据
是否允许通过界面收集有关设备方向的信息
是否允许使用音频输入设备
是否允许使用Web MIDI API
是否允许使用Payment Request API
是否允许通过相应的API以画中画模式播放视频。
是否允许使用Web Authentication API来检索已存储的公钥凭据
是否允许使用屏幕唤醒锁定 API来指示设备不应关闭或调暗屏幕
是否允许使用Web Serial API与串行设备通信，通过串行端口直接连接，或通过 USB 或蓝牙设备模拟串行端口
是否允许使用音频输出设备 API来列出和选择扬声器
是否允许使用Web USB API
是否允许使用Navigator.share(), Web Share API 将文本、链接、图像和其他内容共享到用户选择的任意目的地，例如移动应用程序
是否允许使用WebXR 设备 API与 WebXR 会话进行交互
是否允许收集有关设备加速度信息
是否允许收集有关设备周围环境中的亮度信息
是否允许自动播放通过HTMLMediaElement请求的媒体。
是否允许使用电池状态 API
是否允许使用视频输入设备
是否允许使用该getDisplayMedia()方法捕获屏幕内容
白名单则具有三种值：
*: 允许当前页面及所有呈现在页面中的内容使用该功能(): 不允许使用该功能(self "https://example.org"): 该种参数允许使用通配符，每个允许站点间以空格 隔开，self表示本页面
内容安全策略（CSP）
该头定义了哪些内容允许被该页面使用并执行。
CSP配置很复杂，详情可以看看阮一峰老师的博客 Content Security Policy 入门教程
我可不想重造轮子绝不是因为懒得写
配置好CSP头后也可以使用Google提供的CSP Evaluator检测一下自己的CSP策略是否强力
跑分
最上面的两个检测网址均可对响应头进行检测，Securityheaders的检测没有Mozilla家的那么严苛，一般来讲检测如果能达到A+就表明安全性响应头配置得差不多了。
