跨站脚本攻击（XSS）是网站安全中最常见也最容易被忽视的漏洞类型之一，它的本质是攻击者将恶意JavaScript代码注入到网页中，当其他用户浏览该页面时，恶意脚本就会在用户浏览器中执行，从而窃取Cookie、会话令牌、键盘记录甚至进行钓鱼重定向。要防护XSS攻击，核心手段就是两个字：过滤和转义。过滤是在数据输入阶段拦截危险字符和代码片段，转义是在数据输出阶段将特殊字符转换为安全的HTML实体，让浏览器把它们当作纯文本而非可执行代码来渲染。下面我会从原理到实践，把这套防护方案讲透。
一、先搞清楚XSS攻击到底是怎么发生的
XSS攻击分为三种类型：反射型XSS、存储型XSS和DOM型XSS。反射型XSS是攻击者构造一个带有恶意参数的URL，诱导用户点击后服务器直接把恶意代码反射回页面；存储型XSS是恶意代码被永久存储在数据库中，任何访问相关页面的用户都会中招；DOM型XSS则完全在客户端发生，通过修改页面DOM结构来触发脚本执行。不管哪种类型，攻击成功的前提都是：用户输入的内容没有被正确处理就直接输出到了页面上。所以防护的关键就在于——永远不要信任用户输入，永远在输出时做安全处理。
二、输入端过滤：把危险内容挡在门外
输入过滤是第一道防线，目的是在数据进入系统之前就识别并清除或拒绝危险内容。常见的危险字符包括：尖括号（< >）、引号（" '）、分号（;）、括号（( )）、斜杠（/）、&符号（&）、等号（=）以及javascript:、vbscript:、onerror=、onload=等事件触发关键词。
在实际开发中，可以使用白名单机制而非黑名单。黑名单永远有遗漏的风险，因为攻击者可以用各种编码方式绕过。白名单则只允许明确安全的字符通过。比如用户名只允许字母、数字和下划线，那就直接用正则表达式限定：
^[a-zA-Z0-9_]+$
如果业务场景需要允许一些特殊字符，比如富文本编辑器允许用户输入HTML标签，那就不能简单粗暴地全部过滤掉，而是要用专门的HTML净化库来处理。比如Java中的OWASP Java HTML Sanitizer、Python中的Bleach库、PHP中的HTML Purifier，这些库能在保留合法标签的同时剔除危险的属性和事件处理器。
需要特别注意的是，输入过滤不能替代输出转义。过滤只是辅助手段，因为你无法保证所有入口都做了完美过滤，也无法预见所有攻击变种。所以输出转义才是真正的核心防线。
三、输出端转义：让恶意代码变成无害文本
输出转义的原理是将HTML中具有特殊含义的字符转换为对应的HTML实体编码，这样浏览器在解析时就会把它们当作普通文本显示，而不会当作HTML标签或JavaScript代码去执行。以下是必须转义的核心字符对照：
< 转换为 <
> 转换为 >
& 转换为 &
" 转换为 "
' 转换为 '
/ 转换为 /
在不同的开发语言和框架中，转义函数各不相同。PHP中使用htmlspecialchars()函数：
$safe_output = htmlspecialchars($user_input, ENT_QUOTES, 'UTF-8');
Java中使用Apache Commons Text的StringEscapeUtils.escapeHtml4()：
String safeOutput = StringEscapeUtils.escapeHtml4(userInput);
Python中使用html.escape()：
import html safe_output = html.escape(user_input)
前端JavaScript中如果需要动态插入文本到DOM，应该使用textContent属性而不是innerHTML：
element.textContent = userInput; // 安全 // 避免使用 element.innerHTML = userInput; // 危险
这里有一个关键点：转义的方式要根据输出上下文来选择。如果数据是输出到HTML正文中，用HTML实体转义；如果是输出到JavaScript变量中，需要用JavaScript转义；如果是输出到URL参数中，需要用URL编码；如果是输出到CSS中，需要用CSS转义。上下文不同，转义规则完全不同，用错了等于没防护。
四、针对不同场景的具体防护策略
场景一：用户评论和留言板。这是存储型XSS的高发区。用户提交的内容会存入数据库，其他用户访问时会读取并渲染。防护方案是：存储时做输入过滤，读取输出时做HTML转义。同时在数据库层面，对存储的内容也做一次转义存储，作为双重保险。另外，设置Content Security Policy（CSP）头部，限制页面只能执行同源脚本，禁止内联脚本执行，即使有XSS漏洞也能大幅降低危害。
场景二：URL参数和表单输入。反射型XSS常通过URL参数注入。防护方案是：对所有GET和POST参数在输出到页面时统一转义。很多现代框架如React、Vue、Angular默认就会对插值表达式进行自动转义，但如果使用了v-html、dangerouslySetInnerHTML这类强制渲染HTML的API，就必须手动确保内容已经净化。
场景三：富文本编辑器。这是最复杂的场景，因为业务需求就是让用户输入带格式的HTML。解决方案是：前端用编辑器自带的过滤功能做初步处理，后端用HTML净化库做深度清洗。推荐使用DOMPurify这个JavaScript库，它在浏览器端就能完成净化，支持白名单配置：
const clean = DOMPurify.sanitize(dirty, {
ALLOWED_TAGS: ['b', 'i', 'em', 'strong', 'a'],
ALLOWED_ATTR: ['href', 'title']
});场景四：JSON数据输出到页面。有些开发者会把JSON数据直接嵌入到<script>标签中，如果JSON里包含用户输入的内容，攻击者可以用</script>来提前闭合标签注入代码。正确做法是对JSON中的特殊字符做转义，或者使用专门的JSON序列化工具确保安全输出。
五、Content Security Policy（CSP）作为纵深防御
CSP是浏览器层面的安全策略，通过HTTP响应头告诉浏览器哪些资源可以加载和执行。一个严格的CSP策略可以有效遏制XSS攻击的影响范围。推荐配置如下：
Content-Security-Policy: default-src 'self'; script-src 'self' 'nonce-随机值'; style-src 'self' 'unsafe-inline'; img-src 'self' data:;
核心要点是：禁止使用unsafe-inline执行内联脚本，所有脚本必须通过外部文件加载并配合nonce或hash验证。这样即使攻击者成功注入了脚本，浏览器也会因为CSP策略而拒绝执行。CSP不是替代转义和过滤的手段，而是在前面防线被突破后的最后一道屏障。
六、框架和工具层面的自动化防护
现代Web开发框架大多内置了XSS防护机制。React的JSX默认转义、Vue的模板插值默认转义、Angular的自动上下文感知转义，这些都大大降低了开发者犯错的概率。但开发者必须了解这些框架的"逃生舱"——即那些绕过自动转义的API，比如React的dangerouslySetInnerHTML、Vue的v-html、Thymeleaf的th:utext。使用这些API时必须手动确保数据安全。
此外，建议在开发流程中引入自动化安全扫描工具，如OWASP ZAP、SonarQube、Semgrep等，在代码提交和部署阶段自动检测潜在的XSS漏洞。定期进行渗透测试也是必要的，人工测试往往能发现自动化工具遗漏的边界情况。
七、容易被忽略的几个细节
第一，字符编码问题。如果页面编码声明和实际编码不一致，攻击者可能利用编码差异绕过转义。务必确保页面使用UTF-8编码，并在HTTP头和HTML meta标签中都明确声明。
第二，DOM型XSS的特殊性。这种攻击不经过服务器，完全在客户端发生。防护方法是避免使用eval()、setTimeout(string)、setInterval(string)、document.write()等可以执行字符串为代码的API，同时对所有动态修改DOM的操作进行严格的输入验证。
第三，第三方组件和库的安全。很多XSS漏洞不是自己写的代码出问题，而是引用的第三方JS库存在漏洞。定期更新依赖、使用npm audit或Snyk检查依赖安全、避免引入来路不明的脚本，这些都是基本功。
第四，HTTPOnly和Secure Cookie设置。即使XSS攻击成功，如果Cookie设置了HTTPOnly属性，JavaScript就无法读取Cookie，能有效防止会话劫持。配合Secure属性确保Cookie只在HTTPS下传输，进一步提升安全性。
八、总结：构建多层防护体系
XSS防护不是单一技术能解决的问题，而是需要构建纵深防御体系。输入过滤是第一层，输出转义是核心层，CSP是兜底层，框架自动防护是便利层，安全扫描和渗透测试是验证层。每一层都不能缺，每一层都有其特定的防护范围。作为开发者，最重要的意识是：任何来自用户的数据都是不可信的，任何输出到页面的数据都必须经过安全处理。把这个原则刻进开发习惯里，XSS漏洞自然就会大幅减少。网站安全没有银弹，只有持续的重视和系统化的防护策略，才能真正守住底线。
