Purify Laravel Package

Product Decisions This Supports

• Shipping user-generated content (UGC) faster. Use this package when comments, posts, profiles, support tickets, CMS pages, or notification templates allow a limited subset of HTML. It provides an allowlist-based sanitization layer instead of relying on ad hoc regex or front-end-only cleaning.
• Build vs. buy. Sanitization is security-critical and easy to get wrong. Buying into HTMLPurifier via this Laravel wrapper avoids maintaining a custom HTML sanitizer, while MIT licensing keeps procurement and legal friction low.
• Security roadmap and compliance work. Centralized sanitization policy supports stored-XSS risk reduction, OWASP-aligned input handling, and audit evidence that user HTML is filtered before rendering.
• Per-surface content policy. Named configuration sets let product and security teams define stricter rules for comments and broader rules for long-form posts or CMS content. Dynamic configuration supports one-off exceptions without globally loosening policy.
• Rich-text editor rollouts. The package ships HTML5 definitions and documents custom definitions for editors such as Basecamp Trix. This reduces the integration work needed to support editor-generated markup, custom elements, and allowed attributes.
• Retroactive policy changes. The recommended “sanitize on the way out” approach, plus PurifyHtmlOnGet Eloquent casts, lets teams store raw content and tighten rendering rules later without a database migration or content rewrite.
• Multi-tenant or plan-based content rules. Different configurations can be selected by content type, tenant, or feature area, making it possible to vary sanitization policy without forking the sanitization implementation.
• Operational maintainability. Serializer caching and the purify:clear command give engineering a defined operational path when definitions or policies change. Caching can be disabled temporarily for debugging.
• Decision against scope creep. This package is not an editor, CMS workflow, markdown parser, CSP solution, or JavaScript-context encoder. Treating it as one component of a broader content-security strategy keeps product scope honest.

When to Consider This Package

Consider adoption when:

• The application is on Laravel 7+ and PHP 7.4+ and needs server-side HTML sanitization.
• Users can submit HTML through a WYSIWYG editor, rich-text comments, CMS fields, email templates, or imported content that will later be rendered in a browser.
• The product needs an allowlist policy for tags, attributes, and CSS rather than a blocklist or regex-based filter.
• Different content surfaces need different rules, or policy is expected to evolve after launch.
• The team wants Laravel-native ergonomics: facade usage, publishable config, named configuration sets, Eloquent casts, and an Artisan cache-clear command.
• The product can follow the “store raw, sanitize on render” pattern and wants the ability to re-sanitize historical content under new rules.
• The team is comfortable pinning a Composer dependency and testing policy changes as part of release management.

Look elsewhere or reconsider when:

• Content is plain text only. Laravel’s escaping and proper output encoding are simpler and safer than introducing HTML sanitization.
• The need is client-side sanitization, a full CMS/editor workflow, markdown parsing, or rich-text collaboration. Pair this package with the appropriate editor or parser rather than expecting it to provide those capabilities.
• The product requires sanitization outside HTML contexts, such as JavaScript injection points, URL schemes in application logic, or file upload safety. Those need separate controls.
• The team cannot accept the maintenance profile of a community package with a small maintainer footprint and modest ecosystem signals. In that case, evaluate HTMLPurifier directly or a commercially supported alternative.
• Performance testing shows HTMLPurifier is too slow for the specific workload and caching does not sufficiently mitigate it. Large-scale or very high-throughput rendering may need a different architecture.
• The organization requires vendor SLAs, formal security certifications, or guaranteed release cadence that this package does not provide.
• The application falls outside the stated Laravel/PHP requirements or cannot absorb the configuration and cache-management overhead.

How to Pitch It (Stakeholders)

For executives: This is a low-cost, MIT-licensed security control for any feature that lets users submit HTML. It reduces the risk of stored XSS, which can lead to account takeover, data exposure, SEO spam, and reputational damage. Adopting a proven sanitizer is cheaper and more defensible than building one internally, and it lets product teams ship comments, posts, CMS pages, and rich-text features with a clearer security posture. The tradeoff is modest integration and policy-management effort, not license cost.

For engineering: stevebauman/purify is a thin Laravel wrapper around the long-standing HTMLPurifier library. It provides a facade, publishable config, named configuration sets, dynamic per-input configuration, Eloquent casts for sanitize-on-get or sanitize-on-set, HTML5 and custom definition support, CSS definition overrides, serializer caching, and a purify:clear command. The recommended pattern is to store raw content and sanitize on render, which allows policy changes to apply retroactively. It is not a replacement for output encoding, CSP, authorization, or upload scanning; it is the HTML sanitization layer in a broader content-security design.

Recommendation: Approve a short adoption spike: install the package, define two policy profiles (for example, strict comments and broader long-form content), add the Eloquent cast to one model, write XSS regression tests, and document the cache-clear step for definition changes. Pin the version, include policy changes in security review, and reassess if the feature becomes business-critical enough to require commercial support.