PHPWAF拦截AJAX请求典型表现为fetch或XHR触发403，响应含“WAF Blocked”或为空；主因是WAF对application/json的严格校验误判合法字段为XSS，建议前端避免敏感字符串、服务端预处理、加X-Requested-With头或调整WAF规则白名单。
PHPWAF 拦截 AJAX 请求的典型表现
页面正常访问，但 fetch 或 XMLHttpRequest 发起的请求被 403 拒绝，响应里可能带 WAF Blocked、Request Denied 或空内容；浏览器开发者工具 Network 面板中该请求状态码为 403，且 Response 标签页为空或只有简单提示。这不是 PHP 代码报错，而是 WAF（如 mod_security、Safedog、云 WAF 或某些国产 PHP 插件式 WAF）在 Web 服务器层提前拦截了。
Content-Type: application/json 触发规则最常见
很多 PHPWAF 默认对 Content-Type: application/json 的请求做严格校验，尤其当 JSON 数据含 、>、script、onerror、eval( 等字符串时，哪怕只是合法业务字段（如用户昵称填了 "张三"），也会被误判为 XSS 攻击。
实操建议：
-
前端发送 JSON 时避免在字段值中混入 HTML 标签或 JS 关键字；必要时先
encodeURIComponent或服务端用htmlspecialchars($input, ENT_NOQUOTES, 'UTF-8')预处理 - 临时调试可改用
application/x-www-form-urlencoded提交（例如fetch中用new URLSearchParams({a:1,b:2})），绕过 JSON 规则检测 - 检查 WAF 后台是否启用了「JSON 深度解析」或「AJAX 特征识别」类规则，这类规则往往独立开关
如何让 PHPWAF 放行特定 AJAX 接口
不推荐全局关闭 WAF，应精准放行。路径和请求头是关键识别依据：
立即学习“PHP免费学习笔记（深入）”；
- 若 WAF 支持规则白名单（如 mod_security 的
SecRuleRemoveById或 Safedog 的「例外 URL」），添加类似/api/v1/submit这样的精确路径（注意末尾斜杠匹配逻辑） - 给 AJAX 请求加自定义 Header，如
X-Requested-With: XMLHttpRequest（jQuery 默认带，原生fetch需手动设），再在 WAF 规则中允许带该 Header 的 POST 请求 - 部分 PHPWAF 读取
$_SERVER['HTTP_X_REQUESTED_WITH']做判断，确保 PHP 层没被 Nginx/Apache 清除该变量（检查配置中是否有underscores_in_headers off或fastcgi_pass_request_headers on）
后端绕过 WAF 的临时应急写法（慎用）
仅限开发环境或紧急回滚，不可长期依赖：
- 把敏感参数从 POST Body 挪到 URL Query（如
/api/save?data=xxx），避开 Body 检测——但注意 GET 长度限制和日志泄露风险 - 用 base64 编码整个 JSON 字符串再 POST，WAF 规则通常不自动解码，服务端用
json_decode(base64_decode($_POST['payload']))解析 - 如果 WAF 是基于 PHP 扩展（如某些国产“PHP 安全防护”插件），检查其配置文件中是否有
ajax_whitelist或skip_path项，填入接口路由
真正稳定的解法永远是调整 WAF 规则本身，而不是让业务代码去迁就拦截逻辑；多数误报源于规则过于宽泛，比如用正则匹配 select\s+from 却没限定上下文，导致 "user_select" 这种字段也被拦。
