Arcjet filters
Arcjet filters let you block requests using
Wireshark-like display
filter
expressions over HTTP headers, IP addresses, and other request fields. This
allows you to quickly enforce rules like allow/deny by country, network, or
user-agent.
Why use filters?
Section titled “Why use filters?”You can use filters to block unwanted traffic inside your application code with Arcjet.
Filters have access to literal request fields such as the
user-agent header and the request IP address. With these fields you can, for
example, block a particular bot or user agent. This is similar to programming
code yourself but with filters these cases integrate with the rest of Arcjet.
Filters also have access to reflected fields such as the country of the request IP address and whether that is a known VPN or relay service. With these fields you can block based on geolocation and other analysis.
This is similar to accessing the ip field on an Arcjet decision and manually
handling requests in your application code. The difference is that with filters
the blocking is integrated with other rules, whereas decision.ip fields are
better for customizing the response such as showing a particular message. See
the VPN & proxy detection blueprint for an
example.
How does it work?
Section titled “How does it work?”The domain-specific language (DSL) is described in the Filters reference.
We use our Rust crate arcjet/wirefilter to match filters.
That crate is a fork of cloudflare/wirefilter,
modified to support an “undetermined” state for fields that are not available.
Is any data sent to the cloud?
Section titled “Is any data sent to the cloud?”All ip.src.* fields reflect information about the client
IP address (the request source IP). These fields require data from our IP
reputation database so a call to the Cloud API is required. Other fields are
analyzed locally.
Arcjet only ever makes a single call to our Cloud API regardless of the rule configuration. The Cloud API has been designed for high performance and low latency, and is deployed to multiple regions around the world. The SDK will automatically use the closest region which means the total overhead is typically no more than 20-30ms, often significantly less. See the Architecture reference for details.