SRI 完整性哈希生成
Subresource Integrity Hash
为你粘贴或拖进来的脚本、样式表算出 Subresource Integrity 属性（sha256/384/512）。
一个指向 CDN 的 `<script src>`，等于长期授权那个 CDN 在你用户的浏览器里运行它想运行的任何代码。子资源完整性属性收回这份授权：哈希和你钉住的那个不一致的文件，浏览器拒绝执行。
把要发布的那个文件原样拖进来
就是你真正要提供的脚本或样式表。原样计算哈希。
用浏览器里的 WebCrypto 计算，得到的正是浏览器之后要比对的那个摘要。这里故意没有网址输入框：从本页去抓一个远程文件来算哈希，要么被 CORS 拦下，要么成了 SSRF 的入口，而且浏览器没法像服务器那样先解析再钉住一个主机。请放进你真正要发布的那个文件。
怎么用
给它文件或 URL
拖入你将要上线的那个文件，或者抓取一个 URL。哈希是对字节算的，所以一个文件和一个只差一个换行符的 URL 会给出不同的属性。
复制整个属性
输出是 `integrity="sha384-…"`。把它连同 `crossorigin="anonymous"` 一起粘到标签上——没有后者，跨域资源是不透明的，完整性无法校验。
钉住版本，不要钉一个会动的标签
对着 `@latest` URL 写的 integrity 属性，会在 CDN 发布新版的那天把站点弄坏。指向一个确切的版本，两者一起更新。
常见问题
该用哪种算法？
sha384 是通常的选择，也是大多数 CDN 公布的。sha256 也被接受，sha512 更强，但这个差别不是这套设计的弱点——钉错版本才是。
加上之后脚本就不加载了。
几乎总是三件事之一：CDN 上的文件变了、缺了 `crossorigin="anonymous"`、或者哈希取自和实际提供的不同的构建（比如压缩版对非压缩版）。
SRI 能防住一个从一开始就是恶意的、被篡改的脚本吗？
不能。它保证的是你拿到的是你钉住的那些字节，仅此而已。如果你钉住的版本本身已经带了后门，SRI 每一次都会忠实地把后门送到。
可以从这些接进来
接下来
这些工具吃得下当前工具的产出，结果可以直接送过去。
CSP 内容安全策略生成
CSP Builder
按引导表单或一份违规报告生成 Content-Security-Policy，并逐条解释每个指令。
文件校验和
File Checksum
不限大小地流式哈希文件，并和你粘贴进来的期望值当场比对。
安全响应头体检
Security Header Scan
给站点的 HSTS、CSP、框架、referrer 和权限相关响应头打分，并说明还该补上哪些。
可疑链接检查
Suspicious URL Check
在你点开之前先看这条链接长什么样——混淆字符、直接写 IP 的主机、@ 障眼法、层层子域、奇怪端口、短链服务——需要时还能追踪跳转并查域名注册时间；没有信誉库。
Base64 编码解码
Base64 Encoder & Decoder
对文本和文件做 Base64 与 Base64URL 编解码，UTF-8 处理正确。
密码泄露检测
Breach Check
查一个密码有没有出现在 Have I Been Pwned 的泄露数据里，浏览器只发出它 SHA-1 哈希的前五位（k-匿名）。