Recaptcha Firewall Laravel Package

Product Decisions This Supports

• Anti-abuse scope for public surfaces: A reCAPTCHA "firewall" sits in the request path and challenges suspicious traffic before it reaches your application — useful for deciding whether bot mitigation belongs in-app versus at the edge (CDN/WAF).
• Build vs. buy vs. borrow: This is the "borrow" option. It informs the roadmap decision of whether to hand-roll challenge gating in middleware or adopt an off-the-shelf Laravel package. With zero stars and zero dependents, it functions as a reference implementation more than a dependency — a cheap way to prototype the UX and logic of challenge-then-pass-cookie gating.
• Use cases it maps to: protecting high-abuse public forms (signup, contact, lead gen), gating beta/waitlist access, rate-limiting brute-force and credential-stuffing attempts on auth endpoints, and shielding launch-day or campaign traffic spikes without standing up a WAF.
• Funnel-quality tradeoff: Every challenge is a conversion tax. This package lets you quantify that tradeoff (challenge rate, pass rate, drop-off) before committing to a permanent anti-bot posture or a vendor contract.
• Vendor independence: Because it's reCAPTCHA-backed and self-hosted in your app, adoption doesn't create a CDN or SaaS commitment — relevant if procurement cycles or privacy review are long.

When to Consider This Package

Consider it when:

• You're on Laravel and want bot gating inside the app, without routing traffic through a third-party edge or changing DNS.
• The exposure is bounded — a handful of routes, a low-to-moderate traffic surface, a pilot or internal tool.
• You can absorb the maintenance risk: given no stars, no dependents, and no visible adoption signal, treat this as unvetted code you are taking ownership of, not a supported dependency. Budget for a fork and a named maintainer on your side.
• You want a working spike to demo to stakeholders in days, with an exit cost near zero if you swap in Turnstile or an edge WAF later.

Look elsewhere when:

• The surface is business-critical, high-traffic, or revenue-bearing. No dependents means no field-tested failure modes; you'd be the first to find them.
• You need accessibility guarantees, privacy/GDPR review, SLA, or security disclosure processes — none of which are evidenced here.
• Google reCAPTCHA itself is the problem (privacy posture, regional availability, UX). Cloudflare Turnstile, hCaptcha, or edge-level bot management are stronger defaults.
• Your need is really rate limiting, input validation, or auth hardening — Laravel's built-in throttling and existing first-party auth packages solve those with far better support.
• A CDN/WAF is already in place. Duplicating bot mitigation in-app adds latency and a second config surface for no incremental protection.

How to Pitch It (Stakeholders)

To executives: This is a low-cost experiment, not a platform bet. It shows us, quickly and cheaply, whether challenging suspicious traffic inside the app improves form quality and reduces abuse — and what it costs us in legitimate conversions. We can walk away with no switching cost. The caveat is maturity: the package has no meaningful adoption signal, so if the pilot succeeds we should expect to own and maintain the code, or replace it with a supported vendor at that point. Recommendation: fund a time-boxed spike, not a production rollout.

To engineering: Treat it as reference code. Read it, fork it, own it — don't composer require it into anything customer-facing without a review pass on middleware ordering, token verification, cookie scoping, bypass rules, and fail-open vs. fail-closed behavior. Confirm how it behaves when Google's API is slow or unreachable; that's the decision that determines whether an outage becomes our outage. If the spike proves out, plan for the swap to Turnstile or edge protection rather than a long-term commitment to a zero-adoption package.