Skip to content

Shield WAF reference

Arcjet Shield WAF protects your application against common attacks, including the OWASP Top 10.

Shield is configured by specifying which mode you want it to run in.

The arcjet client can be configured with one or more Shield rules, which are constructed with the shield(options: ShieldOptions) function and configured by ShieldOptions:

type ShieldOptions = {
mode?: ArcjetMode | undefined;
};
type ArcjetMode = "LIVE" | "DRY_RUN";

Per route versus hooks

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 lets you 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.

Per route

This configures bot protection on a single route.

Hooks

This runs on every request to your SvelteKit app – see the SvelteKit Hooks docs for details.

Avoid double protection with hooks

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 a shield rule defined in the API route at /api/arcjet, you can exclude it from the hook like this:

Arcjet 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. For more information, see the SDK reference.

To check whether a shield rule returned a deny conclusion, use decision.isDenied() and decision.reason.isShield() (JS) / decision.is_denied() and decision.reason_v2.type == "SHIELD" (Python).

You can iterate through the results and check whether a shield rule was applied:

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

This example logs the full result as well as the shield rule:

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.