Product Decisions This Supports
- Safe rich-content display in admin panels: If the product needs to render admin-authored or third-party HTML (announcements, CMS snippets, email previews, policy text, support macros) inside Nova, this field gives a vetted rendering path without us hand-rolling sanitization.
- Build vs. buy on XSS hardening: HTMLPurifier is a mature, well-understood sanitizer. Adopting a thin Nova field wrapper is materially cheaper than maintaining our own sanitize-and-render component, and it keeps the security-critical logic in a library rather than our codebase.
- Feature velocity for internal tooling: Pre-compiled assets mean no npm/Vite pipeline changes in the Nova app — lowers the cost of shipping admin-facing content features and reduces coupling to our frontend build.
- Roadmap enabler: Supports use cases like templated notifications preview, "what the customer will see" rendering, and read-only HTML policy/terms display. Dynamic
html() closures let us render computed content (e.g., resolved placeholders, localized strings) at display time rather than persisting rendered markup.
- Conditional disclosure:
when()/unless() lets us gate sensitive or role-specific content without extra authorization plumbing in the resource class — useful for tiered admin roles.
- Configuration escape hatch: Custom purifier config signals we can tighten or relax the sanitizer profile per deployment instead of forking the package.
When to Consider This Package
Adopt when all of the following hold:
- The admin surface is Laravel Nova 4 or 5, on Laravel 10+ and PHP 8.1+ (check our minimum-supported-version policy — 8.1 is already near end of life, so confirm our floor).
- We need to render arbitrary or semi-trusted HTML in the Nova UI, not just plain text or Markdown.
- We accept HTMLPurifier's output model: it sanitizes toward a conservative, standards-compliant subset. Content relying on inline styles, embeds, iframes, or heavy JS-driven widgets will be stripped unless explicitly configured.
- The content is display-only in the admin; this is not an editor or a WYSIWYG.
Look elsewhere or build in-house when:
- The target is not Nova (Filament, plain Blade, Inertia) — the field abstraction buys us little.
- We need authoring capability (rich text editing, media embedding) — pair a dedicated editor with server-side sanitization instead.
- We require strict CSP / Trusted Types guarantees; HTMLPurifier sanitizes markup but is not a CSP substitute, and
html() closures accepting dynamic input deserve an explicit review.
- We need long-term vendor independence on a security-critical path — a single-maintainer wrapper around HTMLPurifier is a supply-chain consideration; we should be comfortable pinning and patching if upstream stalls.
Risk notes to track: v1.0.0 is a first release — no stability track record, no deprecation history, and the public API (content(), html(), when(), unless()) may still shift. Pin the version and avoid spreading its API across many resources until a maintenance cadence is visible. Also confirm that sanitization happens server-side, not just at render, and that html() closures are the only dynamic path — any user-supplied HTML passed to content() should be treated as untrusted regardless of the default.
How to Pitch It (Stakeholders)
Executives: A small, low-cost dependency that lets our admin tooling safely display HTML content — announcements, policy text, customer-facing previews — without exposing internal users to script-injection risk. It removes a recurring security chore from our own backlog and speeds up delivery of admin content features. Cost is a single Composer package; the main caveat is that it is a young, v1.0.0 project, so we pin the version and keep the integration shallow.
Engineering: A Nova 4/5 field that renders HTML with HTMLPurifier sanitization on by default. Static content via content(), computed content via an html() closure, conditional visibility via when()/unless(), and a custom purifier config hook. Ships pre-compiled assets, so no build-step changes. Requires PHP 8.1+, Laravel 10+, Nova 4/5. Two asks: (1) verify sanitization is server-side and confirm behavior under our CSP; (2) treat html() closures as a trust boundary — no unsanitized user input should reach them. We should also decide whether an HTMLPurifier-based sanitizer is our sanctioned pattern across the product, so we don't end up with three different sanitization approaches.