Laravel Honeypot Laravel Package

Product Decisions This Supports

Feature-level: add anti-spam to public forms without adding friction. This package lets any Laravel form be protected by dropping in a single Blade component (<x-honeypot /> or @honeypot) and attaching the ProtectAgainstSpam middleware to the submission route. For a PM, that's a ~1-ticket, no-design-review, no-vendor-onboarding change that reduces inbox pollution and junk records in the CRM/database. It's the cheapest available option before CAPTCHA.

Build vs buy: buy (adopt), because the "build" version is deceptively small. The core mechanic is a hidden field plus a time-to-submit check — a competent engineer could hand-roll it in a day. What you're actually buying with the MIT dependency is the accumulated edge cases: randomized field names, an encrypted timestamp (so bots can't forge a plausible valid_from), configurable spam responder, and first-party support for Inertia, Livewire (including Volt functional syntax), and Jetstream — plus an enabled env switch that works as a production kill switch. Re-implementing this across every Inertia page and Livewire component is where in-house versions quietly rot.

Roadmap: this defers, and partly de-risks, the CAPTCHA decision. Adopting it gives you a credible answer to "why don't we have CAPTCHA yet?" without committing to a reCAPTCHA/Turnstile integration — which carries vendor cost, third-party script weight, consent/privacy review (GDPR/CCPA), accessibility complaints, and a measurable conversion/friction cost on every form. Treat honeypot as tier-1 defense, rate limiting as tier-2, and CAPTCHA as tier-3 reserved for endpoints with proven, persistent abuse. That's a defensible layered posture you can put in a security or privacy review.

Prioritization: it lets you triage abuse work by endpoint value. Because rollout is per-route middleware, you can protect the contact form, newsletter signup, and guest auth routes (Auth::routes() wrapped in the middleware) first, measure, then extend. Global middleware registration exists for apps with many controllers, and honeypot_fields_required_for_all_forms can enforce coverage — but that flag should be a deliberate, later-phase decision, not a default, since it will flag any form you forgot to instrument.

Use cases where the business case is strongest:

• Contact/lead forms and demo requests, where spam directly costs sales-team time.
• Newsletter and waitlist signups, where junk addresses degrade list quality and email deliverability metrics.
• Public comment or review submission before a moderation workflow exists.
• Guest authentication forms on consumer apps, where bot signups inflate "registered users" and pollute activation funnels.

Metrics this makes legible (and that you should instrument yourself): The package silently discards spam (default BlankPageResponder) and emits no reporting, so PM-owned instrumentation is required: spam-blocked count vs. total submissions, legitimate-user false positives (watch support tickets saying "the form won't submit"), form completion/abandonment rate before and after rollout, and downstream junk-record rate in the CRM. randomize_name_field_name is on by default and is your main defense against browser autofill and password managers filling the hidden field — monitor that false-positive channel specifically after launch.

When to Consider This Package

Adopt when:

• The app is Laravel (routes, middleware, Blade are all first-class here) and forms are public.
• Abuse volume is low-to-moderate and looks like generic, untargeted bot traffic — the README is explicit that "the majority of these bots are pretty dumb," and that is the threat model you're buying.
• You want zero user-visible friction or you're actively trying to remove CAPTCHA from a funnel.
• Your front end is Inertia/Vue, Livewire, or Volt — the package documents each, including a shared honeypot prop via HandleInertiaRequests.
• You already run spatie/laravel-csp and need honeypot's inline hidden style to comply (with_csp).
• You want a reversible, config-flagged rollout with no vendor contract, no billing owner, and no data-processing agreement.

Look elsewhere (or layer on top) when:

• Abuse is targeted, human-assisted, or commercially motivated — credential stuffing, promo/coupon abuse, scraping, fake account farms. A honeypot is not a defense against an adversary who knows your markup.
• The endpoint is high-value (payments, KYC, password reset, invite codes) where a false negative is costly and a false positive is worse.
• You need per-IP/per-identity rate limiting or throttling, IP reputation, bot scoring, or abuse analytics — this package provides none of that; pair it with Laravel's throttle middleware at minimum.
• You need an audited, supported, SLA-backed security control with a named vendor and CVE response process. MIT + community maintenance means you own the risk.
• Compliance or procurement requires vendor security review, DPA, or data residency guarantees — no vendor relationship exists to review.
• The stack isn't Laravel/PHP.

Due-diligence items before you commit it to a roadmap:

• Verify real adoption signals (Packagist download counts, reverse dependencies) rather than star count — the dataset's "0 dependents" is likely a measurement artifact but should be checked, since stars alone are a weak proxy for production usage.
• Confirm framework-version compatibility for your Laravel major against the changelog and release history; a healthy release cadence (recent release dated 2026-09-11) is a positive signal but pin and test it.
• Run an accessibility pass: hidden fields should be hidden from assistive tech and excluded from tab order in your actual implementation, and the default blank-page spam response produces no user feedback — decide deliberately whether false positives should see an error message instead via a custom SpamResponder.
• Verify no collision with real form field names, especially if you use generic names; the config warns about this and it's the most likely self-inflicted outage.

How to Pitch It (Stakeholders)

To executives (one paragraph): We can cut the large majority of automated junk submissions across our public forms with a small, free, open-source change to our existing Laravel app — no new vendor, no monthly cost, no third-party scripts on our pages, and no added friction for real users. It works by adding fields real people never see or fill, plus a check that a human actually spent time on the form. It's reversible in one configuration flag, so the downside risk is low. It is not a complete anti-abuse program: it stops generic bots, not determined attackers, so we should pair it with rate limiting and reserve paid bot-detection for endpoints where we see real, persistent abuse. Recommended: approve as a low-cost, low-risk first layer, instrument it, and revisit CAPTCHA only if the data says we need it.

To engineering:

• Install via Composer; optionally publish config/honeypot.php.
• Add <x-honeypot /> (or @honeypot) to each target form; attach ProtectAgainstSpam to the corresponding POST routes — start per-route, not global.
• Keep randomize_name_field_name enabled (default) to reduce autofill-driven false positives; keep enabled wired to an env var as a kill switch.
• For Inertia, share the Honeypot object through HandleInertiaRequests and merge nameFieldName / validFromFieldName / encryptedValidFrom into each form's payload; for Livewire, use the UsesSpamProtection trait with a HoneypotData property and call protectAgainstSpam() at the top of the submit handler.
• Default BlankPageResponder returns a blank response — replace it with a responder that suits your UX and don't leave users staring at nothing on a false positive.
• Add structured logging/counters around the middleware: we need blocked-vs-submitted counts and a way to spot legitimate users being rejected before we widen coverage.
• Do not enable honeypot_fields_required_for_all_forms until coverage is audited; it will flag any uninstrumented form, including JSON/API endpoints.

To security/legal (brief): No third-party data processor, no user data leaves our infrastructure, no tracking scripts, MIT-licensed with a public changelog and release history, and the anti-spam timing value is encrypted rather than plaintext. It complements — does not replace — rate limiting, WAF, and monitoring.