xss_clean（）是一个扩展，也是愚蠢的。这个函数90%的功能都没有阻止XSS。例如查找单词alert，但不查找document.cookie。没有黑客会在他们的攻击中使用alert，他们会用XSS劫持cookie或读取CSRF令牌来制造XHR。
但是，使用它运行htmlentities()或htmlspecialchars()是多余的。xss_clean()解决了问题，而htmlentities($text, ENT_COMPAT, 'UTF-8')失败的情况如下：

<?php
print "<img src='$var'>";
?>

一个简单的poc是：
您可以在本地主机上运行一个或多个应用程序。
这会将onload=事件处理程序添加到图像标记中。停止这种形式的XSS的方法是htmlspecialchars($var,ENT_QUOTES);，或者在本例中xss_clean()也会阻止这种情况。
但是，引用xss_clean（）文档中的话：
当然，没有什么是100%万无一失的，但我还没有能够让任何东西通过过滤器。
也就是说，XSS是output problem而不是input problem。例如，此函数无法考虑变量已经在<script>标记或事件处理程序中。它也不会停止基于DOM的XSS。您需要考虑 * 您如何使用数据 * 以便使用最佳函数。过滤输入的所有数据是不好的做法.它不仅不安全，而且会破坏数据，使比较变得困难。

CodeIgniter开发人员打算将xss_clean（）用于不同的用例，“一个允许'安全' HTML标记的评论系统或论坛”。这在文档中并不清楚，其中xss_clean显示为应用于用户名字段。
还有另一个永远不要使用xss_clean（）的原因，到目前为止还没有在StackOverflow上强调过。xss_clean（）在2011和2012期间被破坏了，而且不可能完全修复。至少没有完全重新设计，这并没有发生。目前，它仍然容易受到如下字符串的攻击：

<a href="j&#x26;#x41;vascript:alert%252831337%2529">Hello</a>

xss_clean（）的当前实现是通过有效地将urldecode（）和html_entity_decode（）应用于整个字符串开始的。这是必需的，这样它就可以对诸如“javascript：“之类的东西使用幼稚的检查。最后，* 它返回解码后的字符串 *。
攻击者只需对漏洞利用进行两次编码。xss_clean（）只解码一次，然后作为clean传递。这样，您就有了一个单次编码的漏洞利用，可以在浏览器中执行。
我称这些检查为“幼稚的”和不可修复的，因为它们在很大程度上依赖于正则表达式。xss_clean（）没有类似的功能。也许可以将HTML的一个子集列入白名单，这与正则表达式完全兼容。但是，目前的xss_clean（）在很大程度上是一个黑名单。

我建议使用http://htmlpurifier.org/来进行XSS净化。我正在扩展我的CodeIgniter Input类以开始利用它。

是的，你应该仍然在使用它，我通常把它作为一个规则，至少在面向公众的输入上使用它，这意味着任何人都可以访问和提交的任何输入。
通常，清理DB查询的输入看起来像是一个副作用，因为该函数的真正目的是防止Cross-site Scripting Attacks。
我不打算详细介绍xss_clean的每一步，但我会告诉你它比你提到的几步做得更多，我有pastied the source of the xss_clean function（死链接），所以你可以自己看，它是完全注解。

如果你想让filter在每次遇到POST或COOKIE数据时自动运行，你可以打开你的application/config/config.php文件并设置如下：如果是，则将其设置为TRUE。
您可以打开application/config/config.php文件并进行如下设置来启用csrf保护：如果您的配置文件中包含一个或多个参数，
有关更多详细信息，请参阅以下链接。
https://ellislab.com/codeigniter/user-guide/libraries/security.html