Weave Code
Html Sanitizer Laravel Package
typo3/html-sanitizer
A standalone PHP HTML sanitization component from TYPO3, usable in any PHP project. Declarative Behavior settings define allowed tags, attributes, and values; visitors modify or remove nodes; builders combine presets into ready-to-use Sanitizer instances for safe HTML output.
TYPO3 HTML Sanitizer is a standalone PHP component for cleaning untrusted HTML, usable by any PHP project regardless of TYPO3 CMS. It separates concerns: a declarative Behavior defines allowed tags, attributes, and values; pluggable Visitors inspect and modify or remove nodes; the Sanitizer parses and serializes HTML using those rules.
- Declarative, immutable Behavior configuration for tags, attributes, and regex constraints
- Multiple concurrent Visitor implementations
- Builder presets (e.g.,
CommonBuilder) bundle behavior and visitors into a ready-to-use sanitizer - Built-in handling for comments, CDATA sections, and invalid markup encoding
- Framework-agnostic, installable via Composer
Frequently asked questions about Html Sanitizer
- How do I install typo3/html-sanitizer in a Laravel application?
- Run composer require typo3/html-sanitizer. There is no service provider, facade, or config file to publish, so you write a thin application service that builds a Sanitizer from a Builder preset and exposes a sanitize method. Before deploying, confirm the package PHP constraint against your app floor and make sure ext-dom and ext-libxml are present in the runtime image.
- Does typo3/html-sanitizer work with Laravel 10 or 11?
- The package is framework-agnostic and has no Laravel or TYPO3 CMS coupling, so it works with any Laravel release whose PHP version satisfies its Composer constraint. Check the package composer.json against your application PHP floor rather than assuming a Laravel version matrix. The only runtime prerequisites are the DOM and libxml extensions.
- How do I configure which HTML tags and attributes are allowed?
- You declare an immutable Behavior instance using withTags, withFlags, withNodes, and withoutNodes, describing allowed tags, attributes, and value constraints such as a RegExpAttrValue on href. Behavior\Attr also supports prefix matching like data- via NAME_PREFIX. Wrap that Behavior plus your visitors in a Builder preset so the rest of the app only asks for a ready-to-use Sanitizer.
- What is the difference between Behavior, Visitor, Sanitizer, and Builder in this package?
- Behavior is the declarative, immutable allow-list of tags, attributes, values, and encoding flags. VisitorInterface implementations do the actual work by modifying nodes or marking them for deletion, while Sanitizer orchestrates parsing, running visitors, and serializing output. BuilderInterface is a preset that composes a Behavior with visitors and returns a configured Sanitizer, which is the piece you typically register per rendering surface.
- How does typo3/html-sanitizer compare to HTMLPurifier or symfony/html-sanitizer?
- HTMLPurifier is mature and widely deployed but has a dated API, heavy configuration, and is slow; mews/purifier is just a Laravel wrapper around it. symfony/html-sanitizer is the strongest substitute, offering a similar config-object model with HTML5 parsing via masterminds/html5. typo3/html-sanitizer is MIT-licensed and dependency-free, but it parses with DOMDocument::loadHTML, so choose it when an HTML4-era parser is acceptable for your input.
- How do I test my sanitizer policy with PHPUnit or Pest?
- Test through the public API: build the Sanitizer from your preset and assert on the serialized output for representative payloads. Cover both directions of failure, meaning payloads that must be neutralized and legitimate user markup that must survive unchanged. Also cover your encoding flags, since ENCODE_INVALID_TAG and ENCODE_INVALID_COMMENT decide whether rejected markup becomes visible escaped text or disappears.
- Is typo3/html-sanitizer safe against mXSS and mutation XSS attacks?
- The library is built on PHP DOMDocument::loadHTML, and its advisory history, including CDATA and raw-text element XSS, noscript child encoding, comment end bang handling, and a raw-text bypass around ALLOW_INSECURE_RAW_TEXT, all traces back to that parser boundary. Each issue was patched, but the pattern means you should stay current and treat HTML5-accurate parsing as out of scope. Define a documented time-to-patch SLA for security releases and keep the package pinned and monitored.
- Can I reuse one Sanitizer or Behavior instance as a singleton in Laravel?
- Behavior is immutable, so a compiled policy is safe to share as a singleton across the request lifecycle, and multiple distinct policies can coexist in one process without cross-contamination. That makes it easy to register one preset per surface, such as comments versus rich-text admin content. Instantiate or resolve Sanitizer objects through the container so each surface gets the right visitors.
- What are the system requirements for typo3/html-sanitizer?
- You need a PHP version matching the package Composer constraint plus the ext-dom and ext-libxml extensions. Standard PHP images include both, but slim or distroless containers sometimes strip them, which surfaces as a fatal error at runtime. Install with Composer and verify the extensions during your image build rather than at first sanitize call.
- Does typo3/html-sanitizer follow semantic versioning, and should I pin the version?
- Breaking changes have shipped on minor bumps: v2.1.0 and v2.3.0 both carry [!!!] markers, including the Sanitizer constructor now requiring a Behavior and visitors, and CommonBuilder->srcsetAttr was removed and then reverted in a patch. A ^2.0 constraint is therefore not a safe deployment guarantee. Pin to the minor version and treat minor upgrades as reviewable changes with a test run against your policy.
Weaver
How can I help you explore Laravel packages today?