---
title: "API Security"
description:
  "Edge-native API security: schema validation, multi-method authentication, rate limiting, bot protection. Explore practical implementation details and tradeoffs."
canonicalUrl: "https://zuplo.com/features/api-security"
sourceUrl: "https://zuplo.com/features/api-security"
pageType: "feature"
generatedAt: "2026-10-21"
---

# Every threat blocked before it reaches your origin

> Your origin is the worst place to discover a malicious request. Authenticate, validate, and filter every call at the edge — so attacks, abuse, and malformed traffic never reach your servers.

## Security spread across vendors is security with seams

Most API security looks like a stack of half-overlapping products: an auth service here, schema checks in code, rate limits on the gateway, bot rules somewhere else. The seams are where breaches happen. Zuplo collapses the layers into one edge runtime — every check runs against the same request, in the same place, with the same audit.

The problems:

- **Security in three places, slightly wrong in each.** Auth in one console, rate limits in another, schema validation in the application code. Three policies that should match, almost match, and the difference is the bug bounty.
- **Origin reachable from anywhere.** Your API is behind a SaaS gateway. Your origin is on the public internet. Anyone who finds the origin's IP bypasses every security control. Penetration tests find this. Auditors hate it.
- **Schema drift = silent vulnerabilities.** The OpenAPI spec says required: customerId. The handler trusts that. Three deploys later, the gateway lets the field through as null, and a missing-tenant authorization bug ships.
- **Static service-account keys everywhere.** The gateway authenticates to your backend with a JSON key sitting in someone else's secret store, rotated annually if you remember, scoped permissively because nobody could narrow it down.

## One pipeline, layered defense

- **One enforcement layer, every threat.** Auth, schema validation, rate limiting, bot detection, and workload identity federation all run in the same policy pipeline at the edge. One audit, one source of truth, one place to harden.
- **Origin invisible to the public.** Run mTLS, a WireGuard secure tunnel, or workload identity federation between the gateway and your backend — your origin stays private, the gateway stays public, and only authenticated, validated traffic gets through.
- **Auditor-ready by default.** SOC 2 Type II runtime, immutable audit logs, SAML SSO, SCIM, project-level RBAC, region-pinned execution. The compliance package mostly assembled before the first auditor email.

## Layered defenses on the same request, in the order you want them

Stack schema validation, authentication, authorization, rate limiting, and bot detection on a single route — they fire in the order you choose. A rejected request returns a 4xx with full context; the rest of the chain still runs in observability-only mode so you see the full posture, not just the first failure.

Layered security on one route (`routes.oas.json`):

```json
{
  "x-zuplo-route": {
    "policies": {
      "inbound": [
        "request-validation-inbound",
        "open-id-jwt-auth-inbound",
        "custom-rbac-inbound",
        "rate-limit-inbound",
        "audit-log-inbound"
      ]
    }
  }
}
```

Layers shown: DDoS (global edge network), schema validation (OpenAPI), JWT / OAuth / API key, custom RBAC (TypeScript), rate limit (per consumer), bot detection (UA + behavior).

## Security for the AI traffic too

Prompt injection, jailbreak attempts, and PII leaks need the same edge enforcement as a SQLi attempt. The AI Gateway runs on the same policy pipeline — guardrails, semantic firewalls, and token-aware rate limits compose with the rest of your security stack.

- Prompt-injection detection on every chat call
- PII redaction before traffic leaves your origin
- Token-counted rate limits via setIncrements (1 LLM call ≠ 1 unit of budget)
- Audit log every guardrail event with the offending prompt

