How to add app security in a few lines of code

How do you add security to an app in a few lines of code?

Arcjet publishes this guide and sells the SDK it uses in the examples. The same steps apply to any in-application security library, and the final section covers when a few lines of code isn't the right approach.

You add security in a few lines of code by installing a security SDK, creating one client with the rules you want, and calling it at the top of each handler you need to protect. The client returns a decision, and your code allows the request, returns an error, or asks for more proof. There's no proxy to deploy and no DNS change, and the rules live in the same pull request as the feature they protect.

The pattern has four parts:

1. Install the SDK for your framework and set an API key as a secret.
2. Configure a client once, with rules such as a WAF, bot detection, and a rate limit.
3. Call protect() in each route handler, or guard() in a tool call or background job.
4. Act on the decision: continue, return a 403 or 429, or fall back to a safer path.

Start each rule in dry-run mode, which logs what the rule would have done without blocking anything. Switch it to live once you've reviewed a few days of real traffic.

What can a few lines of code protect against?

Each rule is one line in the client configuration. The following rules are the usual starting point for a web app or API:

A few lines of code won't fix an authorization bug, absorb a volumetric DDoS attack, or patch a vulnerable dependency. Keep your authorization checks, your hosting provider's DDoS protection, and your dependency scanner. The SDK adds the rules that need to know about the request and the user, which edge products and scanners can't see.

How do you add security to a Next.js route?

Install the SDK and add your key to .env.local. Don't prefix it with NEXT_PUBLIC_, which would ship it to the browser.

1
npm i @arcjet/next

1
ARCJET_KEY=ajkey_your_site_key

Create the client once, then call it at the top of the route handler:

1
import arcjet, { detectBot, shield, slidingWindow } from "@arcjet/next";
2

3
const aj = arcjet({
4
  key: process.env.ARCJET_KEY!,
5
  rules: [
6
    shield({ mode: "DRY_RUN" }),
7
    detectBot({ mode: "DRY_RUN", allow: ["CATEGORY:SEARCH_ENGINE"] }),
8
    slidingWindow({ mode: "DRY_RUN", interval: 60, max: 100 }),
9
  ],
10
});
11

12
export async function POST(req: Request) {
13
  const decision = await aj.protect(req);
14

15
  if (decision.isDenied()) {
16
    const status = decision.reason.isRateLimit() ? 429 : 403;
17
    return new Response("Request blocked", { status });
18
  }
19

20
  // Your handler
21
  return Response.json({ ok: true });
22
}

That's three rules and one check at the top of the handler. The rules run in dry-run mode, so every request still succeeds and each decision appears in the Arcjet dashboard. When the results look right, change "DRY_RUN" to "LIVE" one rule at a time.

How do you add security to a Python API?

The Python SDK supports FastAPI and Flask. Install it with pip install arcjet or uv add arcjet, then configure the client:

1
import os
2

3
from arcjet import Mode, arcjet, detect_bot, shield, token_bucket
4
from fastapi import FastAPI, Request
5
from fastapi.responses import JSONResponse
6

7
app = FastAPI()
8

9
aj = arcjet(
10
    key=os.environ["ARCJET_KEY"],
11
    rules=[
12
        shield(mode=Mode.DRY_RUN),
13
        detect_bot(mode=Mode.DRY_RUN, allow=[]),
14
        token_bucket(mode=Mode.DRY_RUN, refill_rate=10, interval=60, capacity=20),
15
    ],
16
)
17

18

19
@app.post("/api/search")
20
async def search(request: Request):
21
    decision = await aj.protect(request)
22

23
    if decision.is_denied():
24
        status = 429 if decision.reason_v2.type == "RATE_LIMIT" else 403
25
        return JSONResponse({"error": "Request blocked"}, status_code=status)
26

27
    return {"results": []}

An empty allow list blocks every automated client, including curl. If you need uptime monitors or link previews, add their categories to allow before you switch the rule to live.

How do you add security to a Go service?

Install the module with go get github.com/arcjet/arcjet-go, create one client, and reuse it across requests:

1
package main
2

3
import (
4
  "log"
5
  "net/http"
6
  "os"
7
  "time"
8

9
  "github.com/arcjet/arcjet-go"
10
)
11

