跨站脚本攻击（XSS）的阻止防御，本质上是跨站一场信任边界的博弈。攻击者利用的脚本决是应用程序对用户输入“过度信任”的漏洞——你让用户提交一段文字，他塞进来一段脚本，何解浏览器就傻乎乎地执行了。阻止解决思路其实就三条：过滤、跨站转义、脚本决隔离，何解但每一条执行不到位，阻止都会让防线形同虚设。跨站

先说最基础的脚本决过滤。很多开发者喜欢用黑名单，何解比如把``，全站用户打开页面就中招。所以，输出编码必须按位置来：HTML实体编码、JavaScript的Unicode转义、URL的百分号编码，一个都不能混。

第三条路是隔离，也就是CSP（内容安全策略）。这招是最后一道保险，就算前面全漏了，浏览器也能拦住脚本执行。CSP的核心是告诉浏览器“只准执行我指定的源”，比如`default-src 'self'`，那么任何内联脚本和外部未知域名的脚本都会被拒之门外。但CSP配置起来很拧巴——你要是用了一堆第三方统计脚本、CDN资源，规则就得写得很宽，一宽就形同虚设。我见过一个后台系统，为了省事直接`script-src 'unsafe-inline'`，等于把CSP关了。后来被黑了一次，才老老实实把脚本全挪到静态文件里，再开启严格CSP。

别忘了，XSS不光是技术问题，还是流程问题。开发规范里必须明确：任何用户输入，默认不可信。前端校验只是用户体验，后端必须重新校验一遍——因为攻击者完全可以绕过浏览器直接构造请求。我在一次渗透测试里，看到某个网站前端JS做了长度限制，但后端没做，结果一个超长字符串塞进去，直接把服务端日志撑爆，间接造成了反射型XSS的注入点。这种低级错误，靠代码审查就能避免。

最后说个反直觉的观察：很多团队花大价钱买WAF（Web应用防火墙），却连基本的输入输出编码都没做扎实。WAF是外挂，不是内功。攻击者用个编码混淆就能绕过规则，真正扛事儿的还是你代码里那一行`htmlspecialchars`或者一个严谨的CSP头。与其依赖外部工具，不如把开发人员的“安全意识”焊死在编码习惯里——每次写`echo $_POST['name']`的时候，先问自己一句：这玩意儿要是变成`

防御XSS没有一劳永逸的银弹。它靠的是每一层都多留个心眼，过滤、转义、隔离、规范，四件事都做到及格线以上，攻击者才会觉得你这块骨头难啃。