Altcha Bundle Laravel Package

Product Decisions This Supports

• CAPTCHA replacement / bot-mitigation strategy. ALTCHA is a proof-of-work challenge instead of a third-party CAPTCHA widget, so this package is the concrete "build vs. buy vs. keep Google reCAPTCHA" input for any signup, login, contact-form, checkout, or password-reset abuse problem.
• Privacy and compliance roadmap. Because verification is self-hosted and does not fingerprint users or ship data to a third party, it directly supports GDPR/CCPA positioning, cookie-consent reduction, and "no third-party trackers" commitments that reCAPTCHA/hCaptcha undermine.
• Security hardening roadmap. The 3.1.0 CSP support is the decision-relevant item: teams that enforce a strict Content-Security-Policy (a common audit finding, and a prerequisite for many enterprise security questionnaires) can now adopt ALTCHA without a policy exception. That unblocks rollout in environments where the previous release would have required weakening CSP.
• Vendor and dependency risk. Small, single-maintainer package — this feeds the "acceptable dependency" call, the security-review checklist, and whether to pin versions or wrap it behind an internal abstraction.
• Platform choice. Note the scope: this is a Symfony bundle (altcha-bundle), not a Laravel package. For a Laravel codebase the decision is really about the underlying ALTCHA PHP/server library plus a thin in-house integration; the bundle's releases are useful signal for the health of that ecosystem, but they are not drop-in Laravel work.
• Release cadence as a signal. Two changes, one bugfix and one feature, in a minor bump — a healthy, low-drama maintenance pattern that supports keeping the dependency current rather than forking.

When to Consider This Package

Consider it when:

• You need bot/abuse protection on public forms and want to avoid third-party CAPTCHA scripts, user-tracking, or consent-banner overhead.
• Your stack is Symfony (or you are willing to use the underlying ALTCHA PHP library directly from Laravel/other frameworks).
• You ship a strict Content-Security-Policy; 3.1.0's CSP support is the minimum version to evaluate — earlier versions will force you to relax headers.
• Your threat model is scripted/form-fill abuse at moderate volume, where a proof-of-work challenge is proportionate. It is not a substitute for rate limiting, WAF, or fraud scoring.
• You can absorb a young, small-maintainer dependency, ideally behind your own interface so you can swap it out.

Look elsewhere when:

• You need enterprise SLAs, vendor indemnity, or a formal security program with a guaranteed disclosure timeline — a commercial bot-management vendor is the safer call.
• You are a Laravel-first team wanting a supported first-party package; the ecosystem here is Symfony-oriented, so budget for an in-house adapter and its maintenance.
• Your abuse profile is sophisticated (credential stuffing at scale, residential-proxy farms, targeted scraping) — proof-of-work raises cost but does not stop determined adversaries; combine with or replace by other controls.
• Accessibility or no-JS support is a hard requirement — validate the challenge widget against your baseline before committing.
• You need per-user risk scoring or adaptive challenges; this is a fixed-mechanism gate.

How to Pitch It (Stakeholders)

To executives: We can replace third-party CAPTCHA on our public forms with a self-hosted, privacy-preserving alternative. It removes a tracker from our pages, reduces consent and legal exposure, and avoids per-request vendor fees. The cost is a small open-source dependency and a modest integration effort — worth piloting on one low-risk form before wider rollout.

To engineering: Adopt altcha-bundle 3.1.0 or later — it adds CSP support, which means we don't have to carve an exception into our security headers, and it fixes a type error in 3.0.0. Caveat: this is a Symfony bundle. If the target service is Laravel, we integrate the underlying ALTCHA PHP library ourselves behind an internal ChallengeVerifier interface so the dependency stays swappable. Pin the version, add it to our dependency-review list given the single-maintainer risk, and pair it with existing rate limiting rather than treating it as the sole control.

Recommendation: Approve a scoped pilot on one form. Success criteria: challenge pass rate for legitimate users, measured drop in form-spam volume, no CSP violations, and a working fallback path if the package is abandoned. Revisit for broader rollout once the pilot data is in.