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)的传递。
核心头及使用方法
Access-Control-Allow-Origin
:指定允许跨域请求的来源(如https://client.com
,*
表示允许所有,但若带凭据则不能用*
)。Access-Control-Allow-Methods
:允许的 HTTP 方法(如GET, POST, PUT
)。Access-Control-Allow-Headers
:允许的自定义请求头(如Authorization
)。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 的场景(如用户中心、支付系统)。
总结:安全头的最佳实践
- 多层防护:结合使用多个安全头(如 CSP + HSTS + X-Content-Type-Options),覆盖不同风险场景。
- 最小权限:遵循“最小必要”原则(如 CSP 仅允许必要的资源来源,Permissions-Policy 禁用不必要的特性)。
- 兼容性与监控:用
Report-Only
模式测试 CSP 等规则,通过报告机制监控违规行为。 - 优先现代方案:用 CSP 替代
X-Frame-Options
和X-XSS-Protection
,用SameSite
属性增强 Cookie 安全。
合理配置这些安全头,可大幅降低 Web 应用的安全风险,是构建安全系统的基础措施。