跨站脚本漏洞（XSS）之所以长期占据Web安全风险的前列，不是因为它有多高的技术门槛，而是因为它直接利用了浏览器对网站原生代码的信任。攻击者只要找到一个能向页面注入脚本的入口，就能在访问者浏览器里执行任意JavaScript，读取Cookie、劫持会话、篡改页面内容甚至发起钓鱼。很多网站只把修复重点放在用户可见的评论框或搜索框，却忽略了URL参数、HTTP头、上传文件名、错误提示页等隐蔽入口。要真正修复XSS，必须从输出编码、输入校验、内容安全策略和运行时监控四个层面同时下手，而不是只堵某一个点。

先定位所有不可信数据的输出点

修复XSS的第一步不是急着改代码，而是把所有“不可信数据进入HTML”的位置找出来。不可信数据包括URL参数、表单提交、Cookie、HTTP Referer、上传文件名、第三方API返回内容、甚至数据库里历史遗留的脏数据。输出点不只是页面主体，还包括JavaScript变量、HTML属性、CSS样式、事件处理器、meta标签和JSON响应。一个常见的遗漏是错误提示页直接回显用户输入的URL，比如404页面显示“找不到 /xxx”，如果xxx里带有脚本片段且未转义，就会触发反射型XSS。建议用自动化扫描器结合人工代码审计，把所有echo、print、innerHTML、document.write、eval、setTimeout字符串拼接等危险调用全部列出来，形成一张输出点清单。

输出编码必须按上下文区分

很多人以为用htmlspecialchars把尖括号转义掉就万事大吉，实际上XSS的触发上下文远不止HTML标签之间。在HTML文本节点里，把<和>转义确实有效；但在属性值里，还需要转义引号和空格；在JavaScript字符串里，HTML编码完全无效，必须用JavaScript转义或直接避免把数据放进脚本；在URL里，要校验协议并做URL编码。一个典型错误是把用户输入直接拼进onclick="go('<?php echo $url; ?>')"，即使做了HTML实体编码，攻击者仍可注入单引号闭合属性再插入新事件。正确做法是：HTML文本用HTML编码，属性用属性编码，JavaScript上下文用JSON序列化或严格白名单，URL用协议白名单加encodeURIComponent。不同上下文混用编码是XSS反复出现的根源。

输入校验做白名单而不是黑名单

输入校验的价值在于从源头减少危险字符进入系统，但不能替代输出编码。黑名单过滤容易被大小写混写、编码变形、Unicode绕过，比如过滤script却挡不住scr<script>ipt或script。白名单思路是根据字段用途限定允许的字符集：用户名只允许字母数字下划线，手机号只允许数字和加号，颜色值只允许十六进制，URL只允许http和https协议。对于富文本输入，不要自己写正则去过滤标签，应使用成熟的HTML净化库，基于白名单标签和属性做解析后重建，比如只允许p、br、strong、em、a等基础标签，a标签只保留href且强制协议白名单。富文本是XSS重灾区，自己写过滤器的失败率极高。

修复DOM型XSS要管住危险API

DOM型XSS不经过服务端，攻击载荷在浏览器端被JavaScript读取并写入页面。危险API包括innerHTML、outerHTML、document.write、eval、new Function、setTimeout字符串参数、location.href赋值、window.open等。修复原则是尽量不用这些API，改用textContent、createElement、setAttribute等安全方法。如果业务必须用innerHTML插入动态内容，插入前必须经过HTML净化。对于从location.hash、location.search、document.referrer取值的代码，要特别警惕它们被直接拼进HTML或脚本。一个实用的做法是在前端构建时引入静态扫描规则，禁止在代码中出现innerHTML赋值和eval调用，确需使用的必须加注释说明并经过安全评审。

Cookie防护减少XSS得手后的损失

XSS最直接的危害是窃取会话Cookie，因此给Cookie加上HttpOnly属性是必须做的。HttpOnly让JavaScript无法通过document.cookie读取该Cookie，即使XSS成功也无法直接偷走会话标识。但HttpOnly不能阻止攻击者利用XSS发起请求，因为浏览器仍会自动携带Cookie，所以还需要配合SameSite属性。SameSite=Lax或Strict可以限制跨站请求携带Cookie，降低CSRF和部分XSS利用场景的风险。对于登录后的敏感操作，建议使用短时效的独立凭证或二次验证，不要把长期有效的会话凭证暴露在XSS可触及的范围。Secure属性确保Cookie只在HTTPS下传输，防止中间人截获。

