Alt Inbound Laravel Package

Product Decisions This Supports

• Edge vs. application-layer abuse mitigation. Choosing between a WAF/CDN (Cloudflare, Fastly, AWS WAF) and in-app IP blocking for form spam, credential stuffing, scraping, and comment abuse on Statamic properties. This addon represents the "cheap, in-app" end of that spectrum.
• Build vs. buy vs. fork. A competent Laravel engineer can replicate IP-block middleware in roughly a day; this package's value is the Statamic control-panel surface, storage, and lifecycle hooks, not the blocking logic itself. The decision is whether that UI is worth adopting an unvetted dependency versus owning ~200 lines of middleware.
• Editorial/ops self-service roadmap. If support or content teams currently file tickets to engineering every time an abusive IP needs blocking, an addon that exposes blocklist management in the Statamic CP converts recurring engineering toil into an ops capability.
• Roadmap item: abuse handling for user-generated surfaces. Contact forms, comments, member registration, and login throttling are the common Statamic pain points this would address; scope it as a hardening increment rather than a standalone feature.
• Compliance and access-policy scoping. IP allow/deny lists can support coarse regional or network restrictions (e.g., staging lockdown, blocking a corporate range), but should not be positioned as geo-restriction or sanctions screening — IP geolocation is unreliable and trivially bypassed by VPN.
• Vendor-risk posture. With 3 stars, 0 dependents, and a single maintainer, the real decision is "pilot and internalize" versus "standardize." Treat any adoption as a fork-ready commitment, not a procurement of a supported product.

When to Consider This Package

Consider it when:

• You run a Statamic site (verify version compatibility against your install — this is a Statamic addon, not a general Laravel package) and want blocklist management without building a UI.
• Your team is small and no WAF or reverse proxy is in place, and the threat model is opportunistic abuse rather than volumetric DDoS.
• Non-technical staff need to block an IP quickly (harassment, scrapers, a single bad actor) without a deploy.
• Traffic volume is modest enough that per-request middleware evaluation is not a measurable cost.
• You're comfortable reading the source before shipping it — MIT license permits that, and for security-path code you should.

Look elsewhere when:

• You need DDoS resilience, bot fingerprinting, or per-route rate limiting — that belongs at the edge or in Laravel's throttle middleware.
• Your app sits behind a CDN/proxy and the addon does not correctly resolve client IP from trusted headers; naive X-Forwarded-For handling is both a bypass and a spoofing vector that can lock out legitimate users.
• You require IPv6, CIDR ranges, expiry/TTL on blocks, audit logging, or SIEM/alerting integration — confirm each exists; assume nothing from a 3-star repo.
• You need a maintainer SLA, security disclosure process, or reference customers. There are zero public dependents, so no production references exist.
• Your platform is plain Laravel, multi-tenant SaaS, or non-Statamic — the Statamic dependency is dead weight.

Minimum due diligence before a pilot: does it fail open or closed; where blocks are stored (DB vs. file vs. cache) and whether that survives deploys; whether admins can lock themselves out; how it behaves with cached pages; and test coverage. A security control with no tests is a liability.

How to Pitch It (Stakeholders)

To executives: This is a free, MIT-licensed addon that lets our Statamic site block abusive traffic from the admin panel instead of through engineering tickets. It is a low-cost trial, not a security strategy. It has essentially no adoption and one maintainer, so we should not treat it as a supported vendor product — budget a short engineering review and be prepared to own a fork. It does not replace a WAF; if we later need real DDoS or bot protection, that is a separate, larger line item.

To engineering: Small surface area — blocklist storage plus request middleware, wrapped in a Statamic CP UI. Before we adopt: audit IP resolution behind our proxy, block storage durability across deploys, fail-open vs. fail-closed behavior, and lockout safeguards. If the audit is clean, pilot on a low-risk property for one sprint. If it isn't, the blocking logic is a one-day build and we keep the CP UI as a follow-up.

Recommendation: Timeboxed pilot on a non-critical site, paired with edge-level protections, with an explicit decision point on fork-and-own. Do not make this the primary control protecting authentication or payment-adjacent surfaces.