XSS防护核心是上下文感知编码：HTML、JS、URL等不同上下文需用对应编码方式，CSRF需Token绑定会话且严格校验，CSP须全面配置并禁用unsafe选项，DOM型XSS需后端对API返回字段预清洗。
直接输出用户输入前必须做上下文感知编码
不加处理地把 user_input 插进 HTML、JS 或 URL，等于主动给 XSS 开门。关键不是“要不要转义”，而是“在哪种上下文中用哪种编码”。比如：user_input 被塞进 <div>{{ user_input }}</div>，用 HTML 实体编码（、<code>>）就够了；但若写进 <script>var data = "{{ user_input }}";</script>，光 HTML 编码没用，得用 JS 字符串编码，否则引号闭合后仍可注入。
常见错误现象：
- 用
html.escape()处理所有场景，结果在 JS 上下文中被绕过 - 前端用
innerHTML渲染服务端返回的富文本，却没走白名单过滤 - URL 参数拼进
<a href="xxx">时，忘了对&、=做 URL 编码
实操建议：
- Flask 模板中默认开启自动转义，但遇到
{{ user_input | safe }}要立刻警觉，确认该内容是否真的可信 - Django 模板同理，禁用
|safe或mark_safe()前，必须确保已做过白名单清洗（如用bleach.clean()） - 纯 Python 后端生成 HTML 片段时，优先用
html.escape(user_input, quote=True)，且只用于 HTML 文本上下文
CSRF Token 必须绑定会话且一次性验证
CSRF 防御失效，90% 是因为 Token 没和用户 session 绑死，或验证逻辑被绕过。Token 不是贴个标签就完事，它得满足：由服务端生成、与当前 session ID 关联、每次敏感请求都校验、校验失败立即拒绝且不泄露原因。
立即学习“Python免费学习笔记（深入）”；
常见错误现象：
- Token 存在客户端 localStorage，被跨域页面读取复用
- POST 请求未携带 Token 时，后端只打日志不拦截，攻击者可暴力试探
- 使用全局固定 Token（如配置文件里写死），所有用户共享一个值
实操建议：
- Flask 中用
flask-wtf的CSRFProtect，它默认将 Token 加密后存入 session，并在表单渲染时自动注入<input type="hidden" name="csrf_token"> - FastAPI 中推荐用
fastapi-csrf-protect库，它支持自定义加密密钥、Token 过期时间、以及SameSite=Lax的 Cookie 设置 - 手动实现时，Token 值必须调用
secrets.token_urlsafe(32)生成，不能用random模块
Content-Security-Policy 头不能只配 script-src
CSP 是最后一道防线，但很多人只加了 script-src 'self' 就以为万事大吉。其实攻击者早就不靠 <script> 标签了——onerror、javascript: 伪协议、内联样式里的 expression()（IE）、甚至 <img src=x onerror=...> 都能绕过简单配置。
实操建议：
- 至少覆盖
default-src 'self'、script-src 'self' 'unsafe-inline' 'unsafe-eval'（如果真要用内联脚本，就明确写出来，别留空）、style-src 'self' 'unsafe-inline'、img-src *、connect-src 'self' - 开发期先用
Content-Security-Policy-Report-Only头配合report-uri收集违规行为，再逐步收紧 - 避免在 CSP 中放
'unsafe-inline'或'unsafe-eval'，除非你清楚每个用到它们的地方，并已做好其他补偿措施
DOM型XSS最容易被Python后端开发者忽略
Python 后端管不到 DOM 操作，但很多漏洞源头恰恰来自后端返回的数据结构。比如接口返回 JSON：{"searchTerm": "<script>alert(1)</script>"}，前端用 document.write(data.searchTerm) 或 el.innerHTML = data.searchTerm 直接渲染，就触发 DOM 型 XSS。后端没法阻止前端乱写，但可以控制返回什么。
实操建议：
- 对所有 API 接口的字符串字段，预设过滤规则：移除
<script、on\w+=、javascript:等危险模式（用正则要谨慎，优先用成熟库如bleach） - 返回 JSON 前，对可能被前端当作 HTML 渲染的字段（如
title、content、description）统一做 HTML 编码，哪怕前端暂时不用，也留出安全余量 - 在 Swagger 或 OpenAPI 文档中标明哪些字段是“纯文本”，哪些是“允许 HTML”，并要求前端团队严格按约定使用
真正难防的不是那些显眼的 <script>，而是 location.hash、document.referrer、URLSearchParams 这些看似无害的浏览器 API 被前端拿来直插 DOM —— 后端能做的，是在数据出口处多一道清洗，别让危险字符串流出去。
