Laravel 12 零信任架構實戰：超越 FormRequest 的「情境式驗證」與動態 Middleware 防禦術

FormRequest 全部驗證通過，不代表這個請求就值得信任——這是我看過大量 AI 生成程式碼之後最深的體悟。現在的 AI 很會寫 Code，但它們對「資安」的理解，往往還停留在「有檢查就好」的階段，完全沒有情境的概念。這篇就用 Laravel 12 的情境式驗證與動態 Middleware，把零信任架構真正落到程式碼層。

在我們討論 Laravel 驗證與 Middleware 客製化 時，很多工程師（尤其是剛轉職的 junior）會覺得：「啊不就是 php artisan make:request 然後填幾個 required|string 就搞定了嗎？」

大錯特錯。在 2026 年，駭客早就不用簡單的 SQL Injection 或 XSS 來攻擊你了，他們用的是邏輯漏洞（Business Logic Vulnerabilities）和 AI Prompt Injection。如果你的驗證邏輯還停留在「格式檢查」，那你的 API 基本上跟裸奔沒兩樣。今天這篇文章，我不談基礎教學，我們要來聊聊 Laravel 12 環境下，如何打造「零信任（Zero Trust）」的情境式驗證與動態 Middleware。

為什麼標準的 FormRequest 還不夠？

標準的 Laravel FormRequest 很好用，但它有一個致命缺點：它通常是靜態的。你定義了規則，它就照跑。但在複雜的 SaaS 系統或企業級應用中，驗證規則往往取決於「當下的情境」。

• 使用者身份： 管理員和普通用戶呼叫同一個 API 更新資料，允許的欄位應該不同。
• 資料狀態： 一張訂單如果是「待處理」，可以改地址；如果是「配送中」，連備註都不能改。
• 來源環境： 來自內部微服務的請求可能需要寬鬆驗證，但來自公開 Internet 的請求必須嚴格清洗。

如果你在 Controller 裡面寫一堆 if ($user->isAdmin()) 來手動驗證，那程式碼馬上就會變成義大利麵。我們需要在 Request 層就解決這件事。

實戰：情境感知驗證 (Context-Aware Validation)

我們可以利用 prepareForValidation 和動態規則注入來解決這個問題。以下是一個針對訂單更新的進階範例：

<?php

namespace App\Http\Requests;

use Illuminate\Foundation\Http\FormRequest;
use Illuminate\Validation\Rule;
use App\Enums\OrderStatus;

class UpdateOrderRequest extends FormRequest
{
    public function authorize(): bool
    {
        // 這裡不僅僅是回傳 true，還要檢查使用者對該資源的權限
        return $this->user()->can('update', $this->route('order'));
    }

    protected function prepareForValidation()
    {
        // 在驗證前進行資料清洗，例如強制轉型或移除危險字元
        $this->merge([
            'note' => strip_tags($this->input('note')),
        ]);
    }

    public function rules(): array
    {
        $order = $this->route('order');
        $user = $this->user();

        $rules = [
            'note' => ['nullable', 'string', 'max:500'],
        ];

        // 情境 1: 只有管理員可以修改折扣
        if ($user->is_admin) {
            $rules['discount'] = ['nullable', 'numeric', 'min:0', 'max:100'];
        }

        // 情境 2: 根據訂單狀態決定是否允許修改地址
        if ($order->status === OrderStatus::PENDING) {
            $rules['shipping_address'] = ['required', 'string', 'max:255'];
        } else {
            // 如果訂單鎖定，禁止該欄位出現在請求中（防範 Mass Assignment）
            $rules['shipping_address'] = ['prohibited'];
        }

        return $rules;
    }

    public function messages()
    {
        return [
            'shipping_address.prohibited' => '訂單已出貨，無法修改配送地址，請聯繫客服。',
        ];
    }
}

看到差異了嗎？我們不是死板地檢查欄位，而是根據 $order 目前的狀態來動態決定 shipping_address 是 required 還是 prohibited。這就是情境式驗證的精髓。

Middleware 客製化：動態防禦的藝術

除了驗證資料本身，Laravel 驗證與 Middleware 客製化的另一個重點是「請求的過濾管道」。很多工程師習慣把所有 Middleware 塞到 bootstrap/app.php (Laravel 11+) 或 Kernel.php (舊版) 的全域堆疊裡。這樣做的後果是：連一個簡單的健康檢查 API 都要跑過幾十層的 Session 檢查和 CSRF 驗證，效能直接被拖垮。

