Application security by Arcjet

Fresh Produce
,
1

Greetings from Arcjet. We’ve partnered with Fly.io as a security extension provider for JS applications (more runtimes coming soon). Check out the docs to give it a spin!

Fly does a load of security stuff for you - hardware isolation, encrypted networks, DDoS protection - but you still need to handle the application security. What if your app becomes popular and you need to apply limits to users, prevent scrapers and automated bots, and detect fraudulent signups?

That’s where Arcjet comes in. Arcjet is a security layer that protects apps with just a few lines of code.

It’s installed as a dependency in your application and doesn’t require an agent or any additional infrastructure. Check out the Javascript SDK for details on getting started. For when the SDK contacts our API it’s hosted on Fly.io for low latency.

What Arcjet can do

  • Signup form protection (docs) uses Arcjet’s server-side email verification configured to block disposable providers and ensure that the domain has a valid MX record. It also includes rate limiting and bot protection to prevent automated abuse.
  • Bot protection (docs) can block automated clients.
  • Rate limiting (docs) allows configuring limits which can be modified based on the request characteristics e.g. allowing a logged-in user to make more requests than an anonymous user.
  • Arcjet Shield (docs) is like a WAF which detects suspicious behavior, such as SQL injection and cross-site scripting attacks.

And it’s now integrated with Fly.

Get started

Our example app allows you to quickly try all the Arcjet functionality. You can see it running at example.arcjet.com and deploy it yourself:

# Clone our example app
git clone git@github.com:arcjet/arcjet-example-nextjs-fly.git`

# Create a new Fly app and generate the Next.js Dockerfile
fly launch --no-deploy

# Create an Arcjet account and link it to your Fly app
fly ext arcjet create

# Deploy!
fly deploy

This will create a new Arcjet account linked to your Fly account, set ARCJET_KEY as a secret on your Fly application, and then deploy the example app. See a quick run-through on YouTube.

Beta testing

We consider Arcjet ready for production, but we may make changes to the SDK, so we’re still labeling it beta. Sign up - let us know what you think.

The current features available today will be unlimited and free to use. Our goal is to help developers protect their applications so we don’t want you to incur costs if you are attacked.

Arcjet pricing will be based on the usage of features we intend to introduce in the future e.g. organization-wide rules, compliance tools, team management, etc.

Support

We’ll hang out in the Fly forums if you need help, but we’re also available on Discord and via email: support@arcjet.com

11 Likes
2

From General to Fresh Produce

3

Added nodejs, security

4

Is there a public benchmark to know how long it takes for Arcjet to process requests? If it takes a couple hundred(s) milliseconds of latency to process request for Arcjet SDK, then maybe that might be a huge footprint for some apps.

5

Hey @pmbanugo - our internal SLA for full round trip (including a decision) is 20ms, but it’s usually much lower than that because we route requests to stay within the same region where your app is deployed. Our API is deployed on Fly already, but not yet in every region, so if there are particular regions you’re interested in then let me know!

1 Like
6

I’d also add that some decisions can be taken entirely locally. The Arcjet SDK passes the request through a WebAssembly component running inside your environment (embedded in the SDK so you don’t need to manage it). It analyzes the request locally and can take decisions for some things like email validation and parts of the bot detection engine. This will depend on the rules you configure, but in that case the overhead is less than 1ms.

Decisions also get cached so subsequent requests can get a result without needing an API call.

Over time we’re aiming to have more analysis happening locally in WebAssembly. Then the API is more for reporting.

7

Will you be open sourcing the web assembly component? I didn’t see the source code for it in the repo, just the wasm files, so at the moment it’s effectively a black box inside the SDK that runs on customer machines.

8

We have thought about open sourcing it, but at the moment we don’t have any plans to. You can see the inputs & outputs in the SDK code and WASM is of course sandboxed, so the capabilities are visible.

9

What kind of decisions get cached and by what parameters?

On the product side, how would you say it’s different from Wafris? Any public roadmap I can see?

10

All deny decisions get cached based on a configurable client fingerprint. The TTL depends on the rule config e.g. for a rate limit it’ll use your rule time window config to set the TTL. We’re also experimenting with caching allow decisions for certain rules e.g. if we decide a client isn’t a bot then we could allow future requests for a short period before re-evaluating.

Our philosophy is that security functionality should be tightly integrated with the application. One part of this is setting rules in code (in the route they’re protecting, version controlled, and consistent across local, staging & prod environments). But the bigger reason is to be context aware, such as setting a rate limit based on pricing plan for the current authenticated user. This is why we integrate via an SDK where you can access the decision object with details about the result. You can then customize your logic based on the signals Arcjet returns e.g. flagging a new signup for manual review because the signup was via a Tor proxy.

Most other WAF products sit in front of your application so miss all that relevant context. That’s fine if you want a simple block/allow response, but is much more difficult to customize for your application.

I couldn’t find any specific Wafris docs around config and how you integrate it into your code, but one point to compare is that Wafris requires you to run & manage Redis. Arcjet requires no additional infrastructure.

1 Like
11

Arcjet sends sensitive data to their servers to do the processing while Wafris middleware does all the processing on your own servers.

This does mean that you need to setup your own redis instance which Wafris servers can access to load in configurations and to keep track of stats.

From a security and compliance perspective it seems Wafris could be easier to use as no sensitive data leaves your servers, though this is very much dependant on what regulations you are operating under.

1 Like
12

It depends what you mean by “sensitive data”. Arcjet currently processes the request headers remotely, not the body. This is where the WASM component is useful because we can process the more sensitive data in the body entirely in your environment.

Even so, the same compliance & security questions arise when you’re using most cloud services e.g. sending all your data through Cloudflare’s network for processing. I’d be happy to chat with anyone about any compliance questions.

1 Like
13

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.