使用AJAX调用wp_update_post提交大块HTML内容是否存在安全风险？

核心结论 #

提交大量未转义、未过滤的HTML内容一定会引发安全和功能层面的严重问题，具体风险如下：

• 存储型XSS攻击风险
  即便你当前限制了只有管理员、编辑角色可使用该功能，一旦账号被窃取、权限校验逻辑被绕过，攻击者可直接植入恶意JavaScript脚本、跳转代码、钓鱼弹窗等内容，所有访问该页面的用户都会受到影响，包括但不限于Cookie被盗取、个人信息泄露、被强制跳转至恶意站点。
• 页面渲染异常风险
  未校验的HTML可能存在标签不闭合、属性语法错误、与WordPress内置块规则/短代码逻辑冲突的问题，轻则导致页面样式错乱、部分功能失效，重则触发整站前端白屏。
• 恶意资源植入风险
  若提交的HTML中包含指向外部恶意资源的<script>、<link>、<iframe>标签，或是内嵌恶意样式、base64编码的恶意代码，会直接被写入站点数据库，后续触发时很难溯源排查。

修复建议 #

• 前端提交前置校验：过滤你业务不需要的危险标签（<script>、<iframe>、<form>等），以及onclick/onload/onerror等事件属性、javascript:开头的伪协议链接。
• 后端强制HTML过滤：使用WordPress原生的wp_kses()函数做内容校验，你可以自定义允许的标签和属性白名单，仅放行编辑器用到的HTML元素，其余内容全部剔除。示例过滤逻辑：

  // 自定义允许的HTML标签和属性白名单
  $allowed_tags = [
      'div' => ['class' => [], 'id' => []],
      'p' => ['class' => []],
      'span' => ['class' => [], 'style' => []],
      // 按需添加你用到的其他标签和属性
  ];
  $post_content = wp_kses($_POST['post_content'], $allowed_tags);
  

• 特殊字符转义：如果存在需要展示<、>、&等特殊字符的场景，用esc_html()转义后再存储，避免和HTML语法冲突。
• 修复现有PHP代码问题：你当前的add_action( 'wp_ajax_sced_page', 'sced_page' );写在sced_page函数内部且位于wp_die()之后，永远不会执行，需要移到函数外部。
• 补充Nonce校验：在AJAX请求中加入WordPress Nonce参数，后端接收后先校验Nonce合法性，防止CSRF攻击。

内容的提问来源于stack exchange，提问作者Artistica Digital