内容安全策略是最后一道系统性防线

内容安全策略（CSP）通过HTTP响应头告诉浏览器哪些资源可以加载、哪些脚本可以执行。一个严格CSP能阻断大部分XSS的脚本执行，即使攻击者成功注入了script标签，浏览器也会因为来源不在白名单而拒绝执行。配置CSP要遵循最小权限原则：script-src只允许自身域名和必要的可信CDN，禁止unsafe-inline和unsafe-eval；object-src设为none；base-uri设为self；frame-ancestors限制嵌入来源。对于需要内联脚本的旧系统，可以先使用nonce或hash机制，给每个内联脚本生成一次性随机数，攻击者无法预知nonce值，注入的脚本就不会被执行。CSP上线前要用Report-Only模式观察一段时间，收集违规报告并调整策略，避免直接阻断正常业务。

用安全框架和模板引擎减少人为失误

手写拼接HTML是XSS高发的原因之一，现代前端框架如React、Vue、Angular默认对插值表达式进行转义，能有效减少基础XSS。但框架不是万能的，React的dangerouslySetInnerHTML、Vue的v-html、Angular的bypassSecurityTrustHtml都是明确的危险出口，使用时要格外谨慎。后端模板引擎如Jinja2、Thymeleaf、Blade默认自动转义，但开发者有时为了显示原始HTML而关闭转义，这等于主动打开了漏洞。规范应该是：默认转义必须开启，关闭转义的代码必须经过审批，并在代码库中搜索所有关闭转义的关键字，确保没有遗漏。

上传文件和富媒体场景的XSS风险

上传功能常被忽略XSS风险。攻击者可以上传包含脚本的SVG文件，因为SVG本质是XML，浏览器直接打开时会执行其中的script。HTML文件、含JavaScript的PDF、带宏的Office文档也可能在特定场景触发脚本。修复方法是：对上传文件做类型白名单，只允许图片、文档等必要类型；对SVG做服务端净化或直接禁止；所有下载响应设置Content-Disposition: attachment，强制浏览器下载而不是在线打开；图片使用独立域名提供服务，该域名不设置Cookie且不执行脚本，即使图片中混入HTML也不会影响主站。

持续监控和回归测试防止修复回退

XSS修复不是一次性的，新功能上线、代码重构、第三方组件更新都可能重新引入漏洞。需要把XSS检测纳入CI/CD流程，在代码提交和发布前运行静态扫描和动态扫描。静态扫描工具能发现代码中的危险API调用和拼接模式，动态扫描工具通过注入测试向量验证实际输出是否被转义。对于已修复的漏洞，要建立回归测试用例，确保后续改动不会让修复失效。线上部署WAF可以作为补充防线，但不能依赖WAF，因为WAF规则可以被绕过，且无法覆盖DOM型XSS。定期对核心业务做人工渗透测试，重点关注登录、支付、个人信息修改、后台管理等高风险功能。

把安全责任落实到开发流程中

真正有效的XSS防护不是安全团队事后扫描，而是开发者在写代码时就清楚每个输出点的上下文和编码方式。团队内部需要建立安全编码规范，明确哪些API禁用、哪些必须净化、哪些需要审批。代码评审时把安全作为必查项，评审清单里包含“这个变量来自哪里”“输出到哪个上下文”“是否做了对应编码”。对于历史遗留系统，先通过扫描和人工梳理找出所有输出点，按风险排序逐步修复，优先处理无需登录即可触发的反射型XSS和存储型XSS。修复过程中保持业务功能不变，避免因为过度过滤导致正常内容无法显示。

XSS修复的核心不是记住某个函数或某条规则，而是理解数据从进入到输出的完整流动过程，在每个环节施加合适的控制。输入校验减少攻击面，输出编码阻断注入，Cookie属性降低损失，CSP兜底防护，流程规范防止回退。五层措施叠加起来，才能把XSS风险降到可接受的水平。只做其中任何一层，都可能在某个意想不到的入口被绕过。