没有什么是不可能的。

但是，ORM和查询生成器已经降低了SQL注入漏洞，从而防止了最常见的错误。在我的经验中，在默认情况下使用安全(Ish)模板引擎的应用程序也有较少的XSS问题。

但主要问题是：

• 输入卫生设施永远无法解决所有问题，因为您无法对所有上下文的输入进行消毒。
• 在水槽里有适当的处理。您需要标记所有不安全的函数调用(例如本机query)，在准备好的查询中不能有任何变量，也不能设置任何异常(“输入不是用户控制的，所以很好”，“对于很少的情况下”，因为它会很快变得无法管理)。这将严重限制开发人员的可用性。
• XSS非常通用，并不是所有的情况都可以通过模板(例如DOM )来预防。

示例: SQL注入

让我们以PHP为例。您可以标记各种SQL函数(query等)的所有用途，并且只允许使用prepare。您还需要检查是否没有变量传递给prepare：

$stmt = $conn->prepare("SELECT test from table WHERE x=?");
$stmt->bind_param("s", $test);

但是，如果您希望表名是可变的呢？或者是您首先需要构建的复杂查询？例：

$filterquery = " WHERE ";
for ($filter in $filterarray) {
    $filterquery = ...
}

$stmt = $conn->prepare("SELECT test from $tablename" . $filterquery);
$stmt->bind_param("s", [...]);

这是您不能允许的，因为检查$filterquery是否安全是非常重要的。但是，在查询中不允许变量会严重限制开发人员。

您可以使用querybuilder并检查是否只有绑定函数接受参数(如理论中的setParameter )，但您需要再次防止将任何变量传递给其他函数(如where)。由于有合法的用例，这也会限制开发人员的可用性。

示例: XSS

使用XSS，这将变得更加困难。首先，您需要检查所有输出数据的函数，并防止这些函数(echo、print、die等)，这样输出只能通过模板引擎完成(这当然是可行的)。

但是您不能在模板之外动态地构建HTML代码，因为您不能将复杂的变量传递给它(无法知道数据是否是(部分)用户控制的)。

您现在可以对数据进行默认的HTML编码，以防止出现许多XSS情况。但是，如何知道您是否处于JavaScript上下文中呢？或者src属性上下文(您需要在其中防止javascript:链接)？这也是不容易检查的(或者您需要您的开发人员标记该变量是在哪个上下文中打印的，这很容易出错)。

然后是基于DOM的XSS。也许您希望允许某些用户发布一个有限的HTML子集(您可以对其进行筛选，但需要模板中的异常)。