Purifier Laravel Package

Product Decisions This Supports

• User-generated content features: Any roadmap item where users submit HTML—comments, forums, reviews, rich-text bios, CMS pages, support tickets, email templates—needs a sanitization story. This package answers "how do we safely render untrusted HTML?" without building it ourselves.
• Build vs. buy: Strongly favors buy/borrow. Writing a custom HTML sanitizer is a well-known anti-pattern; HTMLPurifier is battle-tested against XSS. This wrapper lets engineering integrate it in hours instead of days.
• Security posture & compliance: XSS is a recurring OWASP Top 10 risk. Adopting a vetted sanitizer is a checkable control for security reviews, pen-test remediations, and SOC2/ISO-style audits.
• Scope decisions for rich content: Configurable allowed tags/attributes forces a product decision on what HTML we accept (e.g., bold/links but not <script>/<iframe>), which is a policy choice PMs should own.
• Roadmap risk assessment: At 32 stars and pinned to Laravel 5, this is a tactical dependency, not a strategic platform bet. Use it to ship, but budget for replacement if the app upgrades.

When to Consider This Package

Consider it when:

• You're on Laravel 5.x (or a compatible stack) and need HTML sanitization integrated with the framework's service container and config.
• You need configurable, policy-driven filtering (allow-list of tags/attributes) rather than blunt stripping.
• You're storing user HTML and rendering it back (WYSIWYG, markdown-to-HTML pipelines, comments).
• You want a thin wrapper over ezyang/htmlpurifier with Laravel-style config rather than hand-wiring the library.
• MIT license and zero vendor lock-in matter to procurement.

Look elsewhere when:

• You're on Laravel 8/9/10/11 or modern PHP—verify maintenance and compatibility first; the "Laravel 5" scope and low star count signal likely dormancy.
• You need an actively maintained dependency with recent releases, security patches, and community support. In that case evaluate mews/purifier (a more widely adopted fork), using ezyang/htmlpurifier directly, or modern alternatives like Symfony's HTML Sanitizer for non-Laravel PHP.
• Your sanitization needs are trivial (plain-text only, strip_tags-level) and don't justify an extra dependency.
• You're rendering only trusted/internal content—sanitization adds processing overhead without benefit.

How to Pitch It (Stakeholders)

To executives: This is a small, MIT-licensed security component that lets us safely accept user-generated content—a prerequisite for engagement features like comments, reviews, and rich profiles. It replaces the risky option of writing our own sanitizer, reducing XSS exposure and lowering the cost of security/compliance reviews. Low cost, low commitment: it's a library, not a platform.

To engineering: It's a thin Laravel service-provider wrapper around the proven HTMLPurifier library, configurable allow-lists, drop-in via config. Caveats to flag: it targets Laravel 5 and has a small community (~32 stars), so treat it as a pragmatic shortcut—confirm compatibility with our Laravel version, pin the version, and keep an exit path to mews/purifier or the upstream library if we modernize the stack. Do not roll our own sanitizer.