Weave Code
Json Request Check Bundle Laravel Package
iwf-web/json-request-check-bundle
iwf-web/json-request-check-bundle adds JSON request checking to Symfony applications, helping validate incoming JSON payloads before they reach your controllers. A small integration for more consistent API request handling.
json-request-check-bundle is a PHP package for validating incoming JSON request bodies before your application processes them. It helps catch malformed or incomplete payloads early, returning clear errors instead of letting bad data reach your controllers and services.
- Schema-based validation for required fields, types, and structure
- Clear error responses for malformed or invalid JSON
- Framework-friendly integration for request handling pipelines
- Lightweight with no heavy dependencies
- Reusable rules across multiple endpoints
Frequently asked questions about Json Request Check Bundle
- Does iwf-web/json-request-check-bundle work with Laravel?
- No. It is a Symfony bundle that hooks the kernel.request event through a Bundle class plus a DI Extension and Configuration, and Laravel has no bundle bootstrap, no matching event name, and a different container and config model. There is no drop-in path: you would be hand-registering a Symfony subscriber outside Laravel's normal middleware lifecycle, which is fragile and unidiomatic. Treat it as reference code, not as a dependency.
- Can I install this Symfony bundle in a Laravel project with Composer?
- You can run composer require iwf-web/json-request-check-bundle, but it pulls in Symfony bundle machinery that Laravel never boots, so nothing will actually execute. There is no service provider, no publishable config, and no middleware class you can register in a route group. If you want the behavior, port the small check into your own middleware instead of installing the bundle.
- Is HashDos still a real threat on PHP 8, or is this package obsolete?
- Largely obsolete in its original form: PHP 7 and later randomize hash seeds, which removes the colliding-key amplification that classic HashDos exploited. What remains genuinely useful is generic input-surface limiting — capping body bytes, top-level and nested key counts, and nesting depth. That is real hardening for JSON endpoints, but it is narrower than the package name implies and is roughly fifty lines of your own code.
- How do I limit JSON body size and key count in Laravel without this bundle?
- Write a small global middleware — call it LimitJsonPayload — that short-circuits on Content-Length before reading the body, decodes with json_decode($body, true, $maxDepth) or uses json_validate on PHP 8.3+, counts keys, and rejects anything past your thresholds with a 413 or 422 and a stable error envelope. Register it after TrustProxies and TrimStrings but before controller resolution and form-request validation, so oversized payloads never reach route binding or validation cost. Budget half a day to a day including adversarial tests.
- Should JSON payload limits be enforced at nginx/ALB or in Laravel middleware?
- Both, in that order. Set client_max_body_size and JSON content-type enforcement at the proxy or ingress first: it takes days, covers every endpoint, and puts zero code in the request path. The Laravel middleware then becomes defense-in-depth for per-route thresholds and for deployments sitting behind a misconfigured proxy. Do not treat the app-layer check as your primary control.
- Why doesn't PHP's max_input_vars protect my JSON API endpoints?
- max_input_vars only governs PHP's parsing of query strings and form-encoded bodies. An application/json body is read as a raw stream and decoded by your own code, so PHP's key-count protection never engages. That is precisely the gap this bundle gestures at, and it is why JSON endpoints will happily accept payloads containing hundreds of thousands of keys by default.
- Is it safe to put a 1-star package in the request path of a production API?
- Risky and hard to justify. The package has one star, no dependents, a single-agency maintainer, and no visible security review, and you would be placing it directly in the request path — the worst possible place for untrusted third-party code. The MIT license makes extraction clean, so vendor the logic or reimplement it and keep the dependency surface at zero.
- What thresholds should I use for max bytes, key count, and nesting depth?
- Instrument before you enforce. Log Content-Length and key counts for one to two weeks, then set limits from the p99.9 of legitimate traffic, with per-route overrides for webhooks, bulk import, and GraphQL where payloads are naturally larger. Ship the middleware in monitor-only mode first, then enforce, then add regression tests built from adversarial fixtures.
- Will a JSON limiting middleware work under Laravel Octane and with queued webhooks?
- Yes, if you write it correctly. The middleware must hold no per-request state in static properties, since Octane keeps workers alive between requests, and thresholds should come from config resolved per request rather than mutated globals. Queued webhook jobs that receive the same payloads bypass HTTP middleware entirely, so apply the same check as a validation rule or job middleware wherever those paths matter.
- Are there Laravel-native alternatives to this bundle, and how should I test the check?
- There is no maintained Laravel-native equivalent worth depending on, so the realistic options are a small internal package you own or a few lines in App\Http\Middleware. Either way, test with adversarial fixtures — deeply nested arrays, huge key counts, truncated JSON, and chunked bodies with no Content-Length — and assert you return 413 or 422 rather than an uncaught 500. Credit the original bundle in the middleware docblock as prior art.
Weaver
How can I help you explore Laravel packages today?