存储型XSS的何防护存可怕之处在于它把恶意脚本写进了数据库。攻击者提交一段带<script>的储型评论，服务器不校验直接存库，何防护存其他用户打开页面时这段脚本就在浏览器里执行了。储型2018年英航数据泄露事件，何防护存就是储型攻击者通过存储型XSS窃取了38万条支付信息——脚本挂在购物页面上，用户填完信用卡点提交，何防护存数据先被脚本截获，储型再发给正常服务器。何防护存

防护第一道闸门是储型输入过滤。但别指望黑名单，何防护存攻击者用<img src=x onerror=alert(1)>或<svg/onload=alert(1)>这类变体轻松绕过。储型正确做法是何防护存白名单校验——只允许预期格式，比如用户名限定为字母数字和下划线，储型评论内容剥离所有HTML标签。何防护存我在某电商平台做测试时，往商品描述里塞了<iframe src=//evil.com>，结果后台直接渲染了。后来开发加了白名单，只保留<b>和<i>，攻击面立刻缩小。

输出编码是第二道防线，比输入过滤更关键。数据从数据库取出后渲染到HTML上下文时，必须按位置编码。在标签内就做HTML实体编码，把<变成<；在JavaScript字符串里就做JS转义。这里有个常被忽略的坑——富文本编辑器。你允许用户提交带格式的内容，就得用专门的富文本清洗库，比如DOMPurify，它会把危险的onerror属性、javascript:协议全部剥掉。别自己写正则清洗，你永远想不到攻击者能构造出什么花活。

第三招是CSP（内容安全策略）。设置Content-Security-Policy: default-src 'self'，浏览器就拒绝加载外部脚本。就算攻击者把脚本存进数据库，CSP也会直接拦下执行。注意CSP要逐步收紧，一次性设太严可能连自己站点的正常功能都搞挂。我见过一个团队把CSP设成script-src 'unsafe-inline'，等于没设，因为内联脚本全放行了。

还有个细节：HttpOnly Cookie。虽然它防的是XSS窃取会话，但配合存储型XSS时能降低危害等级。攻击者拿到页面控制权却拿不到Cookie，至少没法直接冒充登录用户。

最后说个实战经验。别只测输入框，多测那些你没想到的存储位置——用户头像的URL参数、导出文件的文件名、甚至HTTP头里的Referer。攻击者会把payload塞进任何能持久化的字段里。我去年挖过一个漏洞，是在用户“收货地址”的备注栏存了payload，管理员后台一打开订单列表就触发。你猜开发为什么没发现？因为测试用例只覆盖了评论区和昵称。

存储型XSS的防护没有银弹，三层叠加才靠谱：输入白名单、输出按上下文编码、CSP兜底。每层都有绕过可能，但叠一起攻击成本就高到不值得了。定期拿扫描器打自己系统，别等黑产来帮你测试。