探索 Laravel 中的运行时请求检查（Guards、Contexts 与 Tradeoffs）

Source: Dev.to

介绍

我一直在尝试一个 Laravel 包，该包在 运行时 检查请求，即在请求已经进入框架之后（而不是仅在控制器被调用之前）。

这个想法最初是一个问题，而不是一个解决方案：

框架内部的运行时上下文能否提供比静态请求检查更好的安全信号？

为此，我原型化了一个包，在请求已经进入 Laravel 后构建 RuntimeContext，并对其运行一系列 Guards 管道。

RuntimeContext

• 规范化的请求数据（头部、主体、路由信息）
• 执行元数据
• 可选的历史信号

Guards

• 小而专注的检查器
• 基于优先级的执行
• 可以短路或聚合结果
• 返回结构化的 GuardResult 对象

Guard 特性

• 可配置，并可在运行时启用/禁用
• 每个 guard 都有定义好的成本 / 优先级

Profiles

• 按路由或使用场景分组 guard
• API 与后台路由的行为不同
• 不同的强制执行模式

响应模式

示例 Guard 类型（非 exhaustive）

• SQL 注入（基于模式 + 启发式）
• XSS 指标
• SSRF 尝试（内部 IP、元数据端点）
• 大规模赋值滥用
• PHP 反序列化向量
• NoSQL 操作符注入
• GraphQL 深度 / 复杂度滥用
• Bot 与异常行为（实验性）

性能考量

• 去重缓存 用于重复负载
• 抽样 – 检查一定比例的请求，始终检查可疑请求
• 分层检查 – 快速扫描 → 深度扫描
• Guard 级别和管道时间预算

这些实验旨在在信号质量与开销之间取得平衡，尽管该方法在真实生产流量中仍未得到验证。

限制

• 不是验证的替代品
• 不是 WAF
• 不声称“阻止所有攻击”
• 尚未生产就绪

该项目主要是围绕 guard 组合、运行时上下文建模以及信号质量与开销之间权衡的设计实验。

征求反馈

我希望得到以下方面的意见：

• 架构选择
• Guard 接口设计
• 基本缺陷（如果有）
• 已有的更好解决方案的项目

如果你在以下方面有经验：

• Laravel 内部机制
• PHP 安全工具
• 请求生命周期
• 运行时分析系统

…请分享你的想法，无论是正面的还是负面的。

链接

• GitHub（源码 & issue）：
• Packagist: