Purifier Laravel Package

Product Decisions This Supports

• Rich-text / user-generated content features. Any roadmap item where users author HTML — WYSIWYG comments, forum posts, CMS pages, knowledge-base articles, support-ticket bodies, product descriptions, email template previews — needs a server-side sanitization decision. This package is that decision made concrete: whitelist-based HTML purification behind a Laravel service provider, facade, and publishable config.
• Build vs. buy for security primitives. Writing your own XSS filter is a classic PM mistake: it looks like a two-day task and becomes a permanent liability. HTMLPurifier is a mature, standards-oriented, whitelist (allow-list) sanitizer; this package is a thin Laravel integration around it. The buy decision is really "adopt HTMLPurifier," and the wrapper just removes a day or two of service-container plumbing.
• Editor capability as configuration, not code. The config file lets you scope allowed tags/attributes per field (e.g., strict for comments, permissive for CMS). That means product/marketing can expand what an editor supports without an engineering release, and security posture can be tightened per surface.
• Compliance and pentest remediation workstreams. Directly maps to OWASP A03 (Injection) and stored-XSS findings. Useful as the documented, auditable control in a SOC 2 / security-questionnaire answer: "untrusted HTML is sanitized via an allow-list before storage/rendering."
• Third-party and imported content. RSS ingestion, HTML pasted from Word/Google Docs, legacy CMS migrations, and inbound HTML email all carry arbitrary markup. A whitelist sanitizer is the standard answer, and this is the lowest-integration-effort way to get one in Laravel.
• De-risking a "just escape everything" shortcut. If the product needs rendering of formatting (bold, links, lists) rather than plain text, {{ }} escaping and strip_tags() are insufficient or too blunt. This package keeps the feature viable without incurring the security debt.

When to Consider This Package

Adopt when:

• You must accept untrusted HTML and render it back (not merely display it as escaped text), and you want an allow-list model rather than blocklist regexes.
• You are on Laravel and want config publishing, a facade, and container binding rather than instantiating HTMLPurifier by hand in every service.
• You need per-field sanitization profiles and are willing to maintain the config as a first-class part of the product surface.
• You can tolerate a single-maintainer, near-zero-adoption wrapper (2 stars, 0 dependents) by pinning a version, vendoring it, or forking — the durable value is upstream HTMLPurifier, not the wrapper.
• You will run it behind a cache (HTMLPurifier's serializer cache is essentially mandatory for performance) and can accept the CPU cost on write paths.

Look elsewhere when:

• You only ever output escaped text — Blade's {{ }} is the correct and cheaper control; adding this is unnecessary attack surface and dependency weight.
• You want a widely adopted Laravel wrapper with community pressure-testing — mews/purifier is the conventional choice and a lower-governance-risk pick.
• You need HTML5 semantics or CSS sanitization at modern fidelity — HTMLPurifier is HTML4/XHTML-oriented and conservative; Symfony's HtmlSanitizer or a W3C-sanitizer-based approach may fit better.
• Performance is on the hot path. This is not a per-request-on-every-render tool; sanitize on write or cache aggressively. For very high-volume input, evaluate lighter allow-list parsers.
• Framework compatibility is unverified. Confirm Laravel 10/11/12 and PHP 8.x support against the actual release, not the "Laravel 5+" description — the metadata and the code may disagree.
• You need client-side parity — always pair with a browser-side sanitizer (e.g., DOMPurify) for defense in depth; this package is server-only.

How to Pitch It (Stakeholders)

To executives: This is a small, cheap security control for a class of feature we will build anyway — anywhere users type formatted content. It uses a long-established open-source sanitizer (MIT licensed, no vendor lock-in, no cost) and turns "prevent stored XSS" from a bespoke engineering project into a configuration exercise. Adoption cost is hours, not weeks, and it gives us a defensible, documentable answer in security reviews. The main caveat is governance, not technology: the Laravel wrapper itself is a low-adoption package, so we mitigate by pinning the version and treating the underlying library as the real dependency — with a fork as the fallback, at negligible cost.

To engineering: Thin wrapper over HTMLPurifier — service provider, facade, publishable config with per-profile allow-lists. Sanitize on input, cache the serializer definition, and write tests asserting round-trip behavior for our allowed tag set. Two things to verify before we commit: framework/PHP version support on the current release, and whether the wrapper adds anything we'd miss by depending on ezyang/htmlpurifier directly. Either path is acceptable; the wrapper is a convenience, not an architectural commitment.