在前面的實作中，我們看到了自動化腳本是如何暴力破解密碼或是撞庫。為了阻止這類攻擊，現代網站幾乎都會加入 CAPTCHA（圖形/行為驗證碼）機制。但有了驗證碼就真的安全了嗎？

• 什麼是 CAPTCHA？

CAPTCHA的全名是Completely Automated Public Turing test to tell Computers and Humans Apart（全自動區分電腦與人類的圖靈測試）。它的核心目的只有一個：確保發送 HTTP 請求的是「真實人類」而非「自動化程式腳本」。

• CAPTCHA 的世代演進

第一代：扭曲文字/數字圖形
使用扭曲、加雜訊線條的圖片，要求使用者輸入文字（如早期常見的 4 位數驗證碼）。
缺點：辨識體驗差，且現代 OCR（光學字元辨識）與 AI 很容易破譯。

第二代：圖像點選（reCAPTCHA v2）
例如「請選出所有含有紅綠燈的圖片」或勾選「我不是機器人」。
利用行為軌跡（滑鼠移動路徑、點擊時間）判斷是否為人類。

第三代：無感驗證（reCAPTCHA v3 / Cloudflare Turnstile）
使用者完全不需要手動點擊，系統根據使用者的瀏覽行為直接給出 0.0 ~ 1.0 的安全評分（Score），由後端決定是否放行。

• 常見的「不安全驗證碼（Insecure CAPTCHA）」設計陷阱

1. 前端驗證陷阱（Client-side Validation）
   錯誤作法：驗證碼的正確答案直接藏在前端 JavaScript 或 HTML 原始碼中，或者用前端 JS 判斷「驗證碼正確」才發送請求。
   攻擊手法：攻擊者直接檢視網頁原始碼抓出答案，或繞過前端 JS 直接發送 POST 請求給後端 API。

2. 驗證碼可重複使用（Reusable CAPTCHA）
   錯誤作法：驗證碼驗證通過後，伺服器沒有立刻將該驗證碼註銷（Invalidate）。
   攻擊手法：攻擊者先手動輸入一次正確驗證碼，取得 Session 後，用同一個驗證碼發送數萬次自動化爆破請求。

3. 跳過步驟漏洞（Step Bypass）
   錯誤作法：多步驟表單（如：Step 1 輸入帳密 + 驗證碼 ➔ Step 2 完成登入），後端 Step 2 只有簡單檢查 if(step == 2)，卻沒有檢查「Step 1 是否真的驗證成功」。
   攻擊手法：攻擊者直接發送 Step 2 的請求，完全跳過 Step 1 的驗證碼頁面。

4. 明文回應漏洞（API Logic Flaw）
   錯誤作法：伺服器生成驗證碼時，將正確答案以明文（例如 {"captcha_answer": "8k2p"}）隨 JSON 回應傳給前端瀏覽器。