UD5工具箱
常见问题解答
什么是 HTTP 安全头？为什么它们重要？
HTTP 安全头是在 HTTP 响应中添加的特殊头部信息，用于指示浏览器采取特定的安全策略。它们是 Web 安全防御体系的重要组成部分，与输入验证、参数化查询、访问控制等服务器端安全措施互补。正确配置安全头可以防范多种常见攻击：CSP 防范 XSS 攻击，HSTS 防范 SSL 剥离和会话劫持，X-Frame-Options 防范点击劫持，X-Content-Type-Options 防范 MIME 嗅探攻击。根据 OWASP 的安全建议，所有网站都应该配置基本的安全响应头。现代浏览器对安全头的支持越来越完善，配置安全头是一种低成本、高回报的安全加固措施。
Content-Security-Policy 为什么如此重要？
CSP 是目前防范 XSS 攻击最有效的单一安全机制。XSS 攻击允许攻击者在受害者浏览器中注入和执行恶意 JavaScript，窃取会话 Cookie、键盘记录、发起钓鱼攻击等。CSP 通过严格控制页面可以加载和执行哪些资源，即使攻击者成功注入了脚本标签，浏览器也会根据 CSP 策略阻止恶意脚本的执行。CSP 还支持 report-uri 指令，可以将违规行为发送到指定端点进行监控和分析。配置良好的 CSP 可以将 XSS 攻击的成功率降低 90% 以上。但 CSP 也是最复杂的安全头，需要仔细测试以确保不会影响网站的正常功能。
HSTS 的 preload 机制是什么？
HSTS preload 是一种解决 HSTS 首次访问安全问题的机制。HSTS 只在浏览器收到响应头后才生效，但首次访问时还没有收到响应头，攻击者可以在首次连接时进行 SSL 剥离。通过将域名加入浏览器的 HSTS 预加载列表，浏览器会在内置的列表中查找，对于列表中的域名，即使首次访问也会强制使用 HTTPS。要加入预加载列表，需要满足以下条件：配置有效的 HSTS 响应头（max-age 至少 31536000 秒，包含 includeSubDomains），所有子域名也支持 HTTPS，提供有效的 HTTPS 连接。提交申请后需要等待浏览器厂商审核和更新，这个过程可能需要数周到数月。
X-Frame-Options 和 CSP frame-ancestors 有什么区别？
X-Frame-Options 是较早的防点击劫持头部，只有三个选项（DENY、SAMEORIGIN、ALLOW-FROM），功能相对有限。CSP 的 frame-ancestors 指令是其现代替代方案，支持更灵活的来源控制，可以指定多个允许嵌入的来源。例如 frame-ancestors 'self' https://trusted.com 允许同源和指定域名的嵌入。frame-ancestors 还可以完全禁用嵌入（frame-ancestors 'none'），效果等同于 X-Frame-Options: DENY。虽然 frame-ancestors 功能更强大，但为了兼容旧版浏览器（如 IE 11），建议同时配置 X-Frame-Options 和 CSP frame-ancestors。
Set-Cookie 的 SameSite 属性应该怎么设置？
SameSite 属性控制 Cookie 在跨站请求中的发送行为，有三个值：Strict 表示完全不在跨站请求中发送 Cookie（最安全但可能影响从外部链接跳转到网站时的登录状态）；Lef 表示在顶层导航（如点击链接跳转）时发送，在跨站 AJAX/图片请求中不发送（推荐，平衡了安全性和用户体验）；None 表示始终发送（必须同时设置 Secure 属性，否则浏览器会拒绝）。对于大多数会话 Cookie，推荐使用 SameSite=Lax; Secure; HttpOnly 组合。对于需要在跨站请求中携带的 Cookie（如 CSRF Token），可以使用 SameSite=None; Secure。
为什么 fetch API 获取不到目标网站的响应头？
这是由于浏览器的 CORS（跨源资源共享）安全策略限制。当使用 fetch API 从一个域名请求另一个域名的资源时，浏览器会执行 CORS 检查。对于简单请求，浏览器会自动添加 Origin 头，服务器需要在响应中包含 Access-Control-Allow-Origin 头来允许跨域访问。对于非简单请求，浏览器会先发送预检请求（OPTIONS），服务器需要正确响应预检请求。即使 CORS 检查通过，浏览器默认也只允许 JavaScript 访问简单的响应头（如 Content-Type、Content-Length），对于安全相关的头部（如 Strict-Transport-Security、Content-Security-Policy），需要服务器在 Access-Control-Expose-Headers 中明确暴露。这就是为什么使用 fetch API 无法获取到完整的安全响应头。
Permissions-Policy 和 Feature-Policy 有什么区别？
Feature-Policy 是 Permissions-Policy 的前身，两者功能相似但有重要区别。Feature-Policy 于 2018 年引入，用于控制浏览器特性在页面和 iframe 中的使用权限。2020 年，W3C 将其重命名为 Permissions-Policy，并进行了 API 改进。主要区别包括：Permissions-Policy 使用新的语法格式（键值对形式），不再使用 Feature-Policy 的字符串解析方式；Permissions-Policy 支持通过 allow 属性在 iframe 上单独配置；Permissions-Policy 增加了对更多特性的支持。目前两者在浏览器中的支持情况略有不同，Chrome 96+ 完全支持 Permissions-Policy，Firefox 和 Safari 仍在逐步迁移中。建议新项目使用 Permissions-Policy，同时保留 Feature-Policy 以兼容旧版浏览器。
安全评分的计算依据是什么？
安全评分（0-100分）是根据所有检测的安全头的配置情况综合计算的。每个安全头根据其重要性和配置完整度获得一定的分数。评分因素包括：安全头是否存在（存在得分，缺失不得分）、配置值是否正确（正确得分，部分正确得部分分，错误不得分）、安全头的风险等级（高危安全头的权重更高）。例如，CSP 和 HSTS 作为最重要的安全头，在评分中占比较高。X-Frame-Options 和 X-Content-Type-Options 虽然配置简单但防护效果显著，也占一定权重。评分等级对应关系：A 级 90-100 分、B 级 75-89 分、C 级 60-74 分、D 级 40-59 分、F 级 0-39 分。建议所有网站至少达到 B 级。