Weave Code
Shield Laravel Package
laravel-shield/shield
Laravel Shield is a lightweight security middleware for Laravel that helps protect your application from malicious requests, bots, and abusive traffic. It provides configurable rules and filters so you can block unwanted requests before they reach your routes and controllers.
The core shield package.
Frequently asked questions about Shield
- What does laravel-shield/shield do?
- Laravel Shield is the core runtime package of the Shield family: a Laravel service provider plus middleware that intercepts inbound request input and sanitises or validates it before requests reach routes and controllers. The canonical pattern for this package family is XSS-oriented input sanitisation. It is a thin, single-purpose library with a publishable config file and Kernel-level middleware registration, and it has no persistence, queueing, or external service dependency.
- Which Laravel and PHP versions does laravel-shield/shield support?
- The last release was on 2017-10-31 and targets the Laravel 5.4/5.5 era, with constraints around illuminate/support 5.x and PHP 7.0/7.1. It will not satisfy the dependency constraints of Laravel 6+ or PHP 8.x. On modern applications, Composer resolution will fail or require version pinning hacks.
- Is laravel-shield/shield still maintained?
- No releases have been published in roughly seven years, and there are no upstream security patches. For a security-adjacent package, receiving no patches is an anti-control rather than a safety feature. Treat it as abandoned and check whether a maintained fork or successor exists before relying on it.
- How do I install laravel-shield/shield in a Laravel app?
- Historically, installation was composer require, publishing the config file, and registering ShieldMiddleware in app/Http/Kernel.php. Mechanically that is trivial, but the real constraint is dependency compatibility with Laravel 5.4/5.5 and PHP 7.0/7.1. On modern Laravel or PHP versions, installation turns into an unbudgeted compatibility project rather than a one-line setup.
- Does laravel-shield/shield work with Laravel 9, 10, or 11?
- No. The package constraints target the Laravel 5.4/5.5 era and PHP 7.0/7.1, so Composer will not normally resolve it on Laravel 9, 10, or 11 with PHP 8.x. For modern applications, treat the package as a reference implementation rather than a dependency.
- Is input sanitisation middleware the right way to prevent XSS in Laravel?
- Generally no. XSS is best handled at the output layer with Blade escaping using {{ }}, a Content Security Policy, and parameterised queries, not by globally mutating inbound input. Input sanitisation can corrupt legitimate payloads such as markdown, JSON APIs, rich text, base64, and trusted editor HTML, creating silent data-integrity defects. If raw input filtering is mandated, scope an allow-list sanitiser only to the specific fields that require HTML.
- What are good alternatives to laravel-shield/shield?
- For HTML filtering, use a maintained sanitiser such as mews/purifier or ezyang/htmlpurifier directly, with allow-list rules for specific rich-text fields. For general XSS defence, enforce Blade escaping and add a CSP header through Laravel middleware or your web server. If you need the Shield intent, reimplement the roughly 200 lines as a scoped middleware instead of adding the abandoned package to composer.json.
- What exactly does the laravel-shield/shield middleware change in the request?
- The package intercepts inbound request input and changes the shape of $request->all() globally, which is a broad blast radius because every request passes through it. It is unclear from the package overview whether it also touches json(), file uploads, headers, and route parameters. Confirm those details before using it, especially if any endpoint relies on raw input.
- Can laravel-shield/shield break webhooks, HMAC validation, payments, or JSON APIs?
- Yes, that is a serious risk. Input sanitisation can alter raw payloads, so consumers that rely on signed webhooks, HMAC validation, payment payloads, or exact JSON bodies may silently break. Avoid global sanitisation and test those endpoints carefully; if filtering is required, apply scoped middleware only to named routes that need it.
- What risks should I consider before using laravel-shield/shield in production?
- The technical risk is high: the package is abandoned, has no security patches, and has a bus factor of roughly one with no demonstrated production user base. It also carries correctness risk by sanitising at the wrong layer, plus transitive CVE exposure if it delegates to a 2017-pinned HTML sanitiser. It is only a reasonable fit for legacy Laravel 5.4/5.5 estates that have explicitly chosen input sanitisation at the edge as their security model.
Weaver
How can I help you explore Laravel packages today?