Http Security Headers

HTTP 安全相关的响应头（Security Headers）是 Web 应用安全防护的核心手段，通过浏览器与服务器的协作，防御跨站脚本（XSS）、点击劫持、中间人攻击、信息泄露等常见风险。以下是最常用的安全头及其作用机制、使用方法和适用场景的详细说明：

一、Strict-Transport-Security（HSTS）

作用机制

强制浏览器仅通过 HTTPS 协议与服务器通信，拒绝使用 HTTP 协议，彻底阻断“HTTP 降级攻击”“SSL 剥离攻击”等中间人攻击。

• 浏览器首次通过 HTTPS 接收该头后，会将域名加入本地缓存，在 max-age 有效期内，所有对该域名的请求会自动转为 HTTPS（即使输入 http:// 或点击 HTTP 链接）。

使用方法

格式：Strict-Transport-Security: max-age=<秒数>; [includeSubDomains]; [preload]

• max-age：必填，缓存有效期（秒），推荐 31536000（1 年）。
• includeSubDomains：可选，将规则应用到所有子域名（如 blog.example.com）。
• preload：可选，声明希望加入浏览器 HSTS 预加载列表（需申请，解决首次访问风险）。

示例（Nginx 配置）：

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;

适用场景

• 所有已部署 HTTPS 的网站（必须先确保 HTTPS 配置正确，否则会导致网站无法访问）。
• 尤其适合金融、电商等对传输安全要求高的场景，防止用户因输入 HTTP 地址或点击 HTTP 链接导致的安全风险。

二、Content-Security-Policy（CSP）

作用机制

通过白名单机制精确控制浏览器可加载的资源（脚本、样式、图片等）和执行的代码，从根本上防御 XSS、代码注入等攻击。

• 浏览器仅允许加载/执行 CSP 指令明确授权的资源（如 script-src 'self' 仅允许同源脚本），未授权的资源会被拦截。

使用方法

格式：Content-Security-Policy: 指令1 来源1 来源2; 指令2 来源3; ...
核心指令：

• default-src：所有资源的默认来源（未单独指定时继承）。
• script-src：控制 JavaScript 来源（防御 XSS 的核心）。
• style-src：控制 CSS 来源。
• img-src：控制图片来源。
• frame-ancestors：控制哪些域名可通过 iframe 嵌套当前页面（替代 X-Frame-Options）。

示例（严格限制脚本和框架）：

add_header Content-Security-Policy "default-src 'self'; script-src 'self' https://trusted-cdn.com; frame-ancestors 'self';" always;

仅报告模式（不拦截资源，仅发送违规报告）：

add_header Content-Security-Policy-Report-Only "script-src 'self'; report-uri /csp-report;" always;

适用场景

• 所有网站，尤其是用户输入频繁的场景（如评论、表单），防御 XSS 攻击。
• 需要限制第三方资源加载的场景（如仅允许指定 CDN 的脚本）。
• 替代 X-Frame-Options 和 X-XSS-Protection，提供更细粒度的控制。

三、X-Content-Type-Options

作用机制

阻止浏览器对资源进行MIME 类型嗅探，强制浏览器严格遵守服务器返回的 Content-Type 头，避免因 MIME 类型混淆导致的 XSS 攻击。

• 例如：服务器声明 Content-Type: text/plain 的文件，即使内容是 <script> 代码，浏览器也会当作纯文本显示，不会执行。

使用方法

唯一有效值：X-Content-Type-Options: nosniff

示例（Nginx 配置）：

add_header X-Content-Type-Options "nosniff" always;

适用场景

• 所有网站，尤其是允许用户上传文件的场景（如用户上传 .txt 文件伪装成脚本）。
• 静态资源服务器（如 CDN），防止攻击者替换资源内容后通过 MIME 嗅探执行恶意代码。

四、X-Frame-Options

作用机制

限制当前页面是否允许被其他页面通过 <iframe>、<frame> 等标签嵌套，防御点击劫持攻击（攻击者通过透明 iframe 诱导用户点击敏感操作）。

使用方法

取值：

• DENY：禁止任何网站嵌套当前页面（包括自身域名）。
• SAMEORIGIN：仅允许同源（协议+域名+端口相同）页面嵌套。
• ALLOW-FROM <uri>：仅允许指定域名嵌套（现代浏览器已不支持，推荐用 CSP 的 frame-ancestors 替代）。

示例（禁止任何嵌套）：

add_header X-Frame-Options "DENY" always;

适用场景

• 敏感操作页面（如登录、支付、删除数据）：用 DENY 完全禁止嵌套。
• 需在自身域名内嵌套的页面（如后台管理系统的子页面）：用 SAMEORIGIN。

五、X-XSS-Protection

作用机制

控制浏览器内置的XSS 过滤器行为，检测并拦截可能的 XSS 攻击代码（仅在旧版浏览器生效，现代浏览器已逐渐弃用）。

使用方法

取值：

• 0：禁用过滤器（不推荐）。
• 1：启用过滤器，检测到攻击时尝试移除恶意代码（可能导致页面异常）。
• 1; mode=block：启用过滤器，检测到攻击时完全阻止页面加载（更安全）。

示例：

add_header X-XSS-Protection "1; mode=block" always;

