說起防止SQL注入，這大概是每個PHP開發者都繞不開的課題。尤其像打卡系統這類需要頻繁與資料庫互動的項目，一旦出現漏洞，後果不堪設想。我特別欣賞那個打卡項目裡提到的「使用prepare + bind_param」的做法，這絕對是業界公認的防禦基石。但老實說，很多人只是照著範例寫，根本沒搞懂為什麼這樣做能防住注入。今天就來聊聊，如何在PHP項目開發中真正把這道防線築牢。
參數化查詢不只是「綁定變數」這麼簡單
很多人看到bind_param就以為萬事大吉，其實關鍵在於預處理（prepare）這個動作。當你把SQL語句模板提前傳送給資料庫伺服器時，伺服器會先編譯這個語法結構，這時候無論後面綁定的參數是什麼妖魔鬼怪，都只會被當成純文字，不會被解釋成SQL指令。這就是為什麼$stmt = $conn->prepare("SELECT * FROM users WHERE id = ?")比直接拼接字串"SELECT * FROM users WHERE id = $id"安全千百倍。那個打卡系統的checkin.php寫法就很標準——先prepare，再bind_param，最後execute，完全沒有給注入留餘地。
輸入驗證是第二道鎖，但別過度依賴
有些開發者喜歡在接收參數後先用addslashes()或mysqli_real_escape_string()轉義，再拼接SQL。這種做法其實是上一代的思維，雖然能擋住大部分攻擊，但遇到寬字元編碼或特殊場景還是有破綻。比如GBK編碼下的「寬字元注入」，轉義函數就常出問題。真正可靠的做法是：永遠把參數化查詢當成第一選擇，輸入驗證只是輔助——檢查是否為整數、長度是否合理、格式是否正確。就像打卡系統的用戶ID，完全可以先用filter_var($id, FILTER_VALIDATE_INT)過濾，再丟進預處理語句。
實戰中容易忽略的陷阱
我見過太多專案只在查詢語句用參數化，卻在ORDER BY、LIMIT、動態表名這類地方直接拼接。這些欄位無法用預處理綁定，因為它們屬於語法結構的一部分。這時該怎麼辦？最簡單的方法是白名單驗證：把你的排序欄位限制在允許的幾個值裡（比如只允許'date'或'username'），再用三元運算子或switch來決定。還有一個常見疏漏是批量操作，例如打卡系統要插入多條記錄，有些人會用迴圈拼接多個VALUES，這就危險了。正確做法是一次prepare，然後在迴圈裡重複bind_param和execute，性能和安全都能兼顧。
從框架層面思考，但別迷信框架
現代PHP框架如Laravel、Symfony都內建了ORM，用Eloquent或Doctrine時，查詢生成器預設就會使用參數化綁定。但問題是，很多人遇到複雜查詢就會跳過ORM，直接寫原生SQL——這時又回到手動拼接的老路上。我自己的經驗是，即使是框架，也應該在每個可能執行原生SQL的地方，養成使用佔位符的習慣。那個打卡專案是純PHP開發，沒有框架依賴，但作者仍然用了prepare + bind_param，這種意識比那些抱著框架就以為安全的開發者強多了。
不只是SQL注入，還有更深的教訓
說到底，防止SQL注入本質上是信任邊界的問題。你的PHP程式永遠不該信任來自用戶端（包括表單、URL參數、HTTP頭部、Cookie）的任何資料。那個打卡系統的Session管理、密碼哈希加密也做得不錯，說明作者對安全有整體觀。如果你開發的是API接口，記得在返回錯誤訊息時不要洩漏資料庫細節（比如直接輸出「Duplicate entry for key」），否則攻擊者能從錯誤推斷出表結構。還有，資料庫帳號的權限也要收緊——查詢只用SELECT權限的帳號，不要什麼都給root。這些細節加起來，才能讓你的PHP專案在面對SQL注入攻擊時，像那個打卡系統一樣穩如磐石。
評論（15）
参数化查询基本操作，还是有人踩坑
白名单驗證那個方法實用
prepare加上bind_param真的是標配，新手一定要養成這個習慣，別偷懶
還有預存程序也可以用參數化
框架的ORM默認安全，但還是要小心raw query
PDO的占位符跟mysqli有差嗎？
批量插入用循环重复bind_param，会不会影响数据库连接效率啊？一直開關prepared statement？
filter_var那步其實沒必要，prepare就夠了
之前維護老系統全拼接，改到懷疑人生
之前自己项目也遇到寬字符注入，後來全部改用UTF8就沒事了
又是标题党，内容就那样
看不明白，但感覺很專業
路過，看看熱鬧
說到底就是信任邊界的問題，用戶端資料一律不可信。之前寫API時沒注意錯誤訊息，直接洩漏了表結構，被主管罵死
那API錯誤訊息要怎麼避免洩漏結構？