Exploring Runtime Request Inspection in Laravel (Guards, Contexts, and Tradeoffs)

Source: Dev.to

Introduction

I’ve been experimenting with a Laravel package that inspects requests during runtime, after the request has entered the framework (rather than only before the controller is hit).

The idea started as a question rather than a solution:

Can runtime context inside the framework give better security signals than static request inspection?

To explore this, I prototyped a package that builds a RuntimeContext once the request is already inside Laravel and runs a pipeline of Guards against it.

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

Guard Characteristics

• Configurable and can be enabled/disabled at runtime
• Each guard has a defined cost / priority

Profiles

• Group guards per route or use‑case
• Different behavior for APIs vs. admin routes
• Different enforcement modes

Response Modes

Example Guard Types (not exhaustive)

• 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)

Performance Considerations

• Deduplication cache for repeated payloads
• Sampling – inspect a percentage of requests, always inspect suspicious ones
• Tiered inspection – fast scan → deep scan
• Guard‑level and pipeline time budgets

These experiments aim to balance signal quality against overhead, though the approach is still unproven in real production traffic.

Limitations

• Not a replacement for validation
• Not a WAF
• Not claiming to “block all attacks”
• Not production‑ready

The project is primarily a design experiment around guard composition, runtime context modeling, and trade‑offs between signal quality and overhead.

Seeking Feedback

I’m looking for input on:

• Architecture choices
• Guard interface design
• Fundamental flaws, if any
• Existing projects that solve this better

If you have experience with:

• Laravel internals
• PHP security tooling
• Request lifecycles
• Runtime analysis systems

…please share your thoughts, positive or negative.

Links

• GitHub (source & issues):
• Packagist: