Exploring runtime request inspection in Laravel
I’ve been experimenting with a Laravel package that inspects requests during runtime, not just before the controller is hit.
This started as a question rather than a solution:
Can runtime context inside the framework give better security signals than static request inspection?
So I decided to prototype it.
Core idea
Instead of relying only on:
- validation rules
- middleware checks
- edge security (WAF, CDN rules)
The package builds a RuntimeContext once the request is already inside Laravel and runs a pipeline of Guards against it.
Each guard inspects a different aspect of the request or behavior.
Architecture (high level)
RuntimeContext
- Normalized request data
- Headers, body, …
Exploring runtime request inspection in Laravel
I’ve been experimenting with a Laravel package that inspects requests during runtime, not just before the controller is hit.
This started as a question rather than a solution:
Can runtime context inside the framework give better security signals than static request inspection?
So I decided to prototype it.
Core idea
Instead of relying only on:
- validation rules
- middleware checks
- edge security (WAF, CDN rules)
The package builds a RuntimeContext once the request is already inside Laravel and runs a pipeline of Guards against it.
Each guard inspects a different aspect of the request or behavior.
Architecture (high level)
RuntimeContext
- Normalized request data
- Headers, body, route info
- Execution metadata
- Optional historical signals
Guards
- Small, focused inspectors
- Priority-based execution
- Can short-circuit or aggregate results
- Return structured GuardResult objects
Profiles
- Group guards per route or use-case
- Different behavior for APIs vs admin routes
- Different enforcement modes
Response modes
- log only
- silent
- block
- dry-run (full inspection, no enforcement)
Guards implemented so far
Examples (not claiming completeness):
- SQL injection (pattern-based + heuristics)
- XSS indicators
- SSRF attempts (internal IPs, metadata endpoints)
- Mass assignment abuse
- PHP deserialization vectors
- NoSQL operator injection
- GraphQL depth / complexity abuse
- Bot & anomaly behavior (experimental)
Each guard:
- is configurable
- can be enabled/disabled at runtime
- has a defined cost / priority
Performance considerations
This was a big concern, so I added some experiments:
- Deduplication cache for repeated payloads
- Sampling (inspect % of requests, always inspect suspicious ones)
- Tiered inspection (fast scan → deep scan)
- Guard-level and pipeline time budgets
Still very much unproven in real production traffic.
What this is NOT
Just to be clear:
- Not a replacement for validation
- Not a WAF
- Not claiming to “block all attacks”
- Not production-ready yet
This is more of a design experiment around:
- guard composition
- runtime context modeling
- tradeoffs between signal quality and overhead
Why I’m sharing this
I’m mainly looking for feedback on:
- architecture choices
- guard interface design
- things that are fundamentally flawed
- existing projects that already solved this better
If you’ve worked with:
- Laravel internals
- PHP security tooling
- request lifecycles
- or runtime analysis systems
I’d love to hear your thoughts — positive or negative.
Links
GitHub (source & issues): https://github.com/M9nx/laravel-runtime-guard
Packagist: https://packagist.org/packages/m9nx/laravel-runtime-guard
If this turns out to be a dead end, that’s fine — I mainly want to understand why.
Any feedback is appreciated 🙏