网站安全头缺失检测工具与批量修复脚本

网站安全头（Security Headers）缺失，不是一种漏洞，而是一道本该焊死的防盗门被拆了。攻击者不需要费劲找SQL注入或跨站脚本，只要浏览器允许，他们可以直接在用户浏览器里执行恶意脚本、窃取Cookie、劫持点击、降级HTTPS连接。安全头缺失带来的风险包括但不限于跨站脚本攻击（XSS）、点击劫持、MIME类型嗅探攻击、中间人降级攻击、敏感信息泄露。更麻烦的是，这类问题在中小型站点上几乎是通病，因为开发框架默认不开启，运维又没意识到。

解决这个问题分两步：第一，你得知道缺了哪些头；第二，你得能批量修，因为手改几十个Nginx配置文件根本不现实。下面直接讲检测工具怎么用，以及批量修复脚本怎么写，所有代码都能直接落地。

检测不是随便扫一下，要覆盖这几个关键响应头：Content-Security-Policy（CSP）控制脚本和资源的加载来源，缺失意味着XSS攻击面完全敞开；Strict-Transport-Security（HSTS）强制浏览器只能用HTTPS访问，缺失会让中间人攻击有机可乘；X-Content-Type-Options用来阻止浏览器对MIME类型的自动嗅探，缺失可能导致恶意文件被错误解析执行；X-Frame-Options或CSP中的frame-ancestors指令防止页面被嵌入到iframe中，缺失意味着点击劫持风险；Referrer-Policy控制请求中Referer头的信息量，缺失可能导致敏感URL参数泄露；Permissions-Policy限制浏览器特性的使用权限，缺失会让摄像头、麦克风、定位等API暴露给任意脚本。

检测时还要看这些头的值配置得对不对，不是有就行。比如CSP头里写了unsafe-inline等于白设，HSTS的max-age设成0等于没开。所以检测工具必须能解析头的内容，而不仅仅是判断头是否存在。

直接用现成的在线扫描服务当然可以，但如果你要批量检测几百个域名，或者需要集成到CI/CD流水线里，自己写一个脚本更灵活。下面这段代码用requests库发请求，然后逐个检查安全头是否存在，并对CSP和HSTS做简单的值校验。

import requests
from urllib.parse import urlparse

def check_security_headers(url):
    if not url.startswith('http'):
        url = 'https://' + url
    
    try:
        response = requests.get(url, timeout=10, allow_redirects=True)
        headers = response.headers
        result = {'url': url, 'status': response.status_code, 'checks': {}}
        
        # 检查各个安全头
        csp = headers.get('Content-Security-Policy')
        result['checks']['CSP'] = {
            'present': csp is not None,
            'value': csp,
            'warning': 'unsafe-inline found' if csp and 'unsafe-inline' in csp else None
        }
        
        hsts = headers.get('Strict-Transport-Security')
        result['checks']['HSTS'] = {
            'present': hsts is not None,
            'value': hsts,
            'warning': 'max-age too low' if hsts and 'max-age=0' in hsts else None
        }
        
        xcto = headers.get('X-Content-Type-Options')
        result['checks']['X-Content-Type-Options'] = {
            'present': xcto is not None,
            'value': xcto,
            'warning': 'value not nosniff' if xcto and xcto.lower() != 'nosniff' else None
        }
        
        xfo = headers.get('X-Frame-Options')
        frame_ancestors = None
        if csp and 'frame-ancestors' in csp:
            frame_ancestors = 'found in CSP'
        result['checks']['X-Frame-Options'] = {
            'present': xfo is not None or frame_ancestors is not None,
            'value': xfo or frame_ancestors,
            'warning': None
        }
        
        rp = headers.get('Referrer-Policy')
        result['checks']['Referrer-Policy'] = {
            'present': rp is not None,
            'value': rp,
            'warning': None
        }
        
        pp = headers.get('Permissions-Policy')
        result['checks']['Permissions-Policy'] = {
            'present': pp is not None,
            'value': pp,
            'warning': None
        }
        
        return result
    except Exception as e:
        return {'url': url, 'error': str(e)}

# 批量检测
domains = ['example.com', 'testsite.cn']
for domain in domains:
    result = check_security_headers(domain)
    print(f"\n=== {result['url']} ===")
    if 'error' in result:
        print(f"Error: {result['error']}")
        continue
    for header, check in result['checks'].items():
        status = '✓' if check['present'] else '✗'
        warning = f" [{check['warning']}]" if check.get('warning') else ''
        print(f"{status} {header}{warning}")

这段脚本的检测逻辑很直接，但有几个细节值得注意。第一，allow_redirects设为True，因为有些站点会在重定向链中丢失安全头，你需要检查最终落地页的头。第二，HSTS的检查不能只看头是否存在，max-age至少应该设成31536000（一年）才有实际意义，设成0等于告诉浏览器“别记了”，这跟没设一样。第三，X-Frame-Options和CSP中的frame-ancestors指令功能重叠，只要有一个生效就行，所以检测逻辑里做了合并判断。

