Weave Code
Laravel Xss Protection Laravel Package
protonemedia/laravel-xss-protection
Laravel XSS Protection provides middleware and validation rules that sanitize user input to guard against cross-site scripting. It recursively cleans request data, supports custom filters, and integrates smoothly with Laravel forms and Blade templates.
Laravel XSS protection, middleware and sanitization
Frequently asked questions about Laravel Xss Protection
- How do I install and register protonemedia/laravel-xss-protection?
- Install it with Composer via composer require protonemedia/laravel-xss-protection, then publish the config file with php artisan vendor:publish. Register the middleware globally or on selected route groups: in app/Http/Kernel.php on Laravel 10 and earlier, or through the bootstrap/app.php middleware API on Laravel 11 and newer. The wiring itself takes hours, but plan days for validation because enumerating every input surface you must exclude is the real work.
- Which Laravel and PHP versions does laravel-xss-protection support?
- Release 1.11.0 adds a Laravel 13 compatibility claim, and the constraint appears to span roughly Laravel 9 through 13 on PHP 8.1 and above. Confirm in composer.json that this is a union constraint rather than a narrowed range, and check that the PHP floor did not move. Also verify whether the Laravel 13 claim reflects real CI coverage across the full matrix or just a constraint bump from automated compatibility PRs.
- Does the middleware sanitize nested arrays and JSON request bodies?
- The package recursively cleans request data, so nested form-encoded arrays are handled. However, it is not clear from the surface whether it rewrites only $request->all(), or also the Input facade, validated data, and application/json bodies. Write tests against raw JSON payloads and against FormRequest validated() output before you rely on it, especially if your API accepts nested JSON.
- What sanitizer engine does it use, and can I customize the filters?
- It relies on an HTMLPurifier-family sanitizer, which is CPU- and memory-intensive per request. The package supports custom filters, so you can exclude or special-case fields such as rich-text editors, markdown, base64 uploads, and signed URLs. Tune the published config profile to your actual content types rather than accepting the defaults wholesale.
- Do I still need Blade escaping and a Content-Security-Policy if I use this?
- Yes. Input sanitization is defense-in-depth, not a substitute for contextual output escaping, a Content-Security-Policy, and secure cookie and header handling. Teams that treat this middleware as 'XSS solved' frequently regress elsewhere in the stack. Keep Blade's escaped output and layered headers in place.
- Will sanitizing input break rich-text or markdown content users submit?
- It can, because the package is destructive by design: it mutates data before persistence, and over-broad rules permanently alter user content at rest. That damage is not reversible with a config change, so you must enumerate and exclude rich-text editors, markdown fields, and other trusted payloads up front. Validate against real content samples in staging before enabling it on production forms.
- What is the performance impact on high-traffic Laravel endpoints?
- The underlying HTMLPurifier-family sanitizer is CPU- and memory-intensive per request, and the latency is measurable on high-throughput endpoints. Benchmark the p95 delta on a representative payload mix, and consider scoping the middleware to only the routes that accept untrusted HTML. Release 1.11.0 does not touch the sanitization path, so prior latency measurements remain valid.
- Is this package a good fit for an API plus SPA or Inertia application?
- It is a weaker fit for headless API plus SPA architectures, where the primary XSS controls should already be correct output encoding and a Content-Security-Policy. Sanitizing inbound JSON is largely redundant when rendering is properly escaped. The Inertia Modal reference added in 1.11.0 is a documentation-level improvement and does not change that threat-model calculus.
- How should the middleware be ordered relative to TrimStrings, ConvertEmptyStringsToNull, and signature verification?
- The package documentation does not settle this, so treat ordering as something you must verify in your own stack. Signature verification, such as Stripe or GitHub webhooks, must see the raw request body before sanitization mutates it, or verification will fail. Test the full pipeline order with TrimStrings, ConvertEmptyStringsToNull, and any webhook middleware enabled.
- Is laravel-xss-protection actively maintained and safe enough for production?
- Signals are mixed: roughly 150 stars, zero dependents, and single-maintainer provenance from Protonemedia indicate limited independent production validation. Release 1.11.0 shows activity, but one change landed via laravel-shift automation and the other was a documentation-level Inertia addition, neither touching the sanitizer core. The codebase is small enough to fork if needed, but automated compatibility PRs are a maintenance floor rather than evidence of production hardening.
Weaver
How can I help you explore Laravel packages today?