Xss Middleware Laravel Package

Product Decisions This Supports

• Security hardening for existing Laravel surfaces. Justifies a low-effort, reversible layer over user-generated input (comments, forms, profile fields, search queries) while a longer-term sanitization strategy is scoped.
• Build vs. buy (vs. adopt). Provides a concrete "adopt an existing MIT middleware" option in the trade-off against building in-house input filtering, buying a WAF, or relying solely on framework defaults.
• Roadmap sequencing for rich-text and embed support. Forces an explicit decision on whether product will allow HTML, iframes, or third-party embeds (video, maps, widgets) and where sanitization belongs — this package's allow/deny behavior directly constrains those features.
• MVP and internal-tool scoping. Appropriate as a stopgap for low-exposure internal apps, prototypes, and admin panels where a lightweight global filter is "good enough" until a formal AppSec review.
• Compliance and questionnaire responses. Gives a defensible, documentable answer to "how do you mitigate XSS?" for security reviews, vendor questionnaires, and pen-test remediation tickets — with caveats noted.
• Incident response. A fast, single-middleware mitigation to ship during or immediately after an XSS finding, pending a root-cause fix.
• Risk acceptance / deprecation planning. Because adoption is near zero (5 stars, 0 dependents), it supports an explicit "tactical, time-boxed, replace-later" decision rather than a silent long-term dependency.

When to Consider This Package

Reasonable fit:

• Small or internal Laravel applications with no centralized input sanitization and no dedicated AppSec capacity.
• A tactical stopgap during incident response or before an audit, where speed matters more than architectural purity.
• Defense-in-depth as one layer alongside Blade output escaping, parameterized queries, and a Content-Security-Policy.
• Teams that explicitly want a global, framework-native middleware rather than per-controller validation, and can accept coarse-grained filtering.
• Products that intentionally disallow embed/iframe content and want that policy enforced uniformly.

Look elsewhere when:

• Rich text or user-authored HTML is a core feature. Global input filtering either strips legitimate content (silent data loss, support tickets) or is configured so permissively it stops helping; use a context-aware sanitizer (e.g., HTMLPurifier / Symfony HTML Sanitizer / mews/purifier) at render time.
• You need maintained, auditable dependencies. 5 stars, 0 dependents, and a single maintainer imply an unproven bus factor and no community security review. Prefer first-party framework features or widely adopted libraries for anything internet-facing.
• You have public APIs or client-supplied signed payloads. Mutating request input can break signature verification, idempotency, and contract tests; sanitize downstream instead.
• Stored-XSS and output-context risk dominate. Input-only filtering does not address data already in the database or context-specific encoding needs (attribute vs. script vs. URL). Output encoding and CSP remain mandatory regardless.
• High-traffic or latency-sensitive paths. Per-request recursive filtering of entire payloads is untested at scale here; benchmark before adopting.
• Regulated environments requiring vendor due diligence, SBOM provenance, or documented security ownership.

Adoption gate before merging: pin the version, review the middleware source (it is small enough to read in full), write regression tests for legitimate payloads (HTML, JSON, file uploads, encoded characters), confirm it does not interfere with JSON/API requests, and document the exit plan.

How to Pitch It (Stakeholders)

For executives (30 seconds): We have an option to add a free, MIT-licensed Laravel middleware that strips script, iframe, and embed payloads from incoming user input in one place. It is cheap to try, reversible in a single commit, and gives us a credible answer on XSS for security reviews while we design the durable fix. It is not a silver bullet: it is a small, low-adoption open-source component with one maintainer, and it does not replace output escaping, a Content-Security-Policy, or a real sanitization library for rich-text features. Recommendation: adopt as a tactical, time-boxed layer with tests and a named owner — not as our security strategy.

For engineering: One global middleware on the HTTP kernel, no schema or application-code changes, trivially revertible. Two costs to plan for: (1) it mutates request input, which can silently corrupt legitimate HTML/JSON and break signed or idempotent requests, and (2) it is an unmaintained-by-community dependency we would be effectively forking if it needs changes. Pair it with per-endpoint validation, output encoding, and CSP; add a test suite covering real product payloads before rollout; and treat rich-text/embed support as a separate sanitization decision at render time.

Ask: Approve a one-sprint spike to integrate behind tests, measure behavior against representative payloads, and return a build-vs-buy recommendation between this middleware, a vetted sanitizer, or framework-native controls.