Html Sanitizer Laravel Package

Product Decisions This Supports

• Whether to ship rich-text/UGC features at all. Any roadmap item that renders user-authored HTML — WYSIWYG comments, support-ticket bodies, CMS pages, marketplace listings, notification/email templates, imported RSS or legacy content — is only viable if untrusted markup can be safely re-rendered. A whitelist sanitizer is the enabling dependency for those bets.
• Build vs. buy vs. reuse. The alternative to adopting this is hand-rolling regex/strip_tags filtering or letting engineers spend sprint time on a bespoke sanitizer. Both are worse outcomes for a non-differentiating, security-critical concern; a vetted library converts an open-ended engineering risk into a bounded dependency decision.
• Risk posture and compliance evidence. Persisting and re-rendering user HTML is a standing XSS surface. Choosing a maintained, whitelist-based, HTML5-parsing library is a defensible control for security reviews, pen-test remediations, and SOC 2 / ISO questionnaire answers ("how do you sanitize user content?").
• Scope of the trust boundary. Whitelist configuration is a product decision, not just a technical one: which tags/attributes product actually promises (bold/links/images vs. embedded media vs. inline styles) maps directly to editor capabilities, moderation policy, and rendering fidelity commitments.
• Buy-vs-migrate sequencing. Because the specific package is archived, the real decision is "sanitization as a capability" (endorse) plus "which implementation" (do not endorse this one long-term). That shapes whether the team budgets a spike now or defers.
• Vendor/dependency policy precedent. Adopting or rejecting an archived security library sets the standard your dependency-review process applies to the next one.

When to Consider This Package

Consider the capability (whitelist-based HTML5 sanitization in PHP) whenever:

• You render HTML authored by users, customers, or third parties anywhere in a Laravel app — including stored content re-displayed later, not just request-time echo.
• You need to preserve safe markup rather than escape everything into visible tags (i.e., rich text is a requirement, not a nice-to-have).
• You want declarative, reviewable policy ("these tags, these attributes, these URL schemes") that security and product can both read, instead of imperative string munging.
• You need consistent behavior across malformed/adversarial input — HTML5 parsing rather than regex is the differentiator.

Consider this specific package only in narrow, time-boxed circumstances:

• An existing app already depends on it and a migration is scheduled; keep it pinned short-term rather than ripping it out mid-quarter.
• You are vendoring/forking with a named internal owner who will absorb security patches.

Look elsewhere — and treat this as the default recommendation — because:

• It is archived with no release since December 2021. For a security control, unmaintained is a disqualifier: no fixes for newly discovered parser bypasses, no PHP-version support guarantees, no CVE response path. Your team becomes the maintainer by default.
• It has a maintained successor. The library was upstreamed as symfony/html-sanitizer, which is actively developed, framework-agnostic, and usable from Laravel via Composer (no Symfony app required). For new work, that is the correct buy.
• Laravel-native alternatives exist (e.g., a mews/purifier-style HTMLPurifier wrapper) if you prefer an established Laravel-facing integration and stricter-than-HTML5 policy defaults; HTMLPurifier is slower but battle-tested and still maintained.
• You need zero user HTML. Blade's {{ }} escaping plus a Markdown renderer with HTML disabled already covers you — do not add a sanitizer dependency you don't need.
• You need CSS-level isolation or iframe sandboxing (e.g., full email-client rendering, embedded third-party widgets) — sanitization is necessary but not sufficient; scope that separately.

Note this package ships a Symfony bundle, not a Laravel service provider; in Laravel you'd wire it yourself (singleton binding, a validation rule, a Blade directive). Trivial work, but it is your code to own — and more code to own around a dependency nobody else is patching.

How to Pitch It (Stakeholders)

For executives (one paragraph): We need to render customer-authored rich text — comments, listings, templates — and that is a well-known cross-site-scripting surface. The right answer is a policy-driven HTML sanitizer rather than custom code; hand-rolling it is slow, hard to review, and chronically under-tested. The specific library reviewed here is well designed and was the reference implementation for this problem in PHP, but it is archived with no releases since 2021, which is unacceptable for a security control. Recommendation: endorse the capability, reject this package for new work, and standardize on its actively maintained successor (symfony/html-sanitizer). Cost is one dependency plus roughly 1–2 engineering days of integration and policy configuration; the alternative — a bespoke sanitizer or an unpatched dependency — carries materially higher incident and audit risk than the integration cost.

For engineering: Treat this as a capability decision with an implementation correction. The architecture worth copying is sound: HTML5-compliant parse tree, whitelist of elements/attributes/URL schemes, extension points for project policy, URL and inline-handler filtering. Build to that shape — declarative, version-controlled policy config reviewed like code, a single sanitization service at the render boundary (not scattered strip_tags calls), applied on output as well as input, plus tests with a corpus of known XSS payloads. But implement it on symfony/html-sanitizer: same lineage, actively maintained, Composer-installable in Laravel, no Symfony application required — bind it as a singleton, expose a validation rule and a Blade directive, and translate the whitelist into one config file. If any code currently depends on tgalopin/html-sanitizer, pin it, open a migration ticket with a named owner, and budget a day or two; the APIs are close enough that this is a mechanical port, not a rewrite. Do not fork the archived library unless someone is explicitly funded to own security patches — and if that's the plan, say so out loud, because "we forked the security library" is a decision leadership should hear.