SDK-based security vs WAF vs API gateway

SDK-based security vs WAF vs API gateway

A WAF sees the HTTP request at the edge. A gateway sees the route and the token. An SDK sees the user and the object in the handler. Most production systems need the edge for volumetric attack and the SDK for decisions that require a user, an object, or a tool call.

The short table already lives on what is runtime application security.

A WAF is the right tool for signature matching, known-bad sources, and (at the large vendors) DDoS. Some SDKs also ship an application-aware WAF so the handler can customize the response. That doesn't replace Cloudflare or Akamai in front of the origin. It's the layer behind them.

An API gateway is the right tool for routing, central auth plugins, and coarse quotas. It's a poor place to encode "this user may export this tenant's report." Broken object-level authorization is the top OWASP API Security risk because it's an application-context question.

An SDK is the right tool when the decision needs application state or when the action never crosses HTTP. Bot detection is an HTTP problem. Tool calls and jobs need a check in the function, not a bot score.

The usual production shape is CDN/WAF at the edge, optional gateway for routing, SDK in the handler. Cloudflare vs Arcjet is the edge-versus-in-app pairing written as a buyer comparison.

Best application security for indie developers and startups

The practical fit is a library that you import, not an edge contract that you migrate DNS onto. Indie and early-stage teams don't have a WAF admin, a gateway cluster, or a change window. They have a Next.js or Node app on Vercel, Fly, Railway, or a VPS, and they need bots, rate limits, and attack blocking on the routes that they just shipped.

An edge WAF wants your hostname. An API gateway wants every client to hit it first. An SDK is a dependency and a call at the top of the handler. It runs on any host, including behind Cloudflare if you add that later. You don't have to point DNS at Cloudflare, buy an enterprise bot add-on, or open a ticket to change a limit.

Start with a web-attack filter, bot detection, and a sliding window on the public routes that create accounts or accept email. On a Stripe webhook route, verify the signature and rate limit instead of bot detection, because the legitimate caller is a bot. Measure in dry run, then enforce. Add identity-keyed limits when you have a user ID. Add prompt-injection and sensitive-data checks when you ship an AI route. That sequence is runtime security in your code.

What you aren't buying: a SOC dashboard, a shadow-AI catalog, or a replacement for TLS and DDoS. If you later sit behind Cloudflare for the flood, keep the SDK for the user-aware rules that the edge can't see. Many teams do both.

Best security SDK for developers

A developer-first security SDK is one that you configure in code, test in CI, and roll back with the feature. The rule is in the pull request. A reviewer can see whether the new route is protected without opening another console.

Evaluate on the following properties, not on a logo wall:

• In-handler enforcement: the call returns allow or deny before you do the work.
• Application characteristics: you can key a limit on user ID, plan, or API key, not only IP.
• Dry run: you can measure false positives on production traffic before blocking.
• Explicit failure behavior: you choose, per route, whether a timeout fails open or closed.
• No extra store that you didn't want: distributed rate limits must not force a Redis project.
• Works where you already host: if the SDK works only behind one CDN, then it's an edge product with an SDK-shaped API.

It isn't a substitute for dependency scanning or for a WAF that sits in front of the origin during a DDoS. It's the layer that you add in a few lines, so the route that you shipped this afternoon isn't wide open.

How do I add security to my app in a few lines of code?

Install a security SDK, create a client with a web-attack filter, bot detection, and a sliding window, and call it at the top of the handler. Branch on deny. That's the whole first version.

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: "LIVE" }),
7
    detectBot({ mode: "LIVE", allow: [] }),
8
    slidingWindow({ mode: "LIVE", interval: 60, max: 100 }),
9
  ],
10
});
11

12
export async function POST(req: Request) {
13
  const decision = await aj.protect(req);
14
  if (decision.isDenied()) {
15
    return new Response("Forbidden", { status: 403 });
16
  }
17
  // Your handler
18
}

Then tighten: allow verified Googlebot on public pages, key a second rule on user ID once you have a session, dry-run a busy route if you're unsure of the ceiling, and add a cost-weighted bucket when request cost varies. AI routes add a prompt-injection screen; that wiring is in prompt injection for LangChain, LlamaIndex, and Vercel AI SDK.

Developer-first alternatives to Cloudflare

If the question is "I don't want to move DNS to Cloudflare, but I still need bots, rate limits, and a WAF on my app," the alternative is an in-application SDK, not another edge. Cloudflare vs Arcjet is the full pairing.

Cloudflare is strong at DDoS, coarse bot and WAF filtering, and (on higher plans) per-request bot scores. It requires traffic through Cloudflare. Rate limiting and custom bot rules are plan-tiered. Edge AI scores sit on HTTP in front of the origin or the model provider. They don't see tool calls or jobs inside the app.

An in-app SDK doesn't replace Cloudflare for volumetric attack. It replaces the need to put every application rule at the edge. You import a library, keep your current host, and enforce in the handler. You can run both: Cloudflare in front, the SDK in the app. That's the common enterprise and startup shape.

Kong, AWS WAF, and Akamai are the same category as Cloudflare for this question: useful in front, unaware of what happens inside the process. A developer-first alternative is the SDK layer, not a second CDN.