WAF误报CSV中HTML标签因在请求层扫描字段值，非csv.reader问题；应改Content-Type为application/octet-stream、预转义敏感字符或走API网关透传头绕过。
为什么 csv.reader 会触发 WAF 的 HTML 标签误报
waf（比如 cloudflare、阿里云 waf）在解析 http 请求体时，通常会对字段值做轻量级 html 特征扫描。当 csv 数据里含 <script>、<img src= 或带 </> 的标签片段，哪怕只是用户昵称字段里的 <3 或邮件内容里的 <user@example.com>，都可能被规则库当成 xss 特征拦截。
这不是 CSV 解析器的问题，而是 WAF 在请求层就截断了——你的 Python 代码根本没机会运行到 csv.reader 那一步。
- 真实场景：用户导出带富文本评论的报表，评论里有
<p>挺有用</p>，上传 CSV 时 403 - 关键点：WAF 拦截发生在反向代理/边缘节点，和后端语言无关，
Flask、Django、Node.js全都会中招 - 别试“先解码再传”：URL decode 或 base64 编码整个 CSV 字段反而更易触发
base64-encoded-html类规则
绕过 WAF 的三种实操路径（按推荐顺序）
禁用规则是下策，WAF 管理员通常拒绝开放高危规则白名单；优先选协议层规避。
-
换 Content-Type：把
multipart/form-data改成application/octet-stream，并手动指定filename="data.csv"。多数 WAF 对二进制类型不做 HTML 扫描 -
拆分敏感字段：对 CSV 中已知含 HTML 的列（如
comment），上传前用html.escape()转义，服务端接收后再html.unescape()。注意：只转义双引号、<、>、&四个字符，别动<3这类无害符号 -
走 API 网关透传头：如果 WAF 后面还有一层网关（如 Kong、APISIX），可在请求头加
X-Disable-WAF-Scan: true，由网关清洗后转发——前提是网关配置允许透传该 header
csv.writer 写入时如何避免生成触发规则的内容
不是所有 HTML 都危险，但 WAF 规则往往很粗。写 CSV 时主动规避典型特征，比事后处理更可靠。
- 禁用
quoting=csv.QUOTE_ALL：它会给所有字段加双引号，导致"<script>"这种结构更像恶意 payload - 改用
quoting=csv.QUOTE_MINIMAL，并确保escapechar='\'，让<script>变成<script>（不加引号）或<script>（需 escape） - 对字段值预处理：用正则
re.sub(r'<(/?)([a-zA-Z][^>]*)>', r'', s)替换所有尖括号为 HTML 实体，但保留原始语义
哪些“看起来安全”的操作反而会让问题更糟
有些直觉做法在 WAF 场景下适得其反，容易被忽略。
立即学习“前端免费学习笔记（深入）”；
- 用
json.dumps()包一层再 POST CSV 字符串：WAF 会看到{"data":"<div>..."}，反而强化了 HTML 上下文感知 - 把 CSV 放在
POST /upload的 query string 里：URL 长度受限，且 WAF 对 query 参数的 HTML 检查往往更激进 - 在前端 JS 里用
DOMPurify.sanitize()处理再上传：净化逻辑和 WAF 规则不一致，可能漏掉 WAF 认定的特征（比如注释<!-- test -->）
最稳的路是让数据在传输层“不像 HTML”——不依赖转义、不依赖编码、不依赖前端处理，从 Content-Type 和字段结构上剥离 HTML 语义。WAF 规则是死的，但它的触发条件可以绕开。
