Html Sanitizer Laravel Package

Product Decisions This Supports

• Feature: safe rich text and user-generated content. Use this package when a Laravel/PHP product accepts HTML from customers, editors, support agents, imports, APIs, or WYSIWYG fields and must render it without XSS risk. It supports explicit allow-lists for tags, attributes, and attribute values, making it suitable for comments, profiles, bios, CMS pages, ticket replies, email templates, and marketplace listings.
• Roadmap: security baseline for content surfaces. Treat HTML sanitization as a platform capability rather than a per-feature afterthought. A shared Laravel service/provider with named presets—comment, editor, email_preview, imported_html—lets product teams ship content features without re-litigating XSS rules each sprint.
• Build vs buy: buy the parser/security core, build the product policy. The package provides the sanitizer engine, visitor model, behavior presets, and serialization. The product still owns policy: which tags each role/tenant may use, which URL schemes are allowed, whether invalid markup is encoded or removed, and how sanitization events are logged.
• Use cases: sanitize on ingest and again on output for defense in depth; allow trusted editors broader HTML while restricting public comments; enforce mandatory attributes such as href on links; block javascript: and non-approved URI schemes; encode unexpected comments/tags instead of silently dropping content; support custom elements or legacy markup through closure handlers.
• Product UX decisions: flags such as ENCODE_INVALID_TAG and ENCODE_INVALID_COMMENT let teams choose graceful degradation over aggressive stripping. That affects how much user content survives moderation, imports, and legacy migrations.
• Risk decision: the package is security-sensitive infrastructure from the TYPO3 ecosystem, MIT-licensed, and agnostic to TYPO3 CMS. It has a small public adoption footprint (low stars/dependents), so the PM decision is not “Is it popular?” but “Do we want a narrow, security-maintained sanitizer with our own Laravel integration layer?”

When to Consider This Package

Consider it when:

• You need server-side HTML sanitization in PHP/Laravel for untrusted or semi-trusted HTML.
• You want an allow-list model with configurable tags, attributes, attribute-value rules, and URI schemes.
• You need multiple sanitization presets by role, tenant, content type, or trust level.
• You can accept a thin Laravel integration layer—service provider, config file, facade/helper, preset builders—rather than a Laravel-native API.
• You value security maintenance history: releases include XSS mitigations and security fixes; pin to a current patched version.
• You are comfortable with a small ecosystem footprint and will own integration tests, monitoring, and upgrade discipline.

Look elsewhere or complement it when:

• You need client-side sanitization; use a browser-side sanitizer as defense in depth, not as the only control.
• You need Markdown parsing, schema validation, or CSS sanitization; this package is not those tools.
• You require a large Laravel ecosystem package with community recipes and broad Packagist adoption.
• You need a fully managed WYSIWYG content policy; this package provides the engine, not the editorial policy or admin UI.
• Your team cannot absorb a security-critical dependency with low public dependents; in that case compare against HTMLPurifier, Symfony HtmlSanitizer, or a maintained Laravel wrapper, and document the trade-off.

How to Pitch It (Stakeholders)

For executives: We need a consistent way to render customer-supplied HTML without opening XSS holes. This package gives us an MIT-licensed, security-maintained PHP sanitizer with explicit allow-lists and configurable behavior. It is not a Laravel-first product, so we would wrap it in a small internal service and own our content policies. The business value is reduced security risk, faster delivery of rich-text features, and a reusable platform capability rather than repeated one-off regex fixes.

For engineering: Adopt it as a narrow security component, not as an application framework. Build a Laravel service provider, config presets, and tests around representative payloads. Pin versions, track security releases, sanitize both on ingest and render, and log sanitization outcomes. The package’s Behavior/visitor/builder model is flexible enough for role- and tenant-specific policies, but it requires deliberate configuration and upgrade testing. The low star/dependent count is an adoption-risk signal, not a functional blocker; mitigate it with internal ownership and a fallback comparison against alternatives.