- Can I install tgalopin/html-sanitizer-bundle in a Laravel application?
- No. It is a Symfony bundle with no service provider, facade or publishable config, so its service definitions simply will not load in Laravel. Require the underlying tgalopin/html-sanitizer (or symfony/html-sanitizer) library instead and bind a configured sanitizer in your own service provider. The bundle is only a thin dependency-injection and configuration layer over that library.
- How do I use tgalopin/html-sanitizer in Laravel to clean untrusted user HTML?
- Install the library with Composer, build an HtmlSanitizer instance from your chosen extensions and allowed elements, and register it as a singleton in a small SanitizerServiceProvider. Inject an interface wherever you render or persist untrusted markup, and sanitize on write so stored data stays clean. Read allowlists from config/sanitizer.php rather than hard-coding them in controllers or Blade templates.
- Which Laravel and PHP versions does the sanitizer support?
- The library works wherever its own PHP constraint and dependencies such as symfony/css-selector and masterminds/html5 fit, typically PHP 8.1+ with Laravel 9, 10 or 11. Check the sanitizer version pinned by the bundle's latest release against your Laravel Symfony component pins before installing. The bundle's own Symfony framework constraints are irrelevant to a Laravel install.
- Is tgalopin/html-sanitizer still maintained or effectively deprecated?
- The upstream tgalopin line has largely been superseded by symfony/html-sanitizer, and the bundle reaching Symfony 6 support only in 1.4.0 suggests reactive rather than proactive maintenance. This does not break existing installs, but you should plan an exit path. Keep sanitizer construction behind an interface so the implementation can be swapped without touching call sites.
- tgalopin/html-sanitizer vs symfony/html-sanitizer: which should a Laravel app use?
- symfony/html-sanitizer is the actively developed successor and a reasonable default for new projects, while tgalopin/html-sanitizer is fine if you already depend on it. Both expose a similar wither-style configuration API, so migration is mostly mechanical. Whichever you choose, wrap it behind your own interface so the decision stays reversible.
- How do I configure different sanitizer profiles per environment?
- Keep allowlists in config/sanitizer.php and let Laravel's env overrides drive per-environment differences instead of editing config files per deploy. Note that bundle 1.4.0 changed config-key precedence for env overrides; if you replicate that pattern yourself, the precedence is entirely yours to define. Document it so staging and production cannot silently diverge.
- How do I write XSS regression tests for sanitized HTML?
- Build a golden-file corpus of representative and malicious payloads: script tags, event handlers, javascript: URLs, mutation XSS, and every element your allowlist permits. Assert on sanitizer output byte-for-byte so any allowlist or extension change shows up as a diff. Run the suite in CI and extend it whenever you enable something new, such as the details extension's open attribute and nested summary content.
- Does the details extension introduce new XSS vectors?
- It expands the allowed-markup surface, and the open attribute plus nested summary content are new vectors you should validate. Fuzz those cases and confirm injected attributes are stripped rather than passed through. If you do not actually need collapsible sections, leave the extension disabled.
- What is the migration path from strip_tags or HTMLPurifier to a proper sanitizer?
- Inventory every sanitization call site, including strip_tags, htmlspecialchars on trusted-HTML fields, HTMLPurifier usage and Blade {!! !!} sinks, and classify each as a read path or a write path. Migrate write paths first so stored data is clean, then read paths. Run the old and new sanitizers in parallel in log-only mode for about a week and diff the output before cutting over.
- Do the 1.4.0 return-type and deprecation fixes matter on PHP 8.1?
- Those fixes only matter if you install the bundle, which you should not do in a Laravel app. They do signal that the upstream sanitizer API is stabilising on modern PHP, which is useful maintenance signal. If your CI treats E_DEPRECATED as an error, test the library version you actually pin instead of assuming the fix applies.