Laravel Crowdsec Laravel Package

Product Decisions This Supports

• Security posture & compliance roadmap. v1.7.0 adds a critical jndi_injection scenario (Log4Shell-style ${jndi:…} detection across inputs, headers, and User-Agent) plus broader header inspection. This turns "do we have baseline protection against known critical CVEs at the edge?" into a yes/no you can put on a security roadmap slide, rather than a bespoke engineering project.
• Build vs. buy for WAF/blocking. The package now covers WAF evasion hardening (multi-layer URL/%uXXXX/HTML-entity decoding, NUL bytes, SQL inline comments, NFKC fullwidth normalization), chunked-request size checks, and 64 KB chunked scanning of oversized bodies. That is a meaningful slice of "would we otherwise license a WAF or build one?" — the honest answer is this handles commodity attacks, not a full managed WAF.
• Access control and auditability decisions. The new viewCrowdSec / manageCrowdSec gates fix a real exposure (any logged-in user could block IPs and read raw security events). This is a pre-upgrade decision for the app team: they must define these gates, otherwise dashboard and API return 403 outside local. Also relevant to product: who inside the company is allowed to see raw security events (privacy/DPA implications).
• Data retention and privacy policy. New retention config (events_days, behavior_days, blocked_ips_days, block_count_reset_days, default 30) plus actual deletion of inactive blocked_ips rows — previously the table grew forever. This lets you state a defensible data-retention period to legal/security review instead of "indefinitely."
• Operational ownership / SLO decisions. Manual crowdsec:block {ip} / unblock {ip} with --reason and --duration is a support-runbook feature: it decides whether on-call can act on an abuse report in minutes or must file an engineering ticket. Retention of block_count for busy NAT/shared IPs (now resets via --old-behaviors) also affects false-positive policy for enterprise customers behind shared egress.
• Release/upgrade planning as a product dependency. Laravel 13 support plus real MySQL 8.4 / PostgreSQL 16 / --prefer-lowest CI coverage is a "can we commit to the framework upgrade path?" signal. Conversely, the breaking-ish upgrade notes (gates, manual throttle:60,1 on published configs, crowdsec:cleanup --audit-logs schedule for Laravel 10 Kernel.php apps) are upgrade-planning items for the next maintenance window.
• Which use cases you can promise. Good fit for: blocking credential stuffing/brute force, honeypot-driven blocking, abuse dashboards for internal ops, IP reputation export (--ip, --event-type filters, streaming export). Not a fit for: PCI/WAF-as-a-compliance-control claims, per-tenant multi-tenant isolation, or anything requiring vendor SLAs.

When to Consider This Package

Adopt when:

• You already run Laravel 10–13 and want application-layer threat blocking without adding an external WAF or a new vendor in the procurement pipeline.
• You need credential-stuffing, honeypot, and injection-pattern defenses that run in-process, with no outbound dependency on a third-party service.
• You have an internal security/ops dashboard use case and can define viewCrowdSec / manageCrowdSec cleanly (e.g. fn ($user) => $user->is_admin).
• You want auditable, time-boxed manual blocking — the new crowdsec:block --reason --duration fits a support-runbook model and produces security events you can export.
• You want a configurable retention story for privacy/legal review.
• Your team accepts you own the upgrade work: reading upgrade notes, defining gates, adding rate limiting to published api.middleware, and scheduling crowdsec:cleanup --audit-logs.

Look elsewhere when:

• You need compliance certifications (PCI DSS WAF requirements, managed rulesets with vendor attestation) or 24/7 signature updates with an SLA.
• You need edge/DDoS protection — this is application-level, running after the request reaches PHP.
• You want zero-configuration, zero-maintenance security. This needs gate definitions, scheduling, retention tuning, and periodic review of which scenarios are enforce vs monitor (the JWT role=admin fix is a good reminder that defaults can block real admins).
• You need multi-tenant policy isolation or per-tenant blocklists; blocklists here are global to the install.
• You are on Laravel 9 or below, or need to run the dashboard/API on a database other than MySQL/MariaDB/Postgres/SQLite — note the whitelisted_ips.expires_at DATETIME migration is a MySQL/MariaDB-only fix.
• Your traffic profile means blocking by IP is wrong (heavy carrier-grade NAT, mobile networks) — the block_count decay fix helps, but IP-centric blocking remains the core model.

How to Pitch It (Stakeholders)

To executives: This release closes a known blind spot (Log4Shell-style lookups and header-borne injection) and, more importantly, fixes a security exposure where any logged-in employee could block IPs and read raw security events. It also introduces data retention controls and automated cleanup, so we can say how long we keep security data instead of "forever." Net effect: a credible baseline defense layer we own, at near-zero licensing cost, with a defined upgrade task list — not a replacement for a commercial WAF.

To engineering: One upgrade dependency to plan for — define the viewCrowdSec and manageCrowdSec gates before deploying, or the dashboard and API 403 outside local. Published configs need throttle:60,1 added manually, and Laravel 10 Kernel.php schedules need crowdsec:cleanup --audit-logs to preserve audit retention. In exchange, the release fixes several correctness bugs that caused real damage: WAF blocks ignoring scenario block_duration, a short block overwriting a longer one, re-blocking IPs immediately after expiry, whitelisted IPs being blocked by the honeypot trap, and crowdsec:cleanup --expired silently deleting audit logs. Performance also improves: fewer queries per clean request, batched deletes, cached metrics, and PCRE limits set once per WAF pass. We now have Laravel 13 support and full-suite CI on MySQL 8.4 and PostgreSQL 16, so the framework upgrade path is unblocked.

To security/ops: You get manual crowdsec:block / unblock with reason and duration, an export with --ip / --event-type filters and streaming batches, retention windows on every table, and block_count decay for busy NAT IPs. Two defaults moved in the safer direction: jwt_privilege_escalation now defaults to monitor (it was blocking legitimate admin bearer tokens), and the REST API is rate limited by default. Review your enforce vs monitor scenario list before go-live.