Sanitizer Laravel Package

Technical Evaluation

Architecture fit. elegantweb/sanitizer is a thin, opinionated layer that mirrors Laravel's validator API: you declare a Sanitizer subclass with a $filters array and invoke sanitize(). It leans on illuminate/support and illuminate/validation, so it slots into the Laravel service container without bespoke wiring, and the same class can be instantiated standalone in a plain PHP service (useful for shared libraries, queue workers, or CLI importers). It is not an architectural component — it is a leaf-level utility that fits cleanly into the input-boundary layer (HTTP middleware, FormRequests, console commands, job payload hydration) and does not impose its own conventions on domain logic.

Integration feasibility. Composer-installable, PSR-4 autoloaded, MIT-licensed, with package auto-discovery for the service provider. Adoption cost is measured in hours, not sprints: define filters at the request edge, register custom filters for domain-specific normalization (e.g., phone/E.164, slug generation), and call from controllers or FormRequest prepareForValidation(). The absence of a database, queue, or cache dependency means zero infrastructure change and trivial rollback (remove the Composer line, delete sanitizer classes).

Technical risk. The dominant risk is supply chain, not technology. At ~115 stars and a single-maintainer profile, bus factor is 1 and there is no vendor SLA. The March 2026 release date indicates active maintenance today, but a fast-moving Laravel major (annual cadence) can outpace a small package. Secondary risks: (a) silent, lossy transformations — sanitizers return cleaned data without surfacing what was stripped, which can mask upstream contract violations; (b) divergence between this filter set and laravel/framework's own TrimStrings/ConvertEmptyStringsToNull middleware, creating two competing normalization passes if not sequenced deliberately. Security posture is reasonable — sanitization is defense-in-depth, not a substitute for output encoding and parameterized queries — but the team should not treat it as an XSS control.

Key questions for the maintainer/team.

1. Which Laravel and PHP versions are covered by CI, and what is the stated support window per major?
2. Are custom filters first-class and stable, or an escape hatch that can break across minors?
3. What is the failure contract — exceptions vs. silent coercion — and is it configurable per filter?
4. Is there a published security disclosure process?
5. How does it interact with Laravel's built-in TrimStrings middleware ordering?

Integration Approach

Stack fit. Best suited to Laravel 8–11 on PHP 8.0–8.3, and to standalone PHP services already pulling illuminate/* components. It is a poor fit for non-Composer legacy codebases or frameworks with a different container contract; in those cases the filter classes can be used statically but you lose the ergonomics that justify the dependency.

Migration path. Introduce additively rather than retrofitting. Phase 1: add the package and use it only on new endpoints and the highest-risk existing surfaces — user-generated content (comments, profiles, support tickets), free-text search, and any field that flows into logs or emails. Phase 2: wrap existing FormRequest classes by delegating from prepareForValidation() to a Sanitizer instance, leaving validation rules untouched so behavior changes are isolated to normalization. Phase 3: consolidate ad-hoc trim()/strip_tags()/filter_var() calls scattered through controllers into named Sanitizer classes, which also makes them unit-testable. Phase 4 (optional): bind sanitizers to interfaces and inject them, enabling swap-out if the package is abandoned.

Compatibility. Watch three seams: the illuminate/validation version constraint (the most likely break point on a Laravel major upgrade), the interaction with TrimStrings/ConvertEmptyStringsToNull global middleware (define a single canonical ordering — middleware first, Sanitizer second), and any typed-property or readonly-class assumptions in your own DTOs, since Sanitizer output is array-shaped, not object-shaped. Add a composer outdated check to the upgrade runbook.

Sequencing. Week 1: spike on one endpoint, validate filter coverage against real payloads, write custom filters for domain types. Week 2: codify conventions (naming, where sanitizers live, exception handling) in a short ADR and add a Pint/PHPStan rule so sanitizers are mandatory on new controllers. Weeks 3–4: roll out to the prioritized endpoint list with before/after payload fixtures to catch over-sanitization. Defer broad retrofits until the team has run it in production for one release cycle.

Operational Impact

Maintenance. Low ongoing effort — the package is stateless and configuration-light, so upkeep is essentially "bump the version on Laravel upgrades." The real maintenance tax is governance: without a convention doc, sanitization logic will drift back into controllers within two quarters. Budget roughly one engineering day per Laravel major upgrade to validate filter behavior, plus an owner for the dependency (a named person, not a team).

Support. Community-only. No commercial backing, no guaranteed issue triage, no CVE feed. Mitigate by pinning to a known-good version, vendoring a fork if needed (MIT permits this), and keeping custom filters in application code rather than upstreaming them so they survive a package swap.

Scaling. Negligible. Sanitization is in-process CPU work on request payloads; cost is proportional to payload size and filter count, not traffic topology. No shared state, no network hops, no cache invalidation. At high RPS the only concern is regex-heavy custom filters on large text fields — measure if you sanitize multi-KB bodies on hot paths.

Failure modes. (1) Over-sanitization / silent data loss — strip_tags or aggressive trim quietly mangles legitimate content; mitigate with round-trip tests on realistic fixtures and a rule that sanitizers never alter fields used for matching or billing. (2) Double normalization — global middleware plus Sanitizer produce order-dependent results; fix by owning one pass. (3) Uncaught filter exceptions — malformed input throwing rather than coercing can 500 a request; decide per endpoint and wrap at the boundary. (4) Abandonment — no release for a Laravel major; detect via CI matrix and have the vendor-fork escape hatch ready. (5) False security confidence — teams assuming sanitization covers XSS/SQLi; counter with a standing note that output encoding and query parameterization remain mandatory.

Ramp-up. Very low for anyone who has written a Laravel validator — the mental model transfers directly (rules array, dot-notation for nested keys, custom rule classes). Expect under an hour for a mid-level engineer to ship a first sanitizer, and half a day to be productive with custom filters. The onboarding cost is dominated not by the API but by the team conventions you write around it: where sanitizers live, which layer owns normalization, and how over-sanitization is caught in review. Pair the rollout with one worked example in the repo and a lint rule, and ramp-up is effectively absorbed into normal code review.