spatie/laravel-honeypot for Laravel form spam prevention

The Laravel forms spam problem addressed by x-honeypot

spatie/laravel-honeypot addresses automated form submissions that rely on filling every field they encounter. Public contact, registration, and similar forms expose ordinary HTML inputs to any client, so a bot can imitate a browser without understanding the purpose of each field. The package adds an invisible field that legitimate users should leave empty but naive automated form fillers commonly populate.

The intended users are Laravel developers adding forms to public sites. The package is particularly suited to conventional server-rendered Blade forms because its normal integration consists of an `x-honeypot` component or `@honeypot` directive. It also supports supplying the required values manually for an Inertia application, although the README does not show the complete Inertia implementation.

This is not a general-purpose intrusion detector. Its documented protection has two parts: reject a request containing a value in the honeypot field, and reject a request submitted faster than the configured minimum time. It does not claim to detect distributed, browser-like bots, repeated valid submissions, credential attacks, or spam sent through an API without rendering the form.

Hidden names, timestamps, and ProtectAgainstSpam request handling

Rendering `x-honeypot` adds the hidden values required by the package. The README names these values as `my_name` and `valid_from_timestamp`, while the published configuration exposes the first through `name_field_name`, whose default is `my_name`, and the timing field through `valid_from_field_name`, whose default is `valid_from`. Field names can be changed, but the config warns that they must not collide with fields used by the application.

The hidden name is not fixed in every installation. With `randomize_name_field_name` enabled, the package adds a random string to the configured honeypot name. The default configuration enables this behavior through `HONEYPOT_RANDOMIZE`. Changing a generated field name is therefore not a reason to rename form inputs that participate in normal validation.

The timing check uses a timestamp generated for the view and described by the README as encrypted. `valid_from_timestamp` enables that check by default, and `amount_of_seconds` defaults to one second. The route still needs `Spatie\Honeypot\ProtectAgainstSpam`. According to the README, this middleware intercepts a non-empty honeypot value and an encrypted timestamp that permits an implausibly fast submission. A successful request returns void, while the configured spam protection throws `Spatie\Honeypot\ExceptionsSpamException`.

By default, `BlankPageResponder` handles a flagged request. The response class is configurable, and any replacement must implement `Spatie\Honeypot\SpamResponder\SpamResponder`. This separation keeps detection and response behavior distinct, although the README does not document how exceptions are translated into HTTP responses beyond naming the blank page default.

Composer installation and the first protected Blade form

Install the package through Composer in the Laravel application:

composer require spatie/laravel-honeypot

Publishing the configuration is optional. This command publishes the package configuration under the `honeypot-config` tag:

php artisan vendor:publish --provider="Spatie\Honeypot\HoneypotServiceProvider" --tag="honeypot-config"

The README says the file is published at `config/honeypot.php`. For a first protected form, render the component inside the form:

<form method="POST">
    <x-honeypot />
    <input name="myField" type="text">
</form>

The component inserts the hidden protection fields, so those values should appear when inspecting the rendered HTML. If a route-level form is being added, also attach `Spatie\Honeypot\ProtectAgainstSpam` to the route that handles its submission. The package does not protect a form merely because the hidden fields are rendered. A request must pass through the configured protection class for the checks to apply.

The component is hidden with an inline style by default. Enabling `with_csp` changes that mechanism to a style tag with a CSP nonce and requires `spatie/laravel-csp`. The README does not document installation or configuration steps for that optional integration, so `HONEYPOT_WITH_CSP` should not be enabled without first reviewing the separate package requirements.

Blade directive and Inertia data delivery options

Applications that prefer Blade directives can use `@honeypot` instead of the component:

<form method="POST">
    @honeypot
    <input name="myField" type="text">
</form>

Both forms of view integration are intended to add the same hidden protection values. The directive is not a separate detection layer. Once the fields are submitted, middleware performs the configured checks.

For an Inertia-powered application, the README states that the necessary values can be passed manually to the view layer. The repository does not provide the PHP values, JavaScript rendering code, or middleware sequence for Inertia in the visible README excerpt, so an implementation based only on that documentation would still need to derive the supported data handoff from the installed package rather than invent a client-side field format.

The package also offers a strictness choice through `honeypot_fields_required_for_all_forms`. Its default is `false`, so missing honeypot fields are not by themselves enough to flag a request under that default. Setting it to `true` makes missing fields trigger spam detection. The configuration warns against doing this with global middleware unless every form includes the fields. That is a concrete operational constraint: stricter validation reduces tolerance for omitted markup but can reject legitimate requests that use an unprotected endpoint.

Configuration limits and failure cases in ProtectAgainstSpam

The package can be disabled with `HONEYPOT_ENABLED`, which defaults to `true`. That switch is useful for controlled diagnosis or temporary operational changes, but it leaves public forms without this package's protection. The README does not establish that one second of minimum completion time suits every form or network condition.

The random honeypot name reduces exposure to bots that know the default field, according to the configuration comments. It does not convert the approach into detection of sophisticated automation. A bot able to inspect visible and hidden controls, omit fields it recognizes as traps, and wait before submitting can bypass the documented checks. The timing rule creates a different boundary: a client that submits immediately without loading or completing the form can be classified as spam even when no human filled the honeypot.

Response behavior also deserves review. `BlankPageResponder` is the default, so a flagged form can result in a blank page rather than a validation error or explicit rejection message. This is suitable only if the product does not need to explain rejection to the submitting client. The README names the responder interface but does not describe retry handling, status codes, logging, or custom responder examples.

The global middleware warning is the clearest deployment hazard. If `honeypot_fields_required_for_all_forms` is enabled while middleware covers routes whose forms do not render the fields, valid requests can be marked as spam. Scope protection to protected form endpoints or ensure every form covered by that policy emits the required values.

Maintenance, licensing, and the difference from a custom honeypot

The repository is not archived. Its last push was on 2026-09-11, and the listed releases include 4.7.3 on 2026-09-11, 4.7.2 on 2026-06-25, and 4.7.1 on 2026-02-27. This indicates recent repository activity, but the README does not describe the changes, compatibility boundaries, or upgrade procedure contained in those releases. The repository includes `CHANGELOG.md` and `UPGRADING.md`, but their contents are not shown here, so the cost of moving to a newer package version cannot be assessed from the README alone.

The project uses the MIT license. That identifies the published license, but application owners remain responsible for reviewing the full `LICENSE.md` and complying with its terms and any included notices. No legal interpretation is needed to reach the narrower technical point: this is a reusable library dependency that should be managed through the application's normal Composer update process.

A real alternative is a custom hidden field implemented directly in the application. That approach requires the developer to define the field name, render it, inspect the request, choose a response, and possibly add a timestamp rule. spatie/laravel-honeypot packages those responsibilities as a Blade component, route middleware, configuration, a randomized field-name option, and a replaceable `SpamResponder`. The trade-off is dependency on package configuration and upgrade compatibility instead of owning every rule in application code.

Editorial conclusion

Adopt spatie/laravel-honeypot for public Laravel forms that accept simple browser submissions and can tolerate the documented blank-page response. Do not adopt it as the sole control for abuse that does not fill hidden fields or respect submission timing. Before integration, verify that protected routes include `ProtectAgainstSpam`, every protected form renders `x-honeypot` or `@honeypot`, and the chosen `SpamResponder` produces an acceptable response.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. spatie/laravel-honeypot on GitHub