12
var aj, _ = arcjet.NewClient(arcjet.Config{
13
  Key: os.Getenv("ARCJET_KEY"),
14
  Rules: []arcjet.Rule{
15
    arcjet.Shield(arcjet.ShieldOptions{Mode: arcjet.ModeDryRun}),
16
    arcjet.DetectBot(arcjet.BotOptions{
17
      Mode:  arcjet.ModeDryRun,
18
      Allow: []string{arcjet.BotCategorySearchEngine},
19
    }),
20
    arcjet.SlidingWindow(arcjet.SlidingWindowOptions{
21
      Mode:        arcjet.ModeDryRun,
22
      Interval:    time.Minute,
23
      MaxRequests: 100,
24
    }),
25
  },
26
})
27

28
func handler(w http.ResponseWriter, r *http.Request) {
29
  decision, err := aj.Protect(r.Context(), r)
30
  if err != nil {
31
    log.Printf("arcjet: %v", err)
32
  } else if decision.IsDenied() {
33
    status := http.StatusForbidden
34
    if decision.Reason.IsRateLimit() {
35
      status = http.StatusTooManyRequests
36
    }
37
    http.Error(w, "request blocked", status)
38
    return
39
  }
40

41
  w.Write([]byte("ok"))
42
}

Interval is a time.Duration, so write time.Minute rather than 60, which Go reads as 60 nanoseconds. In production, check the error from NewClient instead of discarding it.

How do you protect code that has no HTTP request?

Tool calls, queue consumers, and MCP servers never receive a Request object, so protect() doesn't apply. Use guard() from @arcjet/guard instead. It takes the values you want to check directly:

1
import {
2
  detectPromptInjection,
3
  launchArcjet,
4
  tokenBucket,
5
} from "@arcjet/guard";
6

7
const arcjet = launchArcjet({ key: process.env.ARCJET_KEY! });
8
const promptInjection = detectPromptInjection();
9
const lookups = tokenBucket({
10
  bucket: "order-lookups",
11
  refillRate: 30,
12
  intervalSeconds: 60,
13
  maxTokens: 30,
14
});
15

16
export async function lookupOrder(
17
  args: { orderId: string; note: string },
18
  session: { userId: string },
19
) {
20
  const decision = await arcjet.guard({
21
    label: "tools.lookup-order",
22
    actor: session.userId,
23
    rules: [
24
      lookups({ key: session.userId, requested: 1 }),
25
      promptInjection(args.note),
26
    ],
27
  });
28

29
  if (decision.conclusion === "DENY" || decision.hasFailedOpen()) {
30
    return { error: "Lookup blocked" };
31
  }
32

33
  return orders.find({ id: args.orderId, userId: session.userId });
34
}

A direct guard() call fails open by default: if Arcjet can't be reached, it returns an allow with error codes. Checking hasFailedOpen() makes this tool fail closed instead, which suits actions that change data or cost money. For framework-specific helpers, see the LangChain, Vercel AI SDK, and Mastra guides.

How do you roll it out without breaking production?

1. Deploy every rule in dry-run mode. Dry-run rules compute and record a decision but always return allow.
2. Review a few days of decisions. Look for real users who would have been blocked – shared office IPs, monitoring tools, and partner integrations are the usual surprises.
3. Switch one rule at a time to live. If support tickets rise, you know which rule caused it.
4. Decide how each route handles errors. HTTP checks fail open by default, which suits most pages. For a route where an unchecked request is worse than a failed one, treat an errored decision as a deny.
5. Keep the edge in front. Your CDN or cloud provider still handles volumetric DDoS; the SDK handles the rules that depend on your application.

What to check before you go live

• The key is a secret. Store ARCJET_KEY in your platform's secret manager, and never in a variable that ships to the browser.
• Client IPs are correct. Behind a load balancer or proxy, confirm the dashboard shows real public IP addresses, not your proxy's. For platform-specific setup, see securing Fly.io apps and detecting the client IP on Firebase.
• Allowed bots are explicit. Search engines, uptime monitors, and link previews need to be on the allow list if you want them.
• Rate-limit keys match your users. An IP-keyed limit punishes users behind a shared IP; key the limit to a user ID once people sign in.
• The SDK version is pinned. Pin the major version so an upgrade is a deliberate change.

When is a few lines of code the wrong approach?

• You can't change the application code. A WAF at the edge, or a runtime agent such as Aikido Zen that instruments the app, may be the only practical option.
• Your stack isn't JavaScript, TypeScript, Python, or Go. Arcjet's SDKs cover those languages; other stacks need an edge WAF or an HTTP-based service.
• You need to absorb large DDoS attacks. That belongs to your CDN or hosting provider.
• The risk is a vulnerable dependency or insecure code. A code scanner finds those before deploy; a runtime SDK doesn't.

For a comparison of the three places you can enforce security, see SDK-based security vs WAF vs API gateway. For the full setup in your framework, see the Arcjet get started guide.