Google Recaptcha Bundle Laravel Package

Product Decisions This Supports

• Bot-abuse mitigation strategy for public surfaces — signup, login, password reset, contact, checkout, and any unauthenticated form. The underlying problem (credential stuffing, form spam, scraping) is real and roadmap-worthy; this specific package is not the answer.
• Build vs. buy for captcha integration — and the answer here is build. Server-side reCAPTCHA verification is a single outbound HTTP call plus one validation rule. That is a half-day of work in Laravel and removes a dependency entirely. A 6-star, archived, 9-year-stale bundle is not a "buy" that saves you anything.
• Platform fit — flag this immediately: this is a Symfony bundle, not a Laravel package. It registers Symfony DI services and configuration; it will not drop into a Laravel app's service provider model. The only portable asset is the idea, not the code.
• Supply-chain and tech-debt risk registry — an archived dependency in the authentication/anti-abuse path is a standing liability. It supports a decision to reject now rather than inherit a migration later.
• Privacy and compliance posture — reCAPTCHA ships user signals to Google. Whether you adopt v2, v3, or Enterprise is a data-processing decision (DPA, consent, regional data transfer), not a library decision. This package's 2018 vintage predates v3/Enterprise support, so it cannot inform the modern option set at all.
• Scope of protection — which endpoints get challenged, friction budget (v2 checkbox vs. v3 invisible scoring), and fallback behavior when the captcha service is degraded. These are product calls the package makes for you via its own conventions — another reason to own the code.

When to Consider This Package

• Effectively never for new work. Archived since 2018, one release, 0 dependents, 6 stars, automated score 0.095. There is no maintenance path, no security response, and no community to validate it.
• The only defensible case: you are already running a legacy Symfony 2/3/4 application with this bundle installed, and you need a short-lived bridge while you replace it. Even then, treat it as a migration trigger, not a keep decision.
• Look elsewhere when: you are on Laravel (it does not apply — write a custom validation rule backed by Laravel's HTTP client), you need reCAPTCHA v3 score-based or Enterprise flows, you have any security review requirement, you need maintained dependency scanning, or you expect anyone other than the original author to read the code.
• Do not adopt if the integration touches authentication or payment flows — those need a dependency you can get a CVE patch for.

How to Pitch It (Stakeholders)

To executives: We evaluated a third-party captcha package and are recommending against it. It was last released in 2018, is formally archived by its author, and has zero downstream users — meaning no one is watching it for security issues. The risk is asymmetric: adopting it saves roughly a day of engineering, and the downside is an unpatched component sitting in front of our login and signup flows. We recommend a small in-house integration we control.

To engineering: Note the platform mismatch — this is a Symfony bundle and we are on Laravel, so there is no integration path short of a rewrite anyway. The replacement is a thin service wrapping an outbound verification call, plus a custom validation rule applied to the endpoints we choose. Estimate: 1–2 days including tests and a config toggle. Bonus: we own the fallback behavior when Google is slow or unavailable, which matters for conversion more than the captcha itself does.

Ask: Approve the in-house build, and let us decide v2 vs. v3 vs. Enterprise as a separate privacy/UX trade-off rather than inheriting it from a dead library.