Json Request Check Bundle Laravel Package

Technical Evaluation

Verdict: adopt the control, not the package. The problem space is legitimate; this specific artifact is a Symfony bundle with near-zero adoption, and the correct Laravel play is to reimplement the check as middleware or push it to the edge.

Architecture fit

• The bundle hooks Symfony's kernel.request event and registers via a Bundle class plus a DI Extension/Configuration. Laravel has no bundle bootstrap; its HTTP kernel is a middleware pipeline with a different container and config model. There is no drop-in path.
• Laravel does use Symfony components (http-foundation, partially http-kernel), so a manual wire-up is theoretically possible, but you would be hand-registering an event subscriber outside the framework's normal lifecycle — fragile and unidiomatic.
• The logic is small and portable: inspect Content-Length, decode JSON with a depth cap, count top-level and nested keys, reject past thresholds. That is a ~50-line middleware in Laravel terms.

Integration feasibility

• Low as a dependency (Composer install pulls Symfony bundle machinery you won't use), medium as a reference implementation or fork source. MIT license makes extraction clean.
• Effort to reimplement natively: roughly 0.5–1 dev-day plus tests, versus an open-ended integration spike to force a Symfony bundle into Laravel.

Technical risk

• Supply chain / bus factor: 1 star, 0 dependents, single-agency maintainer, no visible security review. Treat as untrusted third-party code in the request path — the worst place for it.
• Threat-model erosion: HashDos via colliding keys was substantially mitigated in PHP 7+ by randomized hash seeds. The residual value is generic input-surface limiting (body size, key count, nesting depth) — real, but narrower than the package name implies.
• Coverage gap worth noting: PHP's max_input_vars does not apply to application/json bodies, so JSON endpoints genuinely lack key-count protection by default. That is the actual gap this package gestures at, and it is a few lines to close ourselves.

Key questions

1. Which JSON endpoints accept unbounded bodies today, and what is our real worst-case payload (webhooks, bulk import, GraphQL)?
2. Do we already cap this at nginx/ALB/ingress (client_max_body_size, body-size limits)? If yes, the app-layer check is defense-in-depth, not the primary control.
3. What are our thresholds — bytes, key count, nesting depth — and do they differ per route?
4. Is there a maintained Laravel-native equivalent, or do we own a small internal package?
5. Can we accept the maintenance burden of vendored code in the request path?

Integration Approach

Stack fit

• Target Laravel 10/11/12 on PHP 8.1+. Use json_validate (PHP 8.3+) or json_decode(..., depth: N) for cheap structural validation; short-circuit on Content-Length before touching the body.
• Place the check as global middleware after TrustProxies/TrimStrings and before controller resolution and form-request validation, so malformed payloads never reach binding or validation cost.

Migration path

1. Edge first (days): set body-size limits and JSON content-type enforcement at the proxy/ingress. Highest coverage per unit of effort, zero code in the request path.
2. App layer (one sprint): native LimitJsonPayload middleware — byte cap, top-level key cap, depth cap — returning a Laravel 413/422 with a stable error envelope. Do not install the bundle.
3. Reference, don't depend: read the bundle's threshold defaults and config shape as prior art; credit it in the middleware docblock.

Compatibility

• Symfony's HttpException semantics map to Laravel's handler; ensure rejections produce 413 Payload Too Large, not an uncaught 500.
• Verify behavior under Octane (no per-request static state) and under queued/queued-webhook paths that share the same payloads.

Sequencing Instrument first (log Content-Length and key counts for 1–2 weeks) → set thresholds from p99.9 of legitimate traffic → ship edge limits → ship middleware in monitor-only mode → enforce → add regression tests with adversarial fixtures (deeply nested, wide-key, colliding-key).

Operational Impact

Maintenance

• Vendored/native code we own: low churn, but we own it forever. Upstream is effectively a read-only reference; assume no patches and no CVE response. MIT permits fork-and-forget, which is the right posture here.

Support

• None available from upstream. Internal ownership sits with the platform/backend team; document the thresholds and the rationale in the repo so the next owner doesn't silently raise them.

Scaling

• Naive implementations decode the entire body before checking size — which reproduces the DoS you're defending against. Always gate on Content-Length first and only decode when it passes; cap decode depth. Overhead is then negligible relative to the request.
• At high RPS, avoid double-decoding: validate once and pass the decoded structure forward, or use json_validate where available.

Failure modes

• False positives on legitimate large payloads (bulk import, partner webhooks, file-adjacent JSON) → choose per-route policy, not one global number.
• Wrong status code or exception type surfacing as 500, poisoning client retry logic.
• Silent threshold drift during incident response, re-opening exposure.
• Interaction with streaming/chunked requests that lack Content-Length — need a fallback read cap.

Ramp-up

• Any mid-level Laravel engineer can build and test this in under a day; the hard part is policy (thresholds per endpoint) and rollout discipline, not code. Budget a short design review with security, and a documented exception path for endpoints that legitimately exceed limits.