Skip to content

Signup from protection reference

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

Configuration

Signup form protection is a combination of the rate limiting, bot protection, and email validation primitives. The configuration options are the same, but specified in a single rule.

The configuration definition is:

type ProtectSignupOptions = {
rateLimit?: SlidingWindowRateLimitOptions | SlidingWindowRateLimitOptions[];
bots?:
| BotOptionsAllow
| BotOptionsDeny
| BotOptionsAllow[]
| BotOptionsDeny[];
email?: EmailOptions | EmailOptions[];
};

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

Our recommended configuration for most signup forms is:

  • 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:

Testing with dry run mode

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 will return an allow decision for every request, but log 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 each rule will still be evaluated, so you can still check the rule results to see if the email address is valid or not, or log them to your database.

Decision

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 configured with a protectSignup rule it also requires an additional email prop.

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. See the SDK reference for more information.

The conclusion property contains the final conclusion based on evaluating each of the configured rules. The quick start example code above 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.

You can check if a deny decision was returned by using decision.isDenied(). To narrow down the reason to an email validation rule, you can use decision.reason.isEmail().

Checking rule results

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.

See the SDK reference for more details about the rule results.

Custom verification logic

Checking the rule results allows you to 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.

Error handling

Arcjet is designed to fail open so that a service issue or misconfiguration does not block all requests. The SDK will also time out and fail open after 1000ms when NODE_ENV or ARCJET_ENV is development and 500ms otherwise. However, in most cases, the response time will be less than 20-30ms.

If there is an error condition, Arcjet will return an ERROR conclusion.

Testing

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.

See the Testing section of the docs for details.

Discussion