在指南的開始，我們說過資料過濾在任何語言、任何平台上都是WEB應用安全的基石。這包含檢驗輸入到應用的數據以及從應用輸出的數據，而一個好的軟體設計可以幫助開發人員做到：
確保數據過濾無法被繞過，
確保不合法的信息不會影響合法的信息，並且
識別數據的來源。
關於如何確保資料過濾無法被繞過有各種各樣的觀點，而其中的兩種觀點比其他更通用並可提供更高級別的保障。
調度方法這種方法是用一個單一的PHP 腳本調度（透過URL）。其他任何操作在必要的時候使用include或require包含進來。這個方法一般需要每個URL 都傳遞一個單獨的GET變數來進行調度。這個GET變數可以被認為是用來取代腳本名稱的更簡化的設計。例如：
http://example.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 ://example.org/ ?task=print_form 。
你也可以使用ApacheForceType重定向或mod_rewrite來調整URL 位址：http: //example.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]+.) +[az]{2,}$/i';if (preg_match($email_pattern, $_POST['email'])){$clean['email'] = $_POST['email'];}?>下面的程式碼確保了$_POST[
'color']的內容是red，green，或blue: <?php$clean = array();switch ($_POST['color']){case 'red':case 'green ':case 'blue':$clean['color'] = $_POST['color'];break;}?>下面的程式碼確保$_POST['num']是一個整數（integer）：
<?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被開啟的情況下）。這就是為什麼初始化變數是非常好的習慣。