Sanitizer Laravel Package

Product Decisions This Supports

• Input hygiene as a first-class feature, not a per-endpoint afterthought. Any roadmap item involving user-generated content — comments, profiles, support tickets, reviews, search queries, CSV/import pipelines, admin-editable HTML — needs a consistent normalization layer. A declarative sanitizer lets you define that once instead of re-implementing trim/strip_tags/lowercase logic in every controller.
• Build vs. buy on a small, well-bounded problem. Writing an internal sanitization service is maybe 1–2 days of engineering plus indefinite ownership. This package is MIT-licensed and narrow in scope, so the "buy" (adopt) path is cheap and reversible. The real decision isn't the package — it's whether you standardize sanitization company-wide or leave it ad hoc.
• Security/compliance roadmap acceleration. Sanitization at the trust boundary is a recurring line item in XSS and data-quality hardening work. Adopting a shared mechanism gives you something concrete to point at in a security review, rather than "we trust the frontend."
• Reduced review friction and incident surface. A single rule set that reviewers can read and diff beats scattered inline transformations. It also makes it obvious when a new endpoint forgot to sanitize — a common source of post-launch bugs.
• Use cases that map cleanly: standardizing form input across a Laravel monolith or API, normalizing payloads from third-party webhooks before persistence, cleaning legacy data during migrations, and enforcing house rules on names, slugs, phone numbers, and free-text fields.
• Explicitly not a substitute for validation. Sanitization cleans data; validation rejects it; output encoding protects rendering. Treating this package as a security silver bullet is a product risk, and the roadmap should fund all three, not just this one.

When to Consider This Package

Adopt when:

• You're on Laravel (or plain PHP) and already have many endpoints applying ad hoc input cleaning.
• Your sanitization needs are simple and structural — trimming, tag stripping, case normalization, character allow-lists, casting.
• You want rules to live in config/declarative arrays that PMs and reviewers can read, rather than buried in controllers.
• You want a small, MIT-licensed dependency with a low blast radius if you later remove it.
• You can wrap it behind an internal facade or service so the rest of the codebase doesn't import it directly.

Look elsewhere or build in-house when:

• You need serious HTML sanitization (rich text editors, user-authored markup with an allow-list). Use a dedicated, battle-tested HTML sanitizer — DOMPurify on the client plus a hardened server-side allow-list library. A general-purpose sanitizer is the wrong tool.
• Your actual problem is validation (types, required fields, ranges) — that's Laravel FormRequests/validation rules, not this.
• Your real exposure is output/XSS at render time — contextual escaping in Blade/Twig and a CSP matter more than input scrubbing.
• You need enterprise assurance: active maintainers, security disclosure process, SLAs, large install base. At ~115 stars and a single-maintainer profile, this is a "small community" dependency — fine for internal tooling, risky as a load-bearing security control in a regulated product.
• You need streaming/large-file or binary sanitization, or non-PHP services in the stack — a polyglot platform wants a language-agnostic boundary (API gateway, shared middleware) instead.

Adoption guardrails: pin the version, wrap it in an internal InputSanitizer abstraction, add tests that assert your rule set's behavior, and confirm the release cadence (recent releases are a positive signal, but verify commit activity and issue responsiveness before it lands in a security-sensitive path).

How to Pitch It (Stakeholders)

For executives (one paragraph): We have a recurring, low-glamour source of bugs and security findings: every feature cleans user input slightly differently, or forgets to. This package gives us one declarative, MIT-licensed way to define sanitization rules across the Laravel app. It's a small dependency with a small failure radius, it speeds up delivery on any feature that accepts user data, and it gives us a concrete artifact for security reviews. Cost is near zero; the main risk is that it's a small open-source project, which we mitigate by isolating it behind our own interface so we can swap it out. Recommendation: adopt for structural input cleaning, and fund proper validation and output encoding separately — this is one layer, not the whole defense.

For engineering: Laravel-native integration (service provider + facade), rules expressed as declarative arrays, easy to unit test, composes cleanly with FormRequests and middleware. Wrap it so the package doesn't leak into domain code, pin the version, and document that sanitization ≠ validation ≠ escaping. Do not use it as the HTML sanitizer for rich-text fields — bring in a purpose-built allow-list library for that.

For security: Treat this as defense-in-depth on input normalization, not a control that satisfies an XSS finding. Pair with contextual output escaping, a CSP, and server-side allow-listing for any rendered HTML.