DEV Community

Cover image for Exploring Runtime Request Inspection in Laravel (Guards, Contexts, and Tradeoffs)
Mounir Elsrogy
Mounir Elsrogy

Posted on

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

#architecture #laravel #security

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 🙏

Top comments (0)