graham-campbell/binput
Binput is a Laravel input cleaner that sanitises user input via HTMLPurifier, stripping dangerous markup while keeping safe content. It handles strings and arrays, supports cleaning types such as default, html, url and query, and integrates through a simple facade for safer request data.
Standardizing the input-read contract across an API surface. The package's actual, defensible value is narrow and mechanical: one accessor (Binput::get('key', $default)) reads query strings, form bodies, and JSON payloads the same way. That supports a concrete roadmap decision — do we standardize how controllers read input, or keep mixing request()->input(), request()->query(), and json_decode($request->getContent()) per endpoint? If you have endpoints where JSON clients and form clients behave differently, this is a candidate fix inside a normal feature sprint.
A genuine build-vs-buy-vs-do-nothing triage, with the honest answer usually "do nothing." The three options are (a) adopt this package, (b) write ~20–40 lines of an in-house input helper the team owns outright, or (c) keep using request()->input() with a written convention. For most Laravel apps (c) already wins and (b) is trivial. Framing the decision this way — with the maintenance cost of a low-adoption dependency priced in — is more valuable than the decision itself, and it establishes a reusable pattern for future thin-package proposals.
Correcting a mis-set expectation before it becomes rework. The package markets itself as an "Input Protector," which reads as a security control. It is not: it neither validates nor sanitizes. A PM decision to adopt it because "we need input protection" would be a category error that ships false confidence and, worse, invites someone to bolt sanitization onto it and collide with Blade's output escaping (double-encoding: <). Killing that framing early is a decision this package's evaluation directly supports.
Dependency governance as standing product policy. Zero dependents and a single maintainer on a component that would sit on every request's input path is decision-grade input, not a technical footnote. That justifies a durable house rule about thin packages — vendor, pin, wrap in characterization tests, or decline — that applies long after this specific evaluation closes.
Forcing the written input policy the team currently doesn't have. Adopting or explicitly rejecting a standardized reader makes someone document the house rule: "input is read one way, validated by Form Requests, escaped on output." That one-paragraph artifact is worth more than the library and pays off on every subsequent feature review and onboarding.
Legacy and migration sequencing. The credible use case is an older Laravel app with inconsistent reading patterns carried forward through the L11 upgrade. The v11.1.0 release extends the package's relevance to L11 apps; it does not extend it to L12.
Not supported: security hardening, penetration-test remediation, or OWASP A03 closure. Those decisions need validation rules, parameterized queries, policies, $fillable/$guarded, and output escaping — or a real HTML purifier. If a finding is framed as "unvalidated input reaches views," this package is not the mitigation and should not be scoped as one.
Consider it when:
application/json versus application/x-www-form-urlencoded, or where some controllers reach into $_GET/json_decode directly. Evidence beats precaution.composer.json illuminate/* and php constraints, install, run php artisan package:discover, and confirm the facade alias resolves before building anything on it. On Laravel 12, treat it as unverified until your own suite passes.README.md, then src/, then the release notes. If you can't read it, don't standardize on it.null, dot-notation, nested JSON) contained.Look elsewhere when:
request()->input() plus Form Requests plus Blade/Inertia/API Resource escaping is working, you'd be adding a dependency to solve a problem you don't have.Binput::get() in a stripper and call it a security layer.To executives: We evaluated a Laravel package that standardizes how our controllers read incoming request data, so form posts and JSON API calls go through one consistent accessor instead of several different code paths. My recommendation is not to adopt it as a security measure — despite its "Input Protector" name, it does not validate, sanitize, or block anything; our existing validation and output escaping remain the actual controls. The narrow, legitimate use case is consistency: if we have endpoints that behave differently for browser forms versus API clients, a small in-house helper gives us the same benefit in a few dozen lines that we own outright. The package itself has a single maintainer and effectively no other users, which means adopting it converts an outage risk into a maintenance obligation. Net: no spend, no new dependency; I'll write down our input-handling rule so future features follow one convention, and we can revisit if inconsistency bugs actually show up in the backlog.
To engineering: This is a thin facade over Laravel's existing input handling — one accessor, no validation, no sanitization, no middleware. If we use it, the contract is: Binput::get('key', $default) for reading, Form Requests for validating, output escaping for rendering — never sanitize on input, or we'll produce double-encoded output. Scope it to one vertical slice, add characterization tests for JSON, form, and query access, verify missing-key semantics against ConvertEmptyStringsToNull, and keep $request->file() for uploads. Files aren't input here. Verify L11 compatibility in composer.json before anything else; L12 is unclaimed. Given the single-maintainer, zero-dependent profile, my default is either an in-house helper we own or simply a written convention — adopt the package only if a specific endpoint is demonstrably broken by mixed content types.
How can I help you explore Laravel packages today?