Laravel Xss Protection Laravel Package

Product Decisions This Supports

• Security hardening roadmap / pen-test remediation. Gives you a single, global choke point that sanitizes inbound request input (query string, form body, JSON) before it reaches controllers and models. Useful as a fast, low-effort mitigation for a stored-XSS finding, an OWASP ASVS gap, or a customer security questionnaire item — typically a one-sprint change rather than a multi-team refactor.
• Build vs. buy for a common utility. A request-sanitizing middleware is ~50–100 lines you could write in-house. Buying (MIT-licensed, free) buys you a maintained sanitizer integration, a config surface for skip-lists, and a test suite you don't have to own. The real decision is not cost — it's who maintains the sanitizer rules and whether you want that to be a dependency or your own code. The 1.11.0 release (Laravel 13.x compatibility) is a small but concrete data point that the maintainer is still tracking framework releases.
• Feature enablement for user-generated HTML. If the roadmap includes WYSIWYG comments, rich-text descriptions, CMS pages, email templates, or admin-editable content, this package lets you ship those features with a defensive layer while you decide on a proper output-encoding/sanitization policy.
• Legacy and acquired-codebase triage. Highest value in apps that render unescaped output ({!! !!} in Blade), inherited code with unknown escaping discipline, or apps that store raw payloads from third-party integrations. In those contexts it is a cheap blanket control that buys time for a targeted fix.
• Scope-setting for adjacent work. Adopting it forces an explicit conversation about where sanitization belongs (input boundary vs. write-time vs. render-time), which directly informs decisions on CSP headers, WAF rules, and Form Request validation strategy — and prevents the team from treating this middleware as a substitute for them. The Inertia modal-link handling added in 1.11.0 is a useful illustration of why that conversation matters: framework/frontend conveniences that pass URLs and structured data through query parameters need explicit carve-outs from a global sanitizer.

When to Consider This Package

Adopt when:

• You are on a supported Laravel version — 1.11.0 explicitly adds Laravel 13.x support, so current LTS/current-release apps are covered — and you can register global or group middleware without disrupting existing request pipelines.
• The application stores or renders user-supplied HTML/markup anywhere — WYSIWYG fields, CMS content, imported data, or API responses that clients render as HTML.
• You need a fast, uniform control across many endpoints rather than auditing every controller individually (typical of legacy or inherited code).
• You have compliance or customer-driven requirements that demand demonstrable input-sanitization controls, and you want a documented, configurable mechanism rather than ad-hoc regexes.
• You use Inertia (or are planning to) and want a package that has already accounted for Inertia modal links in its handling rather than one you'd have to patch on day one.
• You can articulate what it does not cover and pair it with output encoding (Blade {{ }}), CSP, and validation.

Look elsewhere or skip when:

• Your app only emits through Blade auto-escaping or JSON consumed by clients that escape correctly — the marginal risk reduction is small relative to the integration and performance cost.
• You operate high-throughput or large-payload APIs. Sanitizing every request has CPU and memory cost proportional to payload size; per-endpoint or write-time sanitization is cheaper and more precise.
• You need context-aware sanitization (HTML body vs. attribute vs. URL vs. JS context) or different policies per field/tenant. A single global middleware tends to over-sanitize legitimate input and under-sanitize the contexts that matter; output-time encoding or a domain-level sanitizer is the better architecture. URL-bearing query parameters (deep links, Inertia modal URLs, redirect targets) are a recurring example of where a blanket policy is the wrong instrument.
• Requests must arrive byte-identical: webhook signature verification (Stripe, GitHub, Shopify), HMAC-signed payloads, encrypted blobs, or idempotency-keyed bodies. Mutating input before verification will break these — you would need a carefully maintained skip-list, which is a recurring maintenance liability.
• Strict schema validation (Form Requests, DTOs) is the intended control. Sanitizing silently mutates data and can mask validation failures; many teams prefer to reject invalid input than silently clean it.
• Dependency-risk tolerance is low. Signals here remain thin: ~150 stars and effectively no downstream dependents in the data provided, which means a small bus factor and limited community validation. The 1.11.0 release is a positive maintenance signal, but two external contributions do not materially change the bus-factor math. For a security-critical control, weigh that against your appetite for forking or vendoring it.
• You need guarantees a middleware can't give — e.g., sanitizing data already in the database, or protecting non-HTTP ingress paths (queues, imports, scheduled jobs).

Due diligence before committing: confirm the underlying sanitizer and its configuration surface, measure the latency impact on your largest realistic payloads, verify behavior with file uploads and nested JSON, verify behavior on Inertia/SPA routes and any URL-bearing query parameters, and decide explicitly which keys are skipped.

How to Pitch It (Stakeholders)

To executives: This is a free, MIT-licensed middleware that adds a defensive layer against cross-site scripting — one of the most common web vulnerabilities and a recurring line item in security audits and enterprise procurement reviews. Integration is measured in hours, not sprints, and it reduces the blast radius of a whole class of bugs without changing product behavior. The latest release keeps it compatible with Laravel 13.x, so it will not become orphaned by our framework upgrade. It is insurance, not a cure: it complements our existing escaping and security headers rather than replacing them.

To engineering: One Composer dependency plus a middleware registration; the package sanitizes inbound query, form, and JSON input and exposes a config skip-list. Version 1.11.0 adds Laravel 13.x compatibility and Inertia modal-link handling — the latter matters because it shows the package is already aware that URL-shaped query parameters must not be treated like prose. Treat it as defense-in-depth at the request boundary, not a substitute for output encoding — Blade auto-escaping and correct JSON handling remain the primary control. Known constraints to design around: it mutates request payloads (so exclude webhook/signature-verified routes), it adds per-request cost proportional to body size (benchmark before enabling globally on high-traffic endpoints), and it applies one policy globally rather than per-context. Adoption signal is still modest (small star count, few dependents), so plan to pin the version — 1.11.0 is a reasonable floor for Laravel 13 apps — review the sanitizer config, and be prepared to vendor or replace it if maintenance stalls.