使用者在訂單頁選好商品、填入數量，畫面顯示總額100元，接著按下建立訂單。後端確認登入身分與操作權限，再處理請求。

但相同的API，也可能收到被改過的金額、畫面不允許的數量，甚至是另一個網站誘使瀏覽器送出的請求。它們不一定能從「是否已登入」分辨出來。

畫面限制不了請求內容

畫面上的金額只能顯示，數量欄位限制最少為1，商品清單只列出可售商品。這些設計方便正常操作，卻不能限制所有送到後端的內容。請求可以繞過畫面直接組合，唯讀與隱藏欄位也可能被修改。

建立訂單的請求因此只接收商品編號與數量。單價從後端取得，成交金額由後端計算，建立者取自登入身分，初始狀態由訂單流程設定。有人額外送來金額或「已核准」，依介面約定拒絕或忽略，不讓它們影響寫入。

請求模型與資料模型各自獨立，前者描述這次允許輸入的內容，後者保存完整訂單。若使用工具依欄位名稱複製物件的值，複製範圍也只包含允許輸入的欄位，其他內容由後端組成。

訂單明細保存當次採用的單價、折扣與金額，形成價格快照；商品主檔後續調價，不會連動改變既有訂單的成交資料。

允許輸入，也不代表可以直接採用

只接收商品與數量，仍有需要檢查的內容。數量可以被改成負數、零或超過允許上限；商品編號即使存在，也可能指向已停售的商品。

因此，後端除了檢查格式與範圍，也要依目前資料判斷商品是否仍可售。下拉選單曾經列出這項商品，並不能保證提交時仍符合條件。使用者開著舊頁面，也可能遇到相同情況，不一定是惡意操作。

數量的檢查要發生在計算與寫入之前。若先拿負數計算金額，或讓後續庫存處理使用它，錯誤就可能已經影響其他資料，最後才檢查便太晚了。

前端檢查能及早提示使用者，後端檢查則涵蓋繞過畫面與資料已變動的請求。兩邊有相似規則，並不代表其中一邊可以省略。理解欄位來源之外，也要知道它在什麼條件下才有效、何時開始產生影響。

帶著登入Cookie，不代表操作來自本站

再看另一種情況：使用者已登入訂單後台，接著開啟一個惡意網站。該網站可能誘使瀏覽器向訂單後台送出請求；如果Cookie設定與請求方式允許攜帶登入Cookie，而後端沒有相應防護，就可能接受使用者沒有打算執行的操作。

這是CSRF（跨站請求偽造）：借用已登入使用者的瀏覽器發出操作。它不需要先偷到密碼，也不同於假登入頁騙走帳密的釣魚攻擊。對後端來說，身分與權限可能都有效，商品與數量也完全合法，但這次操作並非使用者在本站發起。

登入與權限回答誰能操作；欄位來源、輸入條件與跨站防護，則決定這份請求是否能被接受。三者處理不同問題，不能用其中一項代替其他檢查。

「使用者把訂單金額改成 1 元送過來了。」
「結果呢？」
「後端重新計價，存進資料庫的還是一萬元。」
「那他說什麼？」
「他說我們網站有 Bug，結帳金額跟他送的不一樣！」