Json Request Check Bundle Laravel Package

Product Decisions This Supports

• Availability risk budgeting. HashDos (hash-collision and oversized-JSON exhaustion) is an availability threat, not a data-breach threat. This package lets you decide whether that risk gets an application-layer control or is accepted as covered by infrastructure.
• Defense-in-depth placement. Helps answer "where does body-size and JSON-shape enforcement live?" — edge (CDN/WAF/ingress), reverse proxy (client_max_body_size), or framework middleware. This bundle argues for a framework-level backstop.
• Build vs. buy vs. copy. Scope is narrow enough (reject/limit JSON request bodies before json_decode) that the real decision is "adopt a dependency" vs. "write ~50 lines of request-event middleware." Given 1 star and 0 dependents, writing it in-house is a legitimate, defensible option and should be explicitly on the table.
• Roadmap input for API hardening. If you ship a public JSON API, this is a candidate item in a "public surface hardening" epic alongside rate limiting, request timeouts, and max body size — useful for prioritization against other security work.
• Incident/retro follow-through. If you've had a CPU-spike or memory-exhaustion incident traced to a large or adversarial JSON payload, this is a concrete remediation ticket rather than a vague "add rate limiting."
• Compliance and questionnaire answers. Supports answering due-diligence questions about input validation and DoS controls on public endpoints, with a named control rather than a narrative.
• Not a decision driver: it does not affect feature scope, pricing, or customer-facing functionality. Treat it as infrastructure hygiene.

When to Consider This Package

Consider it when:

• You are on Symfony (this is a Symfony bundle — if your stack is Laravel, it is not directly usable; you'd port the idea into middleware instead).
• You expose unauthenticated or broadly authenticated JSON endpoints that call json_decode on attacker-controlled bodies.
• You own the runtime (self-hosted, on-prem, or your own containers) and cannot rely on an upstream gateway to bound body size.
• Your current controls are limited to post_max_size / max_input_vars, which do not constrain JSON payload shape — this is the actual gap the package targets.
• You want a small, auditable, MIT-licensed control and are willing to vendor or fork it.

Look elsewhere (or build in-house) when:

• Your stack is Laravel — no compatibility; implement equivalent request middleware and pair it with ThrottleRequests and proxy-level limits.
• You already terminate traffic at a WAF/API gateway that enforces body-size and JSON depth limits; the marginal risk reduction is low and you're adding a dependency for parity, not coverage.
• Dependency governance is strict. 1 star, 0 dependents, and a single-maintainer release (June 2025) mean no ecosystem validation and no bus factor. Any adoption should assume you own the code.
• You need SLAs, security review artifacts, or long-term maintenance commitments from the vendor — none are available here.
• The threat is better solved at the edge: proxy body limits plus request timeouts typically eliminate the same class of attack with less code in the request path.
• You are latency-sensitive on every JSON request and cannot justify a per-request inspection pass without measured evidence it's needed.

Adoption shape I'd recommend: a one-sprint spike — read the source (it's small), add it behind a feature flag on one public endpoint, measure p99 overhead, and keep the in-house middleware as the fallback if the dependency proves unmaintained.

How to Pitch It (Stakeholders)

For executives: This is a low-cost, low-blast-radius hardening option for our public JSON API. It addresses a specific availability attack — adversarial JSON payloads that exhaust CPU or memory during decoding — which our current proxy and PHP limits do not fully cover. License is MIT; integration cost is small; it changes no customer-facing behavior. The caveat is maturity: the project has essentially no adoption, so we should treat it as code we adopt and own rather than a vendor relationship. Recommendation is a bounded evaluation, not a committed dependency.

For engineering: The bundle adds request-level checks that bound and reject oversized or pathological JSON bodies before json_decode runs — closing a gap that post_max_size and max_input_vars leave open. It's a Symfony bundle, so Laravel services need an equivalent middleware rather than this package. Review the source before adoption; at this size and adoption level, plan to fork or reimplement if the upstream goes quiet, and pair it with proxy-level body limits and request timeouts so the framework control is a backstop, not the primary defense.