Jinja2默认HTML转义是防XSS最有效的第一道防线，仅对{{...}}生效，覆盖<、>、"、'、&；失效场景包括误用|safe、Markup()、纯API中前端未防护及输入存储环节未过滤。
Flask 默认用 Jinja2 模板渲染变量时会自动 HTML 转义，这是防 XSS 的第一道、也是最有效的防线——但前提是别手动关掉它，也别乱用 |safe。
为什么 {{ user_input }} 通常是安全的
Jinja2 默认对所有变量输出做 HTML 转义：比如用户输入 <script>alert(1)</script>，渲染后变成文字 <script>alert(1)</script>，浏览器不会执行。这发生在模板渲染阶段，不依赖后端逻辑或中间件。
- 仅对 Jinja2 模板内
{{ ... }}生效；{% ... %}里的逻辑不受影响 - 转义规则覆盖
<、>、"、'、&，足够防御绝大多数反射型和存储型 XSS - 不处理 DOM 型 XSS（比如前端用
innerHTML拼接服务端返回的 JSON 字段），那得前端自己负责
什么时候会失效？小心 |safe 和 Markup
显式标记内容“安全”是唯一绕过自动转义的方式，但一旦误用，XSS 就直接开门放行。
-
{{ user_input | safe }}：模板里用了就等于放弃防护，必须确保user_input是你完全可控、已清洗过的 HTML（比如富文本编辑器导出的内容） -
from flask import Markup+Markup(html_string)：效果等同于|safe，常被误用于“我想显示换行符”，结果把用户评论里的<img src="https://img.php.cn/" alt="Flask怎么防止XSS攻击_Jinja2默认自动转义与Markup安全标记">也放过去了 - 常见错误：把数据库读出的原始评论字段直接
Markup()后传给模板，而没做任何过滤
纯 API 场景（如 Flask + Vue/React）要不要防？
如果你的 Flask 只返回 application/json，且前端严格用 textContent 或框架的自动转义机制（如 Vue 的 {{ }}、React 的 JSX 插值），那么 Flask 层本身基本不参与 XSS 防御——但 JSON 数据仍要规范编码。
- 确保所有字符串字段经标准 JSON 库序列化（
json.dumps()默认会转义<、>等，无需额外操作） - 禁止拼接 JSON 字符串（如
f'{"data": "{user_input}"}'），否则可能破坏结构并引入注入点 - 真正的风险在前端：比如用
v-html渲染未过滤的字段，或location.href = user_input构造跳转链接
输入验证和过滤不是可选项
自动转义只管“输出”，不管“存进去的是什么”。恶意脚本进了数据库，下次别人查出来再渲染，照样中招。
- 对富文本场景，用专用库如
bleach过滤标签：bleach.clean(user_html, tags=['p', 'br'], strip=True) - 对普通字段（用户名、标题等），用正则或白名单限制字符集：
re.match(r'^[a-zA-Z0-9_\u4e00-\u9fa5]+$', input) - 别信“前端校验就够了”，后端必须重复验证——因为请求可以绕过前端直接打到 Flask
最容易被忽略的一点：XSS 防御不是单点任务。它横跨输入、存储、输出三个环节，Jinja2 的自动转义只是最后一环。关掉它很容易，补上前面两环却常被跳过——尤其是当产品催着上线富文本功能的时候。
