Antispam Bundle Laravel Package

Getting Started

First, resolve the stack mismatch — before anything else. Despite the core23/antispam-bundle coordinate and the "Laravel developer" framing, this is a Symfony bundle, not a Laravel package. It ships a Bundle class, a DependencyInjection extension, container tags, symfony/form extensions and event subscribers. There is no service provider, no publishable config, no middleware, no facade. composer require core23/antispam-bundle will pull the code, but nothing will wire itself into a Laravel app, and the form integration assumes a full Symfony kernel.

So "getting started" splits into two tracks:

If you actually run Symfony (6.4/7.4/8.x, PHP 8.2+):

1. composer require omines/antispam-bundle — note the README badges point at omines/, not core23/ or nucleos/. Confirm which coordinate is canonical and maintained (see Gotchas) before you pin.
2. Enable the bundle in config/bundles.php.
3. Define a profile in config/packages/antispam.yaml (honeypot + timer is the sane default to start).
4. Attach the profile to a form via the provided form extension/option — start with your public contact or registration form, not checkout.
5. Read the docs at omines.github.io/antispam-bundle first; the README is a teaser, the real API surface (profile schema, per-mechanism options) lives there.

If you are in Laravel (the realistic case): the artifact is not adoptable, but the design is. The highest-value first use case is a honeypot + signed-timestamp timer on registration and contact forms — that's ~50 lines as two custom validation rules plus a hidden field, with the same layered, profile-style config shape the bundle uses. Treat this as "adopt the pattern, not the package": read their mechanism list (honeypot, timer, banned scripts, banned markup, banned phrases, URL count), copy the configuration model, and implement against Laravel's FormRequest/validator pipeline. The bundle's real contribution to you is a checklist of heuristics that are already proven-ish, so you're not inventing policy from scratch.

Implementation Patterns

Profile-per-form is the core idea, and it's the part worth stealing. The bundle's value proposition is that you don't sprinkle checks in controllers — you declare a named profile once and attach it to specific forms. Mirror that in Laravel with a config array:

// config/antispam.php
return [
    'profiles' => [
        'registration' => ['honeypot' => true, 'timer' => ['min' => 3, 'max' => 3600]],
        'contact'      => ['honeypot' => true, 'timer' => ['min' => 2], 'urls' => ['max' => 3]],
        'checkout'     => ['honeypot' => true], // invisible to real users; no timing
    ],
];

Then a single AntiSpam service resolves the profile and applies it, so adding a mechanism is a config edit, not a code change.

Layer by friction budget, not uniformly. The bundle deliberately separates mechanisms so you can dial friction per funnel. Match mechanisms to blast radius:

• Registration / contact / newsletter: honeypot + timer + URL count + banned phrases. Bots target these hardest and false positives cost little.
• Checkout / payment: honeypot only (or nothing plus edge bot management). A timer that rejects a fast, autofilled, returning customer is a revenue bug, not spam prevention.
• Password reset: timer + rate limit. Content heuristics are useless here and risky.

Wire it as validation, not a controller if. In Symfony the mechanisms surface as form constraints/events; in Laravel the equivalent is custom validation rules (Honeypot, SubmittedTooFast) on the FormRequest. That keeps the anti-spam outcome visible in the same place as all other validation, testable, and consistent in error messaging.

Keep an abstraction boundary. Because lineage and maintenance are uncertain, wrap whatever you adopt behind your own interface (AntiSpam::check(Profile $p, Request $r)) so you can swap the bundle for spatie/laravel-honeypot, Turnstile, or edge bot management without touching product code. This is the single most important implementation pattern given the maturity signals.

Instrument before you trust it. Log every rejection with the mechanism that fired and the profile. This is how you tune thresholds and catch false positives — the bundle won't do this for you, and heuristics rot silently without it.

Gotchas and Tips

• Package identity is inconsistent and this is the biggest flag. Packagist name (core23), repository (nucleos/NucleosAntiSpamBundle), and README (omines/antispam-bundle) all disagree. This looks like a fork-of-a-fork with an unchanged README. Before pinning anything, confirm the canonical, maintained upstream (likely omines/) and whether this fork carries unmerged fixes or drift. Pin an exact version and read the diff.
• Honeypot fields must be hidden with CSS, not type="hidden". Bots skip type=hidden inputs; a field hidden via position: absolute; left: -9999px (or display:none with a real-looking name like website) is what actually baits them. If you're reimplementing, get this detail right — it's the whole point.
• Timers break legitimate users more than you expect. Aggressive page caching can make a form appear "submitted too fast" (user loads a cached page minutes old, fills instantly, or autofill/password-manager/mobile submit fires within milliseconds). Keep min low (2–3s), and always set a max upper bound or the field becomes a silent rot mechanism. Exclude known-good flows (returning users, autofill) where you can.
• Banned-scripts (Cyrillic/Arabic) will block real international customers. It's a blunt instrument — fine for an English-only B2B funnel, dangerous for anything with global reach. Make it per-profile and off by default.
• URL-count and duplicate-content checks punish legitimate repeat submissions (a user re-submitting a contact form, a message quoting links). Thresholds need real traffic to tune; start permissive and tighten.
• Zero dependents / zero stars means assume you inherit maintenance. No visible security policy, release cadence, or issue responsiveness. Budget for reading the source, keep the abstraction boundary, and don't build anything irreplaceable on it.
• It's server-side and HTML-form-only. No JS, no API/JSON protection, no edge coverage. If abuse escalates to credential stuffing or scraping, this layer won't help — escalate to managed bot management (Cloudflare/DataDome) rather than bolting more heuristics on.
• Config caching (Symfony) / config caching (Laravel) will bite you when you change profiles: cache:clear / config:cache after profile edits, or you'll debug a change that "isn't taking effect."
• Privacy note: IP and submission-content retention for scoring can trigger GDPR/CCPA obligations. Keep retention short and documented; the upside of this approach over third-party CAPTCHA is exactly that it stays in your servers — don't squander it by logging full payloads indefinitely.