Laravel Xss Filter Laravel Package

Product Decisions This Supports

• Rich text and UGC features. Any roadmap item where users author HTML (comments, profiles, CMS pages, support tickets, product descriptions, email templates) forces a decision: store raw HTML and render with {!! !!}, or strip markup entirely. This package exists specifically for the middle path — it sanitizes input while preserving benign markup, so you don't have to degrade the feature to plain text just to ship safely.
• Build vs. buy for sanitization. A hand-rolled regex sanitizer is a classic PM-visible security liability — it silently fails on malformed/obfuscated payloads and is impossible to keep current. Adopting a maintained, MIT-licensed filter (or its better-known competitors) turns an open-ended security engineering task into a small dependency review. This is a buy decision with a near-zero price tag.
• Security/compliance workstreams. Maps directly to OWASP ASVS input-handling controls and pentest findings of the "stored XSS" variety. Useful as a documented, auditable control when a customer security questionnaire or SOC 2 audit asks "how do you handle untrusted HTML input?"
• Defense-in-depth for legacy surfaces. Where older Blade templates, admin panels, or third-party integrations render unescaped output, request-level filtering is a cheap compensating control that doesn't require rewriting views.
• Multi-tenant content authoring. Tenants writing custom HTML for emails, landing pages, or notification templates need markup preserved — but not <script>. This is squarely the package's sweet spot.
• Deprioritization signal. With 41 stars and zero dependents, this is not a bandwagon; the decision to use it should be driven by a specific feature need, not by ecosystem momentum.

When to Consider This Package

Consider it when:

• You have (or are about to ship) at least one field where user-supplied HTML is persisted and re-rendered as markup.
• You want sanitization applied centrally (middleware/request layer) rather than remembered at every controller.
• You need markup preserved — a "strip everything" approach would break the feature.
• Your team lacks a dedicated security engineer and would otherwise write its own filter.
• You want a small, readable, MIT-licensed dependency you can vendor or fork if needed.

Look elsewhere or skip it when:

• Your app escapes on output. If everything goes through Blade's {{ }}, XSS is already mitigated; adding input filtering is redundant and risks mangling legitimate data (double-encoding, broken JSON, mangled Markdown).
• You need a battle-tested, widely-deployed sanitizer. mews/purifier (HTMLPurifier) has orders of magnitude more adoption, a formal allowlist model, and a long CVE history of being hardened. For a regulated or high-traffic product, that maturity usually wins.
• You need policy at the browser edge. A strict Content-Security-Policy plus output encoding is the more durable control; a PHP filter cannot substitute for it.
• Adoption risk is unacceptable. Zero dependents and ~41 stars means no community backstop. Fine for a small surface area, questionable as a load-bearing security control.
• Performance is tight. Middleware running a parser on every request (including large multipart payloads and file uploads) deserves a benchmark before you commit.
• You need a support contract or SLA. There is none implied here.

How to Pitch It (Stakeholders)

To executives: We have a small, concrete security decision rather than a strategic bet. Wherever we let customers or end users type formatting into our product — comments, descriptions, templates — we're one bad string away from a stored-XSS incident and the disclosure, remediation, and trust cost that follows. This package is an MIT-licensed, low-cost control that lets us launch those features without either stripping formatting from the product or asking engineering to invent a sanitizer. The cost is a day of integration and review; the downside is bounded because it's a tiny, forkable dependency with no vendor lock-in.

To engineering: It's a request-layer HTML filter that preserves markup instead of nuking it — the gap between strip_tags and "we can't ship rich text." Two caveats to validate before adoption: (1) it's a low-adoption package (~41 stars, no dependents), so treat it as a reviewed dependency, not an assumed-safe one — pin the version, wrap it behind a single service class so it's swappable, and add regression tests with a known XSS payload corpus; (2) sanitize-on-input is defense in depth, not a replacement for output encoding and a CSP header. If benchmarking shows meaningful overhead on large payloads, restrict it to the routes that actually accept HTML. If the review raises doubts, mews/purifier is the drop-in upgrade path with the same wrapper interface.