Invisible Recaptcha Laravel Package

Technical Evaluation

Architecture fit

• Thin adapter, not a framework: a ServiceProvider, Facade, Blade/JS renderer, a validation rule (invisible_captcha), a config stub, and a server-side call to Google's siteverify endpoint. No persistence, no schema, no domain coupling.
• Sits at the HTTP edge and plugs directly into Laravel's FormRequest rules array, which is the natural seam. Fits cleanly into both monolith and modular Laravel apps.
• For Lumen, CodeIgniter, and native PHP the classes are usable standalone, but auto-discovery, config publishing, and the Blade directive do not apply — integration effort roughly doubles.

Integration feasibility

• composer require, publish config, set RECAPTCHA_SITE_KEY / RECAPTCHA_SECRET_KEY, add the rule. Half a day for a standard Laravel form; an hour if the team has done it before.
• The blocker is version constraints, not code. Last release Feb 2022 implies illuminate/* capped around v9 and no declared PHP 8.2/8.3 support. On Laravel 10/11 this needs a fork or a constraint override, not a clean install.

Technical risk (ranked)

1. Staleness — 2+ years since release; framework and PHP support unverified. Highest-probability blocker.
2. Bus factor — single-maintainer OSS, no visible security policy or disclosure process, no SLA.
3. Protocol drift — Google is steering toward reCAPTCHA v3/Enterprise; invisible v2 is legacy-adjacent and could be deprecated or silently re-behaved.
4. Token lifecycle — tokens are single-use with ~2-minute expiry; multi-tab, back-button, and SPA re-renders produce false negatives that look like bot traffic.
5. Synchronous verification — every protected submit pays an outbound round trip (~100–400 ms) and is coupled to Google's availability.
6. Secret handling — .env by default; needs vault-backed injection and a rotation plan.
7. Supply chain — transitive Guzzle/Illuminate dependencies inherited from a stale lockfile.

Key questions

• Does it run on Laravel 11 / PHP 8.3, and who owns the fork if not?
• Fail-open or fail-closed when Google is unreachable — and is that configurable per form?
• Is the threshold/action policy tunable, or is it one global setting?
• What is the no-JS and accessibility fallback?
• Can the HTTP client be faked for tests without patching the package?
• Is there a credible exit to v3, Enterprise, or Turnstile, and what does the swap cost?

Integration Approach

Stack fit Strong for Laravel 8/9 monoliths with server-rendered forms. Weak for Laravel 10+, and out of scope for API-only, SPA-with-separate-backend, or non-PHP services — those should use a JS-side widget plus a first-party verifier.

Migration path

• From hand-rolled cURL + hidden input: near drop-in, low risk, immediate win in readability and test coverage.
• From another package (biscolab/laravel-recaptcha, google/recaptcha): comparable surface; note that biscolab is materially more actively maintained and supports v3 — benchmark it before committing.
• To anything else later: wrap the package behind an internal CaptchaVerifier interface from day one. The package then becomes one adapter among several, which converts the abandonment risk from a rewrite into a one-file change.

Compatibility Pin laravel/framework at ≤9 or vendor a fork under your namespace; never use --ignore-platform-reqs in production. Verify Guzzle major-version alignment (v6 vs v7) against the rest of the dependency graph. Confirm the CSP allows Google's script origin and that the widget loads behind your CDN/proxy.

Sequencing

1. Spike (week 1) — install on a branch, protect one low-risk form (contact, newsletter), measure added p95 latency and submit success rate.
2. Abstract (week 2) — internal interface + adapter, contract tests against a faked HTTP client, config-driven key sourcing from the secrets manager.
3. Rollout (weeks 3–4) — feature flag at 5% → 50% → 100%, watching success rate, p95, and siteverify error rate.
4. Harden (week 5) — key rotation runbook, alerting, documented fail-mode, privacy review (user IP + token leave your boundary to Google — add to the subprocessor list).

Operational Impact

Maintenance Assume near-zero upstream activity. Budget 1–2 engineer-days per quarter to track framework upgrades and advisories, and treat all patching as yours. Make the fork-vs-swap call explicitly at adoption time rather than discovering it during a Laravel 11 upgrade.

Support Community GitHub issues only; no vendor, no escalation path, no CVE process. An internal runbook (keys, rotation, fail-mode, rollback) is a launch prerequisite, not a nice-to-have.

Scaling Verification is one outbound HTTPS call per protected submission — negligible load on your infrastructure but a hard external dependency on latency and Google's quota. Nothing is cacheable (tokens are single-use). At high volume, apply the rule selectively to risky actions (registration, password reset, checkout) rather than globally, so you aren't paying the round trip on every search or comment.

Failure modes

• Google outage/timeout → fail-open risks bot ingress, fail-closed risks user lockout. Default to fail-open with alerting on low-risk forms, fail-closed only on account-creation abuse vectors.
• Expired or reused token → users see a validation error with no obvious cause; a "please retry" recovery path must exist in the UI.
• Key compromise → needs a dual-key rotation window and a documented cutover.
• Upstream abandonment → a frozen dependency is survivable; being blocked on a framework upgrade is not. This is the failure mode that actually costs money.

Ramp-up A Laravel developer is productive in a few hours; CodeIgniter or native-PHP integrators need about a day. Add roughly one day for on-call runbook, dashboards, and privacy review. Total cost of ownership is dominated by maintenance, not initial integration.

Verdict A tactically sound fit for a Laravel ≤9 application that needs CAPTCHA this quarter and can absorb it behind an internal interface. It is not a strategic bet: staleness plus single-maintainer risk make it a liability on a modern Laravel roadmap. Evaluate biscolab/laravel-recaptcha (v3) or Cloudflare Turnstile as the default, and reserve this package for existing v2 deployments where churn costs more than the risk. The high opportunity score reflects exactly this gap — the package is well-shaped but under-maintained, which is an opening for a maintained alternative rather than a reason to adopt.