适用场景

• 需兼容旧版浏览器（如 IE 8-11、Chrome 77 及以下）的网站。
• 作为 CSP 的补充防护（现代浏览器优先遵循 CSP，忽略此头）。

六、Referrer-Policy

作用机制

控制页面跳转时，浏览器发送的 Referrer 头（包含来源页面 URL）的内容，保护用户隐私和网站信息不被泄露。

使用方法

常见取值：

• no-referrer：不发送任何 Referrer。
• no-referrer-when-downgrade：默认值，从 HTTPS 跳转到 HTTP 时不发送，其他情况发送完整 URL。
• same-origin：仅在同源跳转时发送 Referrer，跨域时不发送。
• strict-origin：跨域跳转时仅发送协议+域名+端口（如 https://example.com），不包含路径。

示例（跨域时仅发送域名）：

add_header Referrer-Policy "strict-origin" always;

适用场景

• 隐私敏感网站（如医疗、金融），防止用户访问路径泄露。
• 不希望第三方网站知道用户来源页面的场景（如内部系统跳转至外部网站）。

七、Permissions-Policy（原 Feature-Policy）

作用机制

限制浏览器对敏感特性（如摄像头、麦克风、地理位置、全屏等）的访问权限，防止第三方脚本滥用这些功能。

使用方法

格式：Permissions-Policy: 特性1=(来源1, 来源2); 特性2=(来源3); ...
常见特性：camera（摄像头）、microphone（麦克风）、geolocation（地理位置）、fullscreen（全屏）。

示例（仅允许同源脚本使用摄像头和麦克风）：

add_header Permissions-Policy "camera=('self'); microphone=('self')" always;

禁止所有网站使用某个特性：

add_header Permissions-Policy "geolocation=()" always; # 禁用地理位置

适用场景

• 不需要使用敏感特性的网站（如纯展示类网站）：禁用所有不必要的特性。
• 需限制第三方脚本权限的场景（如仅允许自身脚本使用摄像头，禁止广告脚本使用）。

八、Access-Control-Allow-*（CORS 相关头）

作用机制

跨域资源共享（CORS）相关头用于控制跨域请求的权限，允许或拒绝不同源的网站访问当前服务器的资源，同时规范跨域请求中凭据（如 Cookie）的传递。

核心头及使用方法

1. Access-Control-Allow-Origin：指定允许跨域请求的来源（如 https://client.com，* 表示允许所有，但若带凭据则不能用 *）。
2. Access-Control-Allow-Methods：允许的 HTTP 方法（如 GET, POST, PUT）。
3. Access-Control-Allow-Headers：允许的自定义请求头（如 Authorization）。
4. Access-Control-Allow-Credentials：是否允许跨域请求携带凭据（true/false，需与客户端 withCredentials 配合）。

示例（允许 https://client.com 跨域请求并携带凭据）：

location /api {add_header Access-Control-Allow-Origin "https://client.com" always;add_header Access-Control-Allow-Methods "GET, POST" always;add_header Access-Control-Allow-Credentials "true" always;if ($request_method = OPTIONS) {return 204; # 处理预检请求}
}

适用场景

• 提供跨域 API 的服务器（如前后端分离架构中，前端域名与 API 域名不同）。
• 需要跨域传递身份信息（如 Cookie）的场景（如单点登录 SSO）。

九、Set-Cookie（安全属性）

作用机制

通过 Set-Cookie 头设置 Cookie 时，附加安全属性限制 Cookie 的使用范围和方式，防止 Cookie 被窃取或滥用（如 XSS 劫持、CSRF 攻击）。

核心安全属性

• HttpOnly：禁止 JavaScript 访问 Cookie（防御 XSS 窃取 Cookie）。
• Secure：仅允许通过 HTTPS 传输 Cookie（防止 HTTP 传输时被拦截）。
• SameSite：限制跨站请求携带 Cookie（防御 CSRF），取值：
  • Strict：完全禁止跨站请求携带。
  • Lax：仅允许导航类跨站请求携带（如 <a> 标签跳转）。
  • None：允许跨站携带（需配合 Secure）。
• Max-Age/Expires：设置 Cookie 有效期，避免永久有效带来的风险。

示例（安全的 Session Cookie）：

add_header Set-Cookie "sessionid=abc123; HttpOnly; Secure; SameSite=Lax; Max-Age=86400" always;

适用场景

• 所有包含敏感信息的 Cookie（如登录 Session ID、认证 Token）。
• 尤其需要防御 XSS 和 CSRF 的场景（如用户中心、支付系统）。

总结：安全头的最佳实践

1. 多层防护：结合使用多个安全头（如 CSP + HSTS + X-Content-Type-Options），覆盖不同风险场景。
2. 最小权限：遵循“最小必要”原则（如 CSP 仅允许必要的资源来源，Permissions-Policy 禁用不必要的特性）。
3. 兼容性与监控：用 Report-Only 模式测试 CSP 等规则，通过报告机制监控违规行为。
4. 优先现代方案：用 CSP 替代 X-Frame-Options 和 X-XSS-Protection，用 SameSite 属性增强 Cookie 安全。

合理配置这些安全头，可大幅降低 Web 应用的安全风险，是构建安全系统的基础措施。