在 2025、2026 年的架構中，我們更傾向於「微術式」的 Middleware 應用。例如，針對 AI Agent 請求的特殊限流（Rate Limiting）與內容審查。

實戰：針對 AI 爬蟲的動態 Middleware

假設你的網站不希望被別人的 AI 模型隨意抓取資料，或者你想針對 API 的異常流量做更細緻的封鎖，我們可以寫一個 Middleware 來動態分析請求特徵。

<?php

namespace App\Http\Middleware;

use Closure;
use Illuminate\Http\Request;
use Symfony\Component\HttpFoundation\Response;
use App\Services\ThreatIntelligence;

class AiBotDefense
{
    public function __construct(protected ThreatIntelligence $threatIntel) {}

    public function handle(Request $request, Closure $next): Response
    {
        // 1. 檢查 User-Agent 是否包含已知的 AI Bot 特徵
        if ($this->isAiBot($request->userAgent())) {
            // 2. 如果是 AI，檢查是否有付費 API Key
            if (! $request->user()?>subscribed('ai-access')) {
                // 3. 沒付費就餵給它假資料或 403
                return response()->json([
                    'error' => 'AI Access Denied. Please upgrade your plan.',
                ], 403);
            }
        }

        // 4. 進階：檢查 Payload 是否包含 Prompt Injection 攻擊字串
        if ($this->threatIntel->containsInjectionPatterns($request->all())) {
             abort(400, 'Malicious payload detected.');
        }

        return $next($request);
    }

    private function isAiBot(?string $userAgent): bool
    {
        $bots = ['GPTBot', 'ClaudeBot', 'CCBot'];
        return str($userAgent)->contains($bots);
    }
}

這個 Middleware 展示了如何將業務邏輯（是否訂閱）與基礎設施邏輯（Bot 偵測）結合。這不僅僅是資安防護，更是商業模式的一部分。

進階技巧：Validation 與 Middleware 的協奏曲

最完美的架構，是讓 Middleware 負責「能不能進來」，讓 Validation 負責「帶了什麼進來」。但我發現很多專案這兩者界線模糊。例如，有人會在 Middleware 裡檢查 `email` 格式，這就是職責錯亂。

在 Laravel 12 中，我建議採用以下原則：

• Middleware： 處理身份驗證 (Auth)、授權 (Policy)、限流 (Throttling)、跨域 (CORS)、日誌 (Logging)。它的決策通常是 binary 的（通過/不通過）。
• FormRequest： 處理資料完整性、商業邏輯限制（如上述的訂單狀態檢查）、資料轉型。它的回饋是詳細的錯誤訊息。

針對 API 的「指數退讓」限流

當 Middleware 偵測到惡意請求或驗證失敗次數過多時，我們不應該只是回傳 422，而應該動態調整該 IP 的 Rate Limit。這需要 Middleware 與 Cache 的深度整合。

// 在 Middleware 中動態調整限流
if ($validationFailedCount > 5) {
    RateLimiter::hit('block:'.$ip, 3600); // 直接鎖一小時
}

這種「連動式防禦」才是資深工程師該有的思維。不要讓你的各個防禦層像孤島一樣各自為政。

結論：程式碼是死的，邏輯是活的

寫了這麼多年 Laravel，我深刻體會到，所謂的「資深」不是你會背多少函式庫，而是你能不能預判系統在極端狀況下的行為。Laravel 驗證與 Middleware 客製化 絕對不是照著官方文件抄一遍就好，你需要思考的是「信任邊界」在哪裡。

如果你還在用全域 Middleware 擋掉所有請求，或者在 Controller 裡寫滿了 `if-else` 做驗證，拜託，趁現在重構一下吧。你的 Server 會感謝你的。

延伸閱讀

想更深入了解 Laravel 的防禦體系與架構設計，建議閱讀以下幾篇我精心整理的文章：

• 你的 API 像公共廁所隨便進？Laravel 11 驗證 (Validation) 與 Middleware 客製化終極實戰
• Laravel 11 防線告急？從 Form Request 到 Middleware 的進階防禦工事，拒絕髒資料與越權存取
• Laravel 門神不好當？從自訂驗證到 Middleware，打造滴水不漏的 API 防線