Arcjet bot detection allows you to manage traffic by automated clients and bots.
Configuration
Bot detection is configured by allowing or denying a subset of bots. The allow
and deny lists are mutually-exclusive, such that using allow will result in
a DENY decision for any detected bot that is not specified in the allow list
and using deny will result in an ALLOW decision for any detected bot that is
not specified in the deny list.
You can use only one of the following configuration definitions:
The arcjet client is configured with one or more detectBot rules which take
one or many BotOptions.
Only allowing specific bots
Most applications want to block almost all bots. However, it is common to allow
some bots to access your system, such as bots for search indexing or API
access from the command line.
This behavior is configured with an allow list from our full list of
bots.
Some applications may only want to block a small subset of bots, while allowing
the majority continued access. This may be due to many reasons, such as
misconfigured or high-traffic bots.
This behavior is configured with an deny list from our full list of
bots.
Bot protection rules can be configured in two ways:
Per route: The rule is defined in the route handler itself. This allows
you to configure the rule alongside the code it is protecting which is useful
if you want to use the decision to add context to your own code. However, it
means rules are not located in a single place.
Hooks: The rule is defined as a hook. This allows you to
configure rules in a single place or apply them globally to all routes, but
it means the rules are not located alongside the code they are protecting.
If you use Arcjet in hooks and individual routes, you need to be careful
that Arcjet is not running multiple times per request. This can be avoided by
excluding the individual routes before running Arcjet in the hook.
For example, if you already have rules defined in the API route
at /api/arcjet, you can exclude it from the hook like this:
Decision
The quick start example will deny requests
that match the bot detection rules, immediately returning a response to the
client using SvelteKit hooks.
Arcjet also provides a single protect function that is used to execute your
protection rules. This requires a RequestEvent property which is the event
context as passed to the request handler.
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 IP analysis in the
SDK reference for more information.
The decision also contains all of the identified
bots detected from the request. A request may
be identified as zero, one, or more bots—all of which will be available on the
decision.allowed and decision.denied properties.
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 type and you can check the reason property for more information, like
accessing decision.reason.message.
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.