xss防护核心是上下文感知编码:html、js、url等不同上下文需用对应编码方式,csrf需token绑定会话且严格校验,csp须全面配置并禁用unsafe选项,dom型xss需后端对api返回字段预清洗。

直接输出用户输入前必须做上下文感知编码
不加处理地把 user_input 插进 HTML、JS 或 URL,等于主动给 XSS 开门。关键不是“要不要转义”,而是“在哪种上下文中用哪种编码”。比如:user_input 被塞进 <div>{{ user_input }}</div>,用 HTML 实体编码(<、>)就够了;但若写进 <script>var data = "{{ user_input }}";</script>,光 HTML 编码没用,得用 JS 字符串编码,否则引号闭合后仍可注入。
常见错误现象:
- 用
html.escape()处理所有场景,结果在 JS 上下文中被绕过 - 前端用
innerHTML渲染服务端返回的富文本,却没走白名单过滤 - URL 参数拼进
<a href="xxx"></a>时,忘了对&、=做 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 关联、每次敏感请求都校验、校验失败立即拒绝且不泄露原因。
常见错误现象:
- 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></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>、<code>on\w+=</script>、javascript:等危险模式(用正则要谨慎,优先用成熟库如bleach) - 返回 JSON 前,对可能被前端当作 HTML 渲染的字段(如
title、content、description)统一做 HTML 编码,哪怕前端暂时不用,也留出安全余量 - 在 Swagger 或 OpenAPI 文档中标明哪些字段是“纯文本”,哪些是“允许 HTML”,并要求前端团队严格按约定使用
真正难防的不是那些显眼的 <script></script>,而是 location.hash、document.referrer、URLSearchParams 这些看似无害的浏览器 API 被前端拿来直插 DOM —— 后端能做的,是在数据出口处多一道清洗,别让危险字符串流出去。
Python免费学习笔记(深入):立即使用
在学习笔记中,你将探索 Python 的核心概念和高级技巧!











