Skip to content

Signup form protection reference

Arcjet signup form protection combines rate limiting, bot protection, and email validation to protect your signup forms from abuse.

Signup form protection is a combination of the rate limiting, bot protection, and email validation primitives. The configuration options are the same as those primitives.

In JavaScript and TypeScript, you configure those options in a single protectSignup rule. In Python, protect_signup forwards the same options to the three rules and returns a tuple that you unpack into rules.

The configuration definition is:

interface ProtectSignupOptions {
bots?: BotOptions;
email?: EmailOptions;
rateLimit?: SlidingWindowRateLimitOptions;
}

The arcjet client is configured with one protectSignup rule which takes ProtectSignupOptions.

For most signup forms, we recommend the following configuration:

  • Block emails with invalid syntax, that are from disposable email providers, or do not have valid MX records configured.
  • Block clients that we are sure are automated.
  • Apply a rate limit of 5 submissions per 10 minutes from a single IP address.

This can be configured as follows:

When you are testing your signup form protection configuration, you can run the rules in dry run mode first by setting mode to DRY_RUN. This returns an allow decision for every request, but logs what the results would have been if they were in live mode. You can view the results in the Arcjet dashboard.

Even in dry run mode Arcjet still evaluates each rule, so you can still check the rule results to see if the email address is valid or not, or log them to your database.

Arcjet provides a single protect function that is used to execute your protection rules. This requires a request argument which is the request context as passed to the request handler. When you configure signup form protection, protect also requires an email argument.

This function returns a Promise that resolves to an ArcjetDecision object. This contains the following properties:

  • id (string) – The unique ID for the request. This can be used to look up the request in the Arcjet dashboard. It is prefixed with req_ for decisions involving the Arcjet cloud API. For decisions taken locally, the prefix is lreq_.
  • conclusion (ArcjetConclusion) – The final conclusion based on evaluating each of the configured rules. If you wish to accept Arcjet’s recommended action based on the configured rules then you can use this property.
  • reason (ArcjetReason) – An object containing more detailed information about the conclusion.
  • results (ArcjetRuleResult[]) – An array of ArcjetRuleResult objects containing the results of each rule that was executed.
  • ip (ArcjetIpDetails) – An object containing Arcjet’s analysis of the client IP address. For more information, see the SDK reference.

The conclusion property contains the final conclusion based on evaluating each of the configured rules. The example code in the quick start uses this property to accept Arcjet’s recommended action: display an error to the user if their email is rejected, otherwise return a 403 error.

To check whether a deny decision was returned, use decision.isDenied() (JS) / decision.is_denied() (Python). To narrow down the reason to an email validation rule, use decision.reason.isEmail() (JS) / decision.reason_v2.type == "EMAIL" (Python).

You can iterate through the results of each rule:

for (const result of decision.results) {
console.log("Rule Result", result);
}

This could be useful metadata to add to a new user’s record in your database before you redirect them to the next step in your signup flow.

Checking the rule results lets you use the Arcjet decision as part of your own verification logic. For example, you could decide to manually verify user signups that come from IP addresses associated with proxies or Tor, and any users who sign up with a free email address.

Arcjet is designed to fail open so that a service issue or misconfiguration does not block all requests. The SDK also times out and fails open after 2000 ms by default. However, in most cases, the response time is less than 20 ms to 30 ms.

If there is an error condition when processing the rule, Arcjet returns an ERROR result for that rule and you can check the message property on the rule’s error result for more information.

If all other rules that were run returned an ALLOW result, then the final Arcjet conclusion is ERROR.

Arcjet runs the same in any environment, including locally and in CI. You can use the mode set to DRY_RUN to log the results of rule execution without blocking any requests.

We have an example test framework you can use to automatically test your rules. Arcjet can also be triggered based using a sample of your traffic.

For details, see the Testing section of the docs.

Discussion