Hello, My API Validation

API 是最後防線，後端驗證不是加分項

曾經我在 PR 裡加入了 MAC Address 與 Serial Number 的格式驗證，卻被視為「應該交由前端處理」而被移除。但後端驗證從來不是錦上添花，而是守住系統邏輯與安全底線的責任。

在前後端分離的開發架構中，前端確實適合處理表單提示與使用者互動，但資料是否可信、格式是否正確，最終仍需由後端把關。這不只是風格問題，而是攸關資料正確性與系統安全的底線。

為什麼不能只靠前端驗證？

• 攻擊者可繞過前端，直接對 API 發送請求，不受前端約束。
• 前端驗證容易遺漏，稍有改版就可能忘記檢查邊界狀況。
• 資料庫的品質與安全性，只能靠後端確保。

不論你多信任使用者或自己的 UI，一旦 API 對外開放，所有輸入都應視為不可信，直到經過後端驗證為止。

常見卻易忽略的驗證需求

欄位類型	常見問題	建議處理方式
MAC Address	大小寫混用、缺冒號、格式不符	正規化格式、統一轉小寫
Serial Number	空白、特殊符號、長度不一	去除多餘空白、限制長度與字元集
Email	格式錯誤、大小寫比對錯誤	標準格式驗證、轉小寫比對
Phone Number	國碼遺漏、格式不統一	統一格式、清理非數字字元
自由輸入文字	可注入 <script> 等惡意內容	過濾 HTML 標籤與特殊字元
JSON 結構欄位	欄位未定義、型別錯誤	僅允許白名單欄位、進行深層驗證
可變長欄位	無長度限制、可被用來進行 DoS 攻擊	設定合理最大長度

後端若不進行上述驗證，可能會導致資料一致性問題、系統崩潰、甚至資安事件。

格式驗證是後端的基本責任

有些人認為「後端只要處理業務邏輯，格式交給前端就好」，但這種分工方式忽略了一個事實：API 是唯一直接接觸資料庫的接口，也是攻擊者的主要進入點。

後端若不主動驗證與保護，資料庫很快就會被寫滿錯誤、污染甚至惡意資料。屆時處理成本會比一開始做好驗證高上數倍。

結語：驗證不是「多做」，而是該做

後端驗證不是在跟前端搶工作，也不是完美主義者的堅持，而是為了讓系統穩定、安全、可維護。

請不要再說「這應該交給前端處理」了。格式驗證、大小寫正規化、欄位清洗，本來就是後端應做的基本工事。既然 API 是最後一道防線，就該由後端守住，而不是放行。