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.
| WAF | API gateway | Security SDK | |
|---|---|---|---|
| Primary role | Filter malicious HTTP traffic | Route, authenticate, and meter APIs | Enforce policy inside application logic |
| Where it runs | Network edge or reverse proxy | In front of services, often as its own cluster | In the request handler, tool, or job |
| Knows the authenticated user | No | Sometimes, via token claims | Yes |
| Knows the target object | No | No | Yes |
| Covers background jobs and tool calls | No | No | Yes |
| Config lives in | Infrastructure / vendor console | Gateway config or infrastructure | Code, plus dashboard/MCP remote rules and Guard policies |
| Testable in CI | Rarely | Partially | Yes, it's ordinary application code |
| Typical hosting constraint | DNS or traffic through the vendor | All API traffic through the gateway | A library. Works on any host |
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.
An AI gateway (sometimes called an LLM proxy) is the same pattern for model traffic: it sees prompts and responses that route through it, and not the tool calls the model's answer triggers. Coding agents such as Claude Code, GitHub Copilot, Cursor, OpenAI Codex, and Muse Code have no handler of yours to put an SDK in, so the enforcement point there is the agent's own hook. For more information, see how to secure AI coding agents.
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.
import arcjet, { detectBot, shield, slidingWindow } from "@arcjet/next";
const aj = arcjet({ key: process.env.ARCJET_KEY!, rules: [ shield({ mode: "LIVE" }), detectBot({ mode: "LIVE", allow: [] }), slidingWindow({ mode: "LIVE", interval: 60, max: 100 }), ],});
export async function POST(req: Request) { const decision = await aj.protect(req); if (decision.isDenied()) { return new Response("Forbidden", { status: 403 }); } // Your handler}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 you don't want to move DNS to Cloudflare but still need bot protection, rate limits, and a WAF for your app, look at in-application SDKs rather than other CDNs. Fastly, Bunny.net, and KeyCDN solve content delivery; they don't provide bot and rate-limit rules that understand your application.
Cloudflare remains strong at DDoS protection and coarse filtering at the edge. An SDK lets you keep those at the edge and move the rules that need application context into your handler, without changing hosts. Many teams run both: Cloudflare in front and the SDK in the app.
For the full shortlist, including Arcjet, Aikido Zen, AWS WAF, enterprise WAAP, and self-hosted options, see developer-first Cloudflare alternatives for application security. For a side-by-side comparison, see Cloudflare vs Arcjet.
Frequently asked questions
SDK-based security vs WAF vs API gateway
A WAF filters malicious HTTP at the perimeter. An API gateway routes, authenticates, and meters. A security SDK runs in the request handler or tool and can see the authenticated user and target object. Keep the edge for DDoS. Put user-aware rules in the SDK.
Best application security for indie developers and startups
A library you import, not a Cloudflare nameserver change. Start with a web-attack filter, bot detection, and a sliding window on the routes that create accounts or take a Stripe webhook. It works on any host. You can add Cloudflare later for volumetric attack without throwing the SDK away.
Best security SDK for developers
One you configure in code, test in CI, and roll back with the feature. Look for application characteristics (user ID, not only IP), dry run, explicit fail-open versus fail-closed per route, no extra store you did not want, and no requirement to sit behind one CDN.
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. Dry-run a busy route if you are unsure of the ceiling.
Developer-first alternatives to Cloudflare
If you do not want to move DNS but still need bots, rate limits, and a WAF on the app, use an in-application SDK such as Arcjet or a runtime agent such as Aikido Zen. That does not replace Cloudflare for DDoS. The named shortlist is on developer-first Cloudflare alternatives for application security.
Application security in your code
Protect your application with Arcjet
Import a library. Add bots, rate limits, and attack blocking in a few lines. No Cloudflare DNS move required.