Bot Shield Laravel Package

Product Decisions This Supports

• Build vs. buy for edge hardening on Livewire surfaces. v1.2.0 extends the package from user-agent heuristics to request-shape validation: forged array-to-scalar prop updates, non-identifier method calls, and self-mutating reactive props are now classified and handled separately from legitimate errors. This is the kind of narrow, framework-aware logic that is expensive to build and maintain in-house, making the package a plausible buy for teams with public Livewire forms.
• Exception-noise reduction as a product/ops investment. The new detector-gated rules suppress expected attack noise (SQL injection probes via forged calls, malformed array payloads) while preserving reports for genuine developer mistakes — e.g. a typo in a real method name still reports, and a component mutating its own reactive prop still reports. That distinction directly affects alert fatigue, Sentry/error-tracker spend, and on-call quality of life.
• Security posture and incident triage. Because suppressed exceptions answer a client error "whatever the user agent," the package now provides a consistent response for forged requests independent of spoofable headers. This supports product decisions about how aggressively to reject malformed Livewire traffic versus log-and-continue.
• Roadmap sequencing for Livewire upgrades. The release is explicitly tied to Livewire internals (MethodNotFoundException, CannotMutateReactivePropException, reactive prop snapshots). Adopting it creates a compatibility surface that should be considered when planning Livewire major upgrades or component refactors.
• Feature-level risk acceptance. Each new rule is individually toggleable or addable via published config, which lets a PM/eng pair decide per-surface (e.g., public marketing forms vs. authenticated admin panels) how strict to be without forking the package.
• Release-readiness gating. The upgrade note reveals a real operational trap: published exceptions.rules replace defaults rather than merge, so existing installs silently do nothing new until config is edited. This is a product decision about default behavior vs. explicit opt-in, and it must be scheduled as a deployment task, not assumed.

When to Consider This Package

Consider adoption when:

• The application is Laravel + Livewire and exposes Livewire components to unauthenticated or low-trust users (public forms, wizards, onboarding, lead capture).
• You are already seeing forged or malformed Livewire requests in logs — array-to-scalar prop mismatches, SQL-injection-shaped method names, reactive prop mutation attempts — or you expect them once you start looking.
• Error-tracker noise from bot/probe traffic is materially affecting on-call or alert budgets, and you want framework-aware suppression rather than blunt regex filters.
• You need response consistency for forged requests regardless of user agent, and you are comfortable with the package returning client errors for matched classes.
• You can own the config lifecycle: publishing config/bot-shield.php, reviewing rule lists on each upgrade, and adding explicit env toggles (e.g. forged_updates) so behavior can be disabled without code changes.

Look elsewhere or defer when:

• The app is not Livewire-based, or Livewire is used only behind authentication with trusted clients — the new rules target shapes that primarily arise from tampering.
• You need WAF/edge-level protection (rate limiting, IP reputation, bot scoring). This package complements, but does not replace, an edge WAF or Laravel's own throttling.
• You cannot commit to reviewing published config on upgrade. The "published rules replace defaults" behavior means the security value of v1.2.0 is opt-in for existing installs; teams that treat config as fire-and-forget will not get the new protections.
• You require vendor-independent exception handling with no coupling to Livewire internal exception classes. The new rules import Livewire\Exceptions\MethodNotFoundException and Livewire\Features\SupportReactiveProps\CannotMutateReactivePropException, so Livewire version changes are a maintenance consideration.
• You need per-request observability of suppressed events. The release describes suppression and client-error responses; if audit trails of blocked probes are a hard requirement, confirm logging behavior before adoption.

How to Pitch It (Stakeholders)

For executives: This release tightens a security layer we can buy rather than build. It detects tampered Livewire requests — malformed data, injection-style method calls, unauthorized prop mutations — and stops them from polluting our error tracking, while still surfacing genuine bugs. The business case is reduced on-call noise, consistent rejection of probe traffic, and avoided engineering time maintaining bespoke framework-internals logic. The cost is a config review on upgrade, not a re-architecture.

For engineering leads: v1.2.0 makes the exception rules detector-gated and condition-aware. New when conditions (ForgedMethodName, ForgedReactivePropUpdate) let rules fire only when both the exception class and the request shape match, which is materially better than string-matching alone. The critical operational detail: a published exceptions.rules list replaces package defaults, so existing installs must add the new rules explicitly, and forged_updates must be added to the exceptions block if we want the ability to disable it via BOT_SHIELD_FORGED_UPDATES=false. Treat the upgrade as a config change with a review step, not a composer bump.

For security reviewers: The package is defense-in-depth for Livewire request integrity, not a WAF. It rejects forged array updates, non-identifier method calls, and self-targeted reactive prop mutations with client errors regardless of user agent, while preserving reports for legitimate typos and legitimate self-mutation. Confirm that suppressed events are still observable in logs or metrics if auditability is required, and pin/review the Livewire exception class imports on each Livewire upgrade.