Weave Code
Antispam Bundle Laravel Package
core23/antispam-bundle
A Symfony bundle for stopping form spam with honeypots, submission timers, banned scripts, markup and phrases, plus URL counting. Configure reusable anti-spam profiles and apply them to any form. Compatible with PHP 8.2+ and Symfony 6.4, 7.x and 8.x.
This bundle provides some basic features to reduce spam in symfony forms.
Frequently asked questions about Antispam Bundle
- Can I use core23/antispam-bundle in a Laravel application?
- No. This is a Symfony bundle, not a Laravel package: it ships a Bundle subclass, a DependencyInjection extension, container tags and form extensions that Laravel's container does not implement. It has no service provider, no publishable config file, no middleware registered into Laravel's HTTP kernel and no Blade, Livewire or Inertia integration, so installing it in a Laravel app either fails or produces dead code that never fires. For Laravel, use spatie/laravel-honeypot, FormRequest validation rules, throttle middleware with RateLimiter, or Cloudflare Turnstile on high-risk forms.
- How do I install the anti-spam bundle?
- You install it with Composer in a Symfony project using composer require core23/antispam-bundle, then enable the bundle in config/bundles.php. Configuration is done under the antispam key, where you define reusable profiles and attach them to specific forms. Note that the README badges and documentation still point to the omines/antispam-bundle package and its docs site, so check which vendor coordinate you are actually pulling in.
- Which PHP and Symfony versions are supported?
- The bundle supports PHP 8.2 and newer, along with Symfony 6.4 LTS, 7.4 LTS and 8.x. It relies on symfony/form, symfony/options-resolver, symfony/http-foundation and symfony/translation, so it expects a full Symfony kernel and framework wiring. There is no Laravel or generic framework support at any version.
- How does the anti-spam profile system work?
- A profile is a named configuration that bundles several detection mechanisms together, and you apply a profile to a form instead of wiring each mechanism by hand. That means you can have a strict profile for public contact forms and a lenient one for account registration or checkout. Profiles are defined in bundle configuration and referenced from your form code, which keeps the spam strategy out of the form classes.
- Why does the timer mechanism block real users or cached forms?
- The timer measures the gap between rendering a form and submitting it, and rejects submissions that are too fast or too slow. Aggressive full-page caching can serve stale timestamps and trip the upper bound, while autofill, password managers and fast mobile users can trip the lower bound. Set generous min and max windows per profile, and never apply a timer profile to a form that is served from a shared cache.
- Are banned script and banned phrase rules safe for international users?
- Banned script rules such as blocklists for Cyrillic or Arabic will reject legitimate users who submit names, messages or addresses in those scripts, so enable them only on forms where that is an acceptable trade-off. Banned phrase and banned markup lists are heuristic and decay over time, meaning they need ongoing curation to stay useful. Prefer per-form profiles so a strict rule on a public contact form never leaks into a registration or profile-editing form.
- Can I use the honeypot, timer or URL counter as standalone components?
- Yes. Each mechanism in the bundle is designed to work either standalone or through a profile, so you can adopt just the honeypot field or just the URL counter without enabling the rest. That is useful for incremental rollout on a high-traffic form. The trade-off is that individual heuristics are weak in isolation; layering two or three of them per profile is what gives realistic protection.
- Is this package tested and safe to run in production?
- The underlying upstream project advertises automated testing, PHPStan max level and mutation testing, but those badges belong to the omines/antispam-bundle repository, not to this fork. This fork shows zero stars, zero dependents and no visible release cadence, security policy or issue responsiveness, which means you should assume you inherit maintenance if you depend on it. Treat it as a reference implementation and audit the code before shipping it to a production Symfony service.
- Who maintains this package, and is it abandoned?
- There are three identities in play: the repository is nucleos/NucleosAntiSpamBundle, the Composer coordinate is core23/antispam-bundle, and every README badge still points to omines/antispam-bundle. That indicates a fork of a fork with the original vendor's documentation left intact. Fork drift, unmerged upstream fixes and unclear canonical ownership are all real risks, so track the original omines project for security fixes and compare it against whatever version you install.
- What are the best Laravel alternatives to this Symfony anti-spam bundle?
- On Laravel, combine rate limiting via throttle middleware and RateLimiter, custom FormRequest validation rules, and a maintained honeypot package such as spatie/laravel-honeypot. Add Cloudflare Turnstile or hCaptcha to public forms where you need stronger proof of humanity. If you like this bundle's design, copy the profile-based configuration and strategy interface into a thin in-house package rather than trying to run Symfony components standalone inside Laravel.
Weaver
How can I help you explore Laravel packages today?