CodeIgniter3怎么使用esc函数过滤视图输出内容防止xss攻击-php教程-PHP中文网

esc()是codeigniter 4引入的视图转义函数，ci3中不存在，应使用html_escape()替代，且需先加载html辅助函数；富文本须用htmlpurifier白名单过滤，不可依赖xss_clean()。

codeigniter3怎么使用esc函数过滤视图输出内容防止xss攻击

直接说结论：esc() 是 CodeIgniter 4 引入的视图专用输出转义函数，CI3 中根本不存在。如果你在 CI3 项目里写了 = esc($user_input) ?>，会触发 Fatal error: Call to undefined function esc()。

CI3 的等效函数是 html_escape()（全局辅助函数），它默认做 HTML 上下文转义，行为接近 esc($str, 'html')。

常见错误现象：复制 CI4 教程代码到 CI3 项目，页面白屏或报错；用 htmlspecialchars() 手动包裹但漏掉编码参数，导致中文乱码或单引号未转义。

必须先加载 url 或 html 辅助函数（任一即可），html_escape() 才可用：$this->load->helper('html');
html_escape() 不支持上下文参数（如 'js' 或 'url'），只做基础 HTML 实体转义
若需 JS 字符串输出，得手动用 addslashes() + 单引号包裹，或改用 json_encode($str, JSON_HEX_TAG | JSON_HEX_AMP)

所有来自数据库、表单提交、URL 参数、Cookie 等不可信来源的数据，在视图中输出前都必须经过转义 —— 不能依赖输入时的 xss_clean()，那是另一层且已过时的防护。

示例场景：显示用户昵称、评论内容、搜索关键词高亮片段。

HTML 内容（段落、标题）：<p><?php echo html_escape($comment); ?></p><div class="aritcle_card flexRow artxards"> <div class="artcardd flexRow"> <a class="aritcle_card_img" rel="nofollow" href="/xiazai/gongju/2515" title="CodeIgniter 4.7.0"><img src="https://img.php.cn/upload/manual/001/503/042/6a6b043218cde750.png" alt="CodeIgniter 4.7.0" onerror="this.onerror='';this.src='/static/lhimages/moren/morentu.png'" ></a> <div class="aritcle_card_info flexColumn"> <a rel="nofollow" href="/xiazai/gongju/2515" title="CodeIgniter 4.7.0" class="overflowclass">CodeIgniter 4.7.0</a> <p class="overflowclass">CodeIgniter下载页提供 CodeIgniter 4.7.0 官方源码包，并整理框架安装、数据库配置与入门开发说明。</p> </div> <a rel="nofollow" href="/xiazai/gongju/2515" title="CodeIgniter 4.7.0" class="aritcle_card_btn flexRow flexcenter"><b></b><span>下载</span> </a> </div> </div>
HTML 属性值（title、alt）：<img src="avatar.jpg" alt="<?php echo html_escape($user_name); ?>">
JavaScript 字符串（慎用！优先用 data-* 属性传值）：<script>var name = <?php echo json_encode($user_name, JSON_HEX_TAG | JSON_HEX_AMP); ?>;</script>
URL 参数拼接（如跳转链接）：@#@#@#@#@#@#@#@#@#@0（注意：这里用 rawurlencode()，不是 html_escape()）

xss_clean() 在 CI3 中是输入阶段的启发式清洗，它不解析 HTML、易被大小写/空格/注释绕过，且对 SVG、CSS expression、data: URL 等现代 XSS 变体基本无效。2026 年的攻击手法早已绕过它。

更关键的是：它只应在「输入即存储、且后续纯文本展示」的极低风险场景下作为辅助手段，比如后台系统通知标题字段。一旦数据要渲染进 HTML、JS 或 CSS 上下文，xss_clean() 就完全失能。

常见错误：在控制器里调用 $this->security->xss_clean($input) 后，视图中直接 = $cleaned_input ?> —— 这等于把转义责任推给输入层，违反“输出时按上下文转义”原则
性能影响：每次调用 xss_clean() 都触发正则扫描，对长文本开销明显，尤其在循环中使用
兼容性陷阱：CI4 已彻底移除该函数，升级时若大量依赖它，重构成本极高

如果业务真需要保留部分 HTML（如用户发帖带加粗、列表），html_escape() 会把所有标签变成纯文本，显然不行。这时必须引入白名单过滤，而非清洗或简单转义。

推荐组合：HTMLPurifier（稳定、标准、可配） + 输出前调用 + 严格限制标签与属性。

不要用 CI3 自带的 strip_tags() 白名单模拟，它不解析 DOM，无法防御 <div onclick="alert(1)"> 类攻击<li>避免在视图中动态初始化 <code>HTMLPurifier 实例，应提前在控制器或模型中净化并缓存结果
配置示例关键项：$config->set('HTML.Allowed', 'p,b,i,br,ul,ol,li,a[href|title]'); —— 明确放行哪些标签及允许的属性
净化后仍需用 html_escape() 包裹？不需要。HTMLPurifier 输出已是安全 HTML，直接 = $sanitized_html ?> 即可

真正容易被忽略的点：富文本字段的数据库存储长度是否足够？TEXT 类型可能不够，而 MEDIUMTEXT 又可能被滥用为存储恶意 payload 容器 —— 净化必须在入库前完成，不能只做输出时兜底。