Html Sanitizer Bundle Laravel Package

Product Decisions This Supports

• Content-safety roadmap for user-generated content (UGC). The underlying HTML sanitizer is the decision-relevant artifact: it determines whether we can safely accept rich text (comments, profiles, support tickets, CMS bodies, marketplace listings) without building our own allow-list engine. Release 1.4.0's addition of the details extension directly expands the set of safe, permitted markup — enabling <details>/<summary> collapsible blocks, which is a recurring product request for FAQ, changelog, and long-form content surfaces.
• Framework lifecycle planning. The Symfony 6 support addition is a compatibility signal, not a feature. Treat it as evidence the maintainer tracks supported framework majors, which feeds our dependency-upgrade roadmap and our risk scoring for this dependency.
• Build vs. buy. This remains a "buy/adopt" decision: sanitization is a security-critical, adversarial-input problem where a mature, allow-list-driven library beats in-house regex/filter code. The release contains no API churn, so the cost of staying on this package stays low.
• Operational configurability. The env-override fix for the key means sanitizer profiles/extensions can now be toggled per environment. That supports a concrete decision: ship new markup permissions (like the details extension) dark in staging, validate rendering and downstream consumers (search indexing, email digests, RSS, mobile clients), then enable in production without a code deploy.
• Deployment hygiene. The missing-return-type deprecation fix reduces log noise and future-proofs us against the next PHP minor's deprecation-to-error promotions — relevant to our "keep dependencies upgrade-clean" policy.

Important scoping note: this release is for tgalopin/html-sanitizer-bundle, a Symfony bundle, not a Laravel package. If the intent is Laravel adoption, the correct artifact is the underlying tgalopin/html-sanitizer library consumed directly (or via a thin Laravel service-provider/config wrapper we own). The PM decision differs accordingly: do not plan to install this bundle in a Laravel app. Treat this assessment as coverage of the sanitizer ecosystem we depend on, and as an early-warning signal for the underlying library's direction.

When to Consider This Package

Adopt (the sanitizer library directly, or this bundle if we are on Symfony) when:

• We accept untrusted HTML from users or third parties and cannot rely on a WYSIWYG alone — sanitization must happen server-side, defense-in-depth.
• We need a configurable allow-list rather than a blunt strip-all or escape-all approach, because product requires preserving legitimate formatting (links, lists, emphasis, and now collapsible <details>).
• We want named sanitizer profiles (e.g. comment, article, email_preview) so different surfaces can permit different markup without duplicated config.
• We need per-environment behavior for rolling out new markup permissions — the 1.4.0 env-key fix makes this practical.
• We are on Symfony 6 (or a PHP version aligned to it) and want maintained compatibility rather than pinning to an EOL major.

Look elsewhere when:

• We are a Laravel codebase. Don't pull in a Symfony bundle; use the standalone sanitizer library or a Laravel-native alternative, and budget a small wrapper + config file as our own code.
• Sanitization is not actually the risk — if all rich text is rendered as plain text or via a strictly typed markdown pipeline, a sanitizer is redundant surface area.
• We need sanitization at render time in the browser as the primary control; server-side sanitization remains necessary regardless, so this doesn't replace the package so much as complement it.
• We require a vendor with commercial SLAs or a security response commitment — this is community-maintained; if our threat model demands contractual guarantees, evaluate a commercial alternative or plan to vendor/fork.

How to Pitch It (Stakeholders)

For executives: We rely on a small, well-scoped open-source component to clean user-submitted HTML before it reaches other users. The latest version (1.4.0) is a low-risk, additive release: it (a) lets us safely support a new formatting capability — collapsible <details> sections — that has been requested for long-form content, (b) adds compatibility with Symfony 6 so we aren't stranded on an unsupported framework version, and (c) fixes two small hygiene issues. There are no breaking changes, so upgrade cost is minimal and there is no user-facing risk. One clarification worth knowing: this particular package is a Symfony bundle; if we proceed on Laravel, the equivalent work is a thin internal wrapper around the underlying sanitizer library — a small, contained engineering task, not a new vendor relationship.

For engineering: Non-breaking minor. Two items of substance: the details extension must be registered explicitly per profile, so enabling it is a deliberate config change — roll it out behind the env-based key override (also fixed in this release) and verify downstream consumers (search indexing, feeds, email rendering, mobile webviews) tolerate the new tags. Framework support moves to Symfony 6; confirm our PHP version and any transitive Symfony constraints before bumping. The return-type fix clears a deprecation that would otherwise become noise or an error on a future PHP upgrade. Recommended action: upgrade in a low-traffic window, add <details>/<summary> to the sanitizer test fixtures, and confirm no consumer treats unknown tags as plain text. If the target application is Laravel, scope a wrapper around the standalone library instead of installing this bundle.