很多运维人员拿到检测报告后，直接搜一段配置粘贴进去，结果反而引入了新问题。CSP头最容易踩坑。如果你不打算花时间梳理站点实际加载了哪些第三方资源，就不要轻易开启CSP的强制执行模式，先用Content-Security-Policy-Report-Only头收集违规报告，等确认策略无误后再切换。default-src 'self'看起来很安全，但如果你的站点用了CDN上的字体、统计脚本、内联样式，页面会直接挂掉。正确做法是先梳理资源来源列表，然后逐步收紧策略。

HSTS的配置要注意includeSubDomains这个指令。如果你在主域名上开了HSTS并加了includeSubDomains，那所有子域名都必须走HTTPS。只要有一个子域名还没配SSL证书，用户就完全访问不了那个子域名。所以开启之前，先确认所有子域名的HTTPS部署情况。

X-Content-Type-Options这个头只有一个有效值nosniff，配了就生效，没什么好纠结的。但要注意，如果你的站点确实需要让浏览器自动识别某些资源的MIME类型（比如老旧的API接口返回了错误的Content-Type），这个头会导致功能异常。不过这种情况极少，绝大多数站点都应该无脑开启。

检测出问题后，手动去每台服务器上改配置效率太低。如果你的站点跑在Nginx上，可以用下面这个思路做批量修复。核心逻辑是：读取检测结果，根据缺失的头生成对应的Nginx配置片段，然后通过自动化工具（Ansible、SaltStack或者简单的SSH脚本）推送到服务器并reload。

def generate_nginx_config(missing_headers):
    config_lines = []
    
    if 'Strict-Transport-Security' in missing_headers:
        config_lines.append('add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;')
    
    if 'X-Content-Type-Options' in missing_headers:
        config_lines.append('add_header X-Content-Type-Options "nosniff" always;')
    
    if 'X-Frame-Options' in missing_headers:
        config_lines.append('add_header X-Frame-Options "DENY" always;')
    
    if 'Referrer-Policy' in missing_headers:
        config_lines.append('add_header Referrer-Policy "strict-origin-when-cross-origin" always;')
    
    if 'Permissions-Policy' in missing_headers:
        config_lines.append('add_header Permissions-Policy "camera=(), microphone=(), geolocation=()" always;')
    
    if 'Content-Security-Policy' in missing_headers:
        # 这里只生成一个基础的CSP模板，实际需要根据站点情况调整
        config_lines.append('add_header Content-Security-Policy "default-src \'self\'; script-src \'self\'; style-src \'self\' \'unsafe-inline\'; img-src \'self\' data:; font-src \'self\';" always;')
    
    return '\n'.join(config_lines)

# 模拟检测结果
detected_issues = {
    'example.com': ['Strict-Transport-Security', 'X-Content-Type-Options', 'X-Frame-Options'],
    'testsite.cn': ['Referrer-Policy', 'Permissions-Policy']
}

for domain, missing in detected_issues.items():
    print(f"\n# Configuration for {domain}")
    print(generate_nginx_config(missing))

这段代码生成的配置可以直接插入到Nginx的server块里。注意每个add_header后面都加了always参数，这很关键。不加always的话，Nginx只会在成功响应（2xx和3xx）里添加这些头，而4xx和5xx错误页面不会带安全头。攻击者可以利用这个特性，故意触发错误页面来绕过安全头的保护。加上always后，不管什么状态码都会输出安全头。

对于Apache用户，逻辑类似，只是语法变成Header always set。对于IIS用户，需要在web.config里配置customHeaders节点。批量推送时，建议先用配置管理工具做灰度发布，先上一台服务器验证，确认站点功能正常后再全量推送。安全头配置不当真的会把站点搞挂，CSP配错一个来源，整个页面的脚本和样式就全被浏览器拦截了。

一次性修复只是起点，真正的安全在于持续监控。把安全头检测脚本集成到CI/CD流水线里，每次部署前自动扫描，发现缺失或配置错误就阻断发布。可以给检测脚本加一个返回码逻辑：如果关键头（HSTS、CSP、X-Content-Type-Options）缺失，脚本返回非零退出码，CI/CD平台就会自动标记构建失败。

另外，检测频率不能只依赖部署时扫描。线上环境可能会因为配置漂移导致安全头丢失，比如运维临时改了一台服务器的Nginx配置但忘了同步。建议用定时任务每天对所有域名做一次全量扫描，结果输出到监控平台，有异常就告警。检测脚本本身也要做异常处理，网络超时、DNS解析失败、SSL证书错误这些情况都要捕获，不能因为脚本报错就漏掉一个站点的检查。

安全头的检测和修复看起来是小事，但它在纵深防御体系里扮演的是最后一道防线。漏洞修不完，0day永远存在，但安全头能让攻击者的利用成本大幅上升。一个配置正确的CSP头，可以把XSS攻击从“拿到Cookie就走”变成“拿了也没用”。这种投入产出比极高的安全措施，没有任何理由不做。