章 28. 錯誤報告
對於 PHP 的安全性來說錯誤報告是一把雙刃劍。一方面可以提高安全性，另一方面又有害。
攻擊系統時經常使用的手法就是輸入不正確的資料，然後檢視錯誤提示的類型及上下文。這樣做有利於攻擊者收集伺服器的訊息以便尋找弱點。比如說，若果一個攻擊者知道了一個頁面所基於的表單訊息，那麼他就會嘗試修改變量：
通常 PHP 所返回的錯誤提示都能說明開發者除錯程式，它會提出哪個檔案的哪些函數或代碼出錯，並指出錯誤發生的在檔案的第幾行，這些就是 PHP 本身所能給出的訊息。很多 PHP 開發者會使用 show_source()、highlight_string() 或是 highlight_file() 函數來除錯代碼，但是在正式運行的網站中，這種做法可能會暴露出隱藏的變量、未檢查的語法和其它的可能危及系統安全的訊息。在運行一些具有內定除錯處理的程式，或是使用通用除錯技術是很危險的。若果讓攻擊者確定了程式是使用了哪種具體的除錯技術，他們會嘗試傳送變量來開啟除錯功能：
不管錯誤處理機制如何，可以探測系統錯誤的能力會給攻擊者提供更多訊息。
比如說，PHP 的獨有的錯誤提示風格可以說明系統在運行 PHP。若果攻擊者在尋找一個 .html 為頁面，想知道其後台的技術（為了尋找系統弱點），他們就會把錯誤的資料送出上去，然後就有可以得知系統是基於 PHP 的了。
一個函數錯誤就可能暴露系統正在使用的資料庫，或是為攻擊者提供有關網頁、程式或設計方面的有用訊息。攻擊者往往會順籐摸瓜地找到開放的資料庫埠，以及頁面上某些 bug 或弱點等。比如說，攻擊者可以一些不標準的資料使程式出錯，來探測腳本中認證的順序（通過錯誤提示的行號數字）以及腳本中其它位置可能洩露的訊息。
一個檔案系統或是 PHP 的錯誤就會暴露 web 伺服器具有什麼權限，以及檔案在伺服器上的組織結構。開發者自己寫的錯誤代碼會加劇此問題，導致洩漏了原本隱藏的訊息。
有三個常用的辦法處理這些問題。第一個是徹底地檢查所有函數，並嘗試彌補大多數錯誤。第二個是對線上系統徹底關閉錯誤報告。第三個是使用 PHP 自訂的錯誤處理函數建立自己的錯誤處理機制。根據不同的安全策略，三種方法可能都適用。
一個能提前阻止這個問題發生的方法就是利用 error_reporting() 來說明使代碼更安全並發現變量使用的危險之處。在發佈程式之前，先開啟 E_ALL 測試代碼，可以幫你很快找到變量使用不當的地方。一旦準備正式發佈，就應該把 error_reporting() 的參數設為 0 來徹底關閉錯誤報告或是把 php.ini 中的 display_errors 設為 off 來關閉所有的錯誤顯示以將代碼隔絕於探測。當然，若果要遲一些再這樣做，就不要忘記開啟 ini 檔案內的 log_errors 選項，並通過 error_log 指定用於記錄錯誤訊息的檔案。