- How do I install voku/anti-xss in a Laravel application?
- Run composer require voku/anti-xss and the library is available immediately. There is no service provider, facade, or config file to publish, so nothing needs registering in config/app.php. Instantiate \voku\helper\AntiXSS directly, or bind it as a singleton in a service provider if you want to reuse one instance. Check that your PHP version satisfies the requirement of the release you pin.
- Does voku/anti-xss work with Laravel 9, 10, 11 and 12?
- Yes. The package is framework-agnostic PHP with no Laravel-specific dependencies, so it works with any Laravel version that satisfies its PHP requirement. Laravel upgrades do not change the AntiXSS API; only your PHP version and the Composer constraint matter. If a constraint conflict appears, run composer why-not voku/anti-xss to see which package is holding it back.
- Should I use AntiXSS instead of Blade's double curly brace escaping?
- No. Blade's {{ }} escaping should stay the default for all user content. AntiXSS is a complement for the narrow cases where you must render raw HTML, such as WYSIWYG editor output, user-supplied templates, or legacy content migrations, typically echoed with {!! !!}. Treat it as defense in depth on top of output encoding, not as a replacement for it.
- How do I clean WYSIWYG HTML before rendering it with {!! !!} in Blade?
- Instantiate AntiXSS once, for example through a container binding, and pass the stored HTML through xss_clean() immediately before echoing it. Output only the returned string with {!! !!}. Sanitize at render time rather than only on input, so that filter updates and patches apply to content that is already stored.
- What was the security issue fixed in voku/anti-xss 4.1.45?
- Versions before 4.1.45 failed to encode tags where a tab, carriage return, line feed, or form feed separated the tag name from the rest, so payloads such as a style tag followed by a tab passed through as raw markup. An unclosed raw style tag then allowed CSS injection through @import or url() exfiltration and swallowed the rest of the page. Any surface that passes attacker-influenced HTML to xss_clean() should be pinned to at least 4.1.45.
- How do I force voku/anti-xss 4.1.45 or higher when it is a transitive dependency?
- Add a direct requirement in your root composer.json, for example "voku/anti-xss": "^4.1.45", and run composer update voku/anti-xss. If another package caps the version, use a Composer resolution override or an alias, then confirm with composer show voku/anti-xss that the lockfile resolves to the patched line. Repeat the audit on every service, including those where the package is only pulled in indirectly.
- How should I test XSS sanitization in Laravel with PHPUnit or Pest?
- Write feature tests that submit known payloads to your endpoints and assert the response contains encoded markup rather than executable tags. Add regression fixtures for the whitespace bypass cases, including tags separated by tab, CR, LF, and FF, so a future upgrade or downgrade is caught automatically. Also assert that legitimate HTML still renders as expected, so you notice over-sanitization before users do.
- Does voku/anti-xss add meaningful overhead on high-traffic pages?
- The filter is regex and string based, so cost scales with input length and is negligible for typical comment, profile, and form payloads. Avoid re-cleaning the same large HTML block several times per request; clean once and cache the result when the content does not change. For unusually large documents, benchmark before assuming the cost is irrelevant.
- What are the alternatives to voku/anti-xss for sanitizing HTML in Laravel?
- HTML Purifier and tgalopin/html-sanitizer, or Symfony's HtmlSanitizer component, offer configurable allowlists and are better suited when users need rich but restricted HTML. AntiXSS is lighter and simpler for blunt filtering of untrusted strings. Many teams run a configurable sanitizer plus Content Security Policy headers as the primary control and keep AntiXSS as an additional layer.
- Is voku/anti-xss actively maintained, and do I still need dependency scanning and CSP?
- The package is maintained and ships patch releases, but the 4.1.45 bypass shows that parser and whitespace edge cases recur, so treat it as a continuously patched dependency. Include it in dependency scanning and CVE alerting even when it is only transitive, and pin a minimum version. Pair it with Content Security Policy headers to limit the damage if sanitization ever fails.