Laravel Waf Laravel Package

Product Decisions This Supports

• Buy vs. build for app-layer protection. This release shifts the package from "a WAF you install" to "a WAF you can operate with confidence." The waf:doctor command directly addresses the failure mode that kills self-hosted WAFs in practice: silent misconfiguration that looks identical to "no attacks." That materially de-risks the buy decision for teams without dedicated security operations.
• Launch and release-readiness gating. Because waf:doctor exits non-zero only on real failures and prints the exact fix, it can be wired into CI or a deploy step. This turns WAF health into a binary, automatable pre-production decision rather than a manual audit—useful for roadmap milestones like "production hardening," "SOC2 evidence," or "first enterprise customer."
• Prioritizing security roadmap items without new infrastructure. Null-byte injection coverage (rule 920270) closes a well-known upload-bypass class (file=passwd%00.jpg). The deliberate exemption for request bodies is a thoughtful product trade-off—binary bodies legitimately contain NULs—and is the kind of detail that reduces false positives during rollout.
• Perimeter integration without building it. waf:export --format=fail2ban lets the team push application-layer findings into existing network defenses. This is a "connect, don't rebuild" decision: you get defense-in-depth from the app WAF plus the host/edge firewall you already run, with no new vendor.
• Exclusion governance and blast-radius control. The change from substring to exact matching on exclusion rules is a genuine security-posture improvement. Previously a match_label of 942 silenced every SQL injection signature and SQL silenced every rule mentioning SQL—effectively an unbounded off-switch for the exact detections the team relies on. Exact matching constrains the blast radius of every future exclusion decision.
• Upgrade risk assessment. The same change is the one item requiring a product/engineering decision before upgrading: hand-inserted exclusion rows that relied on partial matching will stop matching. This re-enables detection (the safe direction), but may surface previously suppressed noise. If your team has manually seeded exclusions, budget a short audit before the v1.3.0 rollout.

When to Consider This Package

Adopt when:

• You run a Laravel application that handles untrusted input and you need application-layer protection that complements—not replaces—an edge WAF or CDN.
• The app handles file uploads, authentication, payments, PII, or multi-tenant data where a null-byte or SQLi bypass has real business consequence.
• You already have (or are willing to build) a deploy pipeline that can run php artisan commands—waf:doctor is only as valuable as the gate you put it behind.
• You want security findings to flow into existing ops tooling (e.g. fail2ban) rather than adopting a new SIEM or managed security service.
• You can own the operational basics: publishing config and patterns, running migrations, and having a cache driver that supports flood counting, bans, and deduplication.
• You have a process—even a lightweight one—for reviewing exclusion rules. Exact matching makes individual exclusions safer, but someone still needs to own the decision to disable a detection.

Look elsewhere when:

• You need managed, edge-level WAF, bot management, or DDoS absorption with a vendor SLA—this package is an application-layer control, not an edge service.
• You cannot publish config, run migrations, or modify the deploy pipeline; several of v1.3.0's best features (schema self-healing, drift detection, CI gating) depend on those capabilities.
• Your app sits entirely behind a CDN or reverse proxy that already terminates and inspects traffic, and you have no appetite for a second ruleset to tune.
• You require a certified/compliance-managed ruleset with vendor-maintained signatures and formal support; this is a self-operated package.
• You have hand-tuned exclusions with partial-match labels and cannot audit them before upgrade—defer until you can, because v1.3.0 will silently re-enable detections those rows were suppressing (again, the safe direction, but potentially noisy).

How to Pitch It (Stakeholders)

To executives: This release makes our application firewall provable rather than merely present. The new waf:doctor command catches the failure modes where a WAF appears healthy but is silently logging nothing—missing schema columns, stale pattern packs, unwired middleware—and exits non-zero so it can block a deploy. That converts a security control from "we think it's on" into "we can demonstrate it's on," which is the difference between a checkbox and audit evidence. We also close a known file-upload bypass (null-byte injection) and tighten exclusion rules so a single mis-scoped exclusion can no longer disable an entire detection category. No new infrastructure or vendor spend is required.

To engineering: v1.3.0 adds three things worth adopting immediately. First, waf:doctor validates the full silent-failure surface—environment enablement, waf_logs column completeness, exclusion table existence, middleware wiring, published pattern/config drift, and cache-driver capability—and prints the exact remediation command for each finding. Put it in CI or the deploy step. Second, waf:export --format=fail2ban emits shell-safe fail2ban-client set <jail> banip <ip> lines with a configurable jail name, so findings can feed host-level bans. Third, schema drift now explains itself: when a finding can't be written (typically a missed upgrade migration), the WAF logs a once-hourly message naming the cause and the vendor:publish + migrate fix, instead of a raw SQL error per request with a quietly empty log.

One migration note to flag in the upgrade ticket: exclusion rules now match the finding label exactly rather than by substring. The old behavior meant an exclusion of 942 silenced every SQLi signature. Rows created through the dashboard/log flow (acceptFromLog) already store exact rule IDs and are unaffected; only hand-inserted rows relying on partial matching change, and they change by re-enabling detection. Audit those rows before deploying. The three-character minimum-length guard is removed, since exact matching makes it unnecessary.