Links: [Explore AI Gateway](/ai-gateway) · [AI Gateway docs](https://zuplo.com/docs/ai-gateway/introduction)

## Deep dives

- [Authentication](/features/authentication) — API keys, JWT, OAuth, mTLS, custom RBAC
- [API Key Management](/features/api-key-management) — Edge-validated, leak-detected, self-serve
- [Backends & Resilience](/features/backends) — Workload identity federation, mTLS, tunnels
- [Rate Limiting](/features/rate-limiting) — Per-IP, per-key, per-token, monthly quotas

## Security that fits how modern API teams work

- **The gateway is the perimeter.** Every check runs inside the gateway runtime across 300+ data centers — no envoy filter to deploy, no sidecar to patch, no Helm chart to keep in sync. The gateway IS the security perimeter, not just a thing in front of one.
- **Workload identity federation, not static secrets.** Skip the service-account JSON in env vars. The gateway exchanges its identity for short-lived backend credentials per request — Workload Identity Federation for GCP, OAuth client credentials for Azure AD, Zuplo-signed JWTs for your own services. Layer mTLS or a WireGuard tunnel for transport trust on top.
- **Schema-as-contract validation.** Your OpenAPI document is the source of truth. The Request Validation policy enforces it at the edge — required fields, types, enums, JSON Schema. Configurable per parameter (reject-and-log, log-only). One spec governs both your docs and your gateway.
- **Programmable RBAC, not a rules engine.** Custom authorization is a TypeScript function with full access to request.user, headers, body, environment variables, and ZoneCache. Pin its behavior with the built-in zuplo test runner — real HTTP assertions against a real deployment, in your repo beside the policy. Review it like any other code. No drag-and-drop policy builders.

## What teams use this for

> "We need auth, schema validation, and rate limiting, but they live in three vendors."

All three are policies on the same Zuplo route. Request Validation enforces your OpenAPI schema; auth validates JWTs or API keys at the edge; rate-limit-inbound throttles with retry-after. One config block. One audit trail.

> "Compliance asks for proof every public route requires auth."

Run an OpenAPI lint rule (Spectral or Vacuum) in your CI that fails the build if any operation lacks an auth policy attachment. Pair with the Request Validation policy and you have a CI gate plus an edge enforcement gate — auditor-ready.

> "Our origin's cloud IAM service-account key is making security nervous."

Replace it with the Upstream GCP Federated Auth policy. Zuplo mints a token via Workload Identity Federation and exchanges it for GCP credentials at the edge — no JSON key, no static secret, no secret-rotation cron.

> "Schema-validation bugs keep slipping into production."

Enable Request Validation in log-only mode against your OpenAPI spec, watch the logs for a week, then flip to reject-and-log once you've cleaned up the surprises. Drift detection becomes part of the deploy pipeline.

## Frequently Asked Questions

### How do I secure an API?

API security is layered: authentication and authorization for every request, schema validation to block malformed inputs, rate limits and quotas to stop abuse, and audit logging for forensics. Doing this in your application code is unmaintainable; doing it in five different vendors is expensive. An API gateway like Zuplo enforces all of these layers in one runtime at the edge — before traffic ever reaches your origin.

### How do I prevent API abuse, scraping, and DDoS attacks?

Three layers: volumetric DDoS protection (handled by the global edge network Zuplo runs on), rate limits and quotas at the gateway (per-IP, per-API-key, per-tenant), and bot/abuse detection via custom TypeScript policies. Block bad actors at the edge before they cost you origin compute or bandwidth. See [/features/rate-limiting](/features/rate-limiting) for the limit-and-quota deep-dive.

### How do I validate request payloads against an OpenAPI schema?

Define your OpenAPI spec, attach a request-validation policy to your routes, and the gateway enforces required fields, types, formats, enums, and JSON Schema constraints before traffic hits your origin. Invalid requests get a 400 with a structured error body in milliseconds; your backend never sees malformed input. Run in log-only mode first to catch existing client bugs without breaking traffic.

### How do I authenticate API requests?

Pick the right method per audience — API keys for B2B partners, JWT/OAuth 2.0 for human users, OIDC SSO for enterprise, mutual TLS for high-security partners — and let the gateway validate at the edge. Zuplo supports every common method out of the box, plus custom TypeScript for any auth scheme that's not on the list. See [/features/authentication](/features/authentication) for the full breakdown.

### How does Zuplo connect securely to private backends?

Zuplo can authenticate to your backend with workload identity federation (GCP, AWS, Azure — no static secrets), Zuplo-signed JWTs your backend verifies, mutual TLS, or a WireGuard tunnel into your private network. Combined with allowlists, your backend trusts the gateway as a known caller and rejects anything else. See [/features/backends](/features/backends) for connection patterns.

### Is Zuplo SOC 2 compliant and what compliance frameworks does it support?

Zuplo is SOC 2 Type II certified. Beyond that, the platform supports HIPAA, GDPR, and enterprise security reviews via SAML SSO, SCIM provisioning, project-level RBAC, immutable account audit logs with full actor and resource context, exportable to your SIEM. TLS 1.2+ everywhere, secrets encrypted at rest, regional data residency available on dedicated and self-hosted deployments. Trust Center at trust.zuplo.com.

### What's the best API security gateway?

Look for: auth + rate limiting + schema validation in one runtime; first-class support for your IdP; private-backend connectivity (mTLS, workload identity federation, WireGuard); audit logs to your SIEM; SOC 2 Type II. Zuplo combines all of these and runs them in 300+ edge data centers. AccuWeather, BlockDaemon, and BancoSol use it as the security perimeter for their public APIs. Talk to a security expert for a fit assessment.

## Next steps

Free Zuplo project, point it at your origin, and you have auth, schema validation, and rate limiting in front of it before lunch.

- [Start for Free](https://portal.zuplo.com/signup)
- [Talk to a Security Expert](/schedule-call)
- [Read the Docs](https://zuplo.com/docs/articles/policies)