在指南的开始，我们说过数据过滤在任何语言、任何平台上都是WEB应用安全的基石。这包含检验输入到应用的数据以及从应用输出的数据，而一个好的软件设计可以帮助开发人员做到：
确保数据过滤无法被绕过，
确保不合法的信息不会影响合法的信息，并且
识别数据的来源。
关于如何确保数据过滤无法被绕过有各种各样的观点，而其中的两种观点比其他更加通用并可提供更高级别的保障。
调度方法
这种方法是用一个单一的 php 脚本调度（通过 URL）。其他任何操作在必要的时候使用include或require包含进来。这种方法一般需要每个 URL 都传递一个单独的GET变量用于调度。这个GET变量可以被认为是用来替代脚本名称的更加简化的设计。例如：
http://a.org/dispatch.php?task=PRint_formdispatch.php是唯一的根文件(Document root)。它可以让开发者做两件非常重要的事情：
在dispatch.php最开始实现一些全局的安全处理，并且确保这些处理不可以被绕过。
容易确定在必要的地方进行数据过滤，特别是一些特殊目的的控制流操作中。
看下面的例子以便进一步讨论dispatch.php脚本:
<?php/* 全局安全处理 */switch ($_GET['task']){case 'print_form':include '/inc/presentation/form.inc';break;case 'process_form':$form_valid = false;include '/inc/logic/process.inc';if ($form_valid){include '/inc/presentation/end.inc';}else{include '/inc/presentation/form.inc';}break;default:include '/inc/presentation/index.inc';break;}?>如果这是唯一的可公开访问到的 PHP 脚本，则可以确信的一点是这个程序的设计可以确保在最开始的全局安全处理无法被绕过。同时也让开发者容易看到特定任务的控制流程。例如，不需要浏览整个代码就可以容易的知道：当$form_valid为true时，end.inc是唯一显示给用户的；由于它在process.inc被包含之前，并刚刚初始化为false，可以确定的是process.inc的内部逻辑会将设置它为true；否则表单将再次显示（可能会显示相关的错误信息）。
注意
如果你使用目录定向文件，如index.php（代替dispatch.php），你可以像这样使用 URL 地址：http://a.org/?task=print_form。
你还可以使用 ApacheForceType重定向或者mod_rewrite来调整 URL 地址：http://a.org/app/print-form。
包含方法
另外一种方式是使用单独一个模块，这个模块负责所有的安全处理。这个模块被包含在所有公开的 PHP 脚本的最前端（或者非常靠前的部分）。参考下面的脚本security.inc
<?phpswitch ($_POST['form']){case 'login':$allowed = array();$allowed[] = 'form';$allowed[] = 'username';$allowed[] = 'passWord';$sent = array_keys($_POST);if ($allowed == $sent){include '/inc/logic/process.inc';}break;}?>
在本例中，每个提交过来的表单都认为应当含有form这个唯一验证值，并且security.inc独立处理表单中0需要过滤的数据。实现这个要求的 HTML 表单如下所示：
<form action="/receive.php" method="POST"><input type="hidden" name="form" value="login" /><p>Username:<input type="text" name="username" /></p><p>Password:<input type="password" name="password" /></p><input type="submit" /></form>
叫做$allowed的数组用来检验哪个表单变量是允许的， 这个列表在表单被处理前应当是一致的。流程控制决定要执行什么，而process.inc是真正过滤后的数据到达的地方。
注意
确保security.inc总是被包含在每个脚本的最开始的位置比较好的方法是使用auto_prepend_file设置。
过滤的例子
建立白名单对于数据过滤是非常重要的。由于不可能对每一种可能遇到的表单数据都给出例子，部分例子可以帮助你对此有一个大体的了解。
下面的代码对邮件地址进行了验证：
<?php$clean = array();$email_pattern = '/^[^@\s<&>]+@([-a-z0-9]+\.)+[a-z]{2,}$/i';if (preg_match($email_pattern, $_POST['email'])){$clean['email'] = $_POST['email'];}?>
下面的代码确保了$_POST['color']的内容是red，green，或者blue：
[/co<?php$clean = array();switch ($_POST['color']){case 'red':case 'green':case 'blue':$clean['color'] = $_POST['color'];break;}?>de]
下面的代码确保$_POST['num']是一个整数（integer）：
[code]
<?php$clean = array();if ($_POST['num'] == strval(intval($_POST['num']))){$clean['num'] = $_POST['num'];}?>
下面的代码确保$_POST['num']是一个浮点数（float）：
<?php$clean = array();if ($_POST['num'] == strval(floatval($_POST['num']))){$clean['num'] = $_POST['num'];}?>
名字转换
之前每个例子都使用了数组$clean。对于开发人员判断数据是否有潜在的威胁这是一个很好的习惯。 永远不要在对数据验证后还将其保存在$_POST或者$_GET中，作为开发人员对超级全局数组中保存的数据总是应当保持充分的怀疑。
需要补充的是，使用$clean可以帮助思考还有什么没有被过滤，这更类似一个白名单的作用。可以提升安全的等级。
如果仅仅将验证过的数据保存在$clean，在数据验证上仅存的风险是你所引用的数组元素不存在，而不是未过滤的危险数据。
时机
一旦 PHP 脚本开始执行，则意味着 HTTP 请求已经全部结束。此时，用户便没有机会向脚本发送数据。因此，没有数据可以被输入到脚本中（甚至register_globals被开启的情况下）。这就是为什么初始化变量是非常好的习惯。
