How to Secure an API Gateway: A Practical Checklist

Securing an API gateway means controlling who can call your API, what they can do once they're in, and how quickly you can detect and stop abuse. In practice this comes down to five layers: authentication, authorization, rate limiting, transport security, and logging/monitoring. Get those five right and you've closed most of the doors attackers actually try.

This article walks through each layer with concrete steps you can apply whether you're running Kong, AWS API Gateway, Nginx, or a managed gateway sitting in front of a third-party API like Claude.

1. Authenticate every request

An unauthenticated endpoint is not an API, it's a public file share. At minimum, every request should carry a credential the gateway can verify before it forwards anything downstream.

Common options, roughly in order of operational simplicity:

• API keys — simple, stateless, easy to rotate and revoke per client
• OAuth2 / JWT — better for user-delegated access and short-lived tokens
• mTLS — strong service-to-service authentication, higher operational overhead

If you're issuing keys, make sure they're scoped per application, not shared across every consumer. A single shared key means one leak compromises everyone. SubToAPI, for example, issues distinct sub_live_... keys per application so you can revoke one client's access without touching the rest of your team — see the quickstart for how key issuance works in practice.

2. Never trust the client for authorization

Authentication answers "who are you." Authorization answers "what are you allowed to do." These are separate checks and skipping the second one is a common gateway misconfiguration.

At the gateway level, enforce:

• Scopes or roles per key — a read-only integration key shouldn't be able to hit write endpoints
• Route-level allowlists — don't let every authenticated key reach every backend route
• Team/seat boundaries — if you have multiple users sharing a plan, make sure one seat's key can't see another seat's usage or data

This is where a lot of "we had a gateway but got breached anyway" incidents come from: the gateway checked the key was valid, but never checked whether that key should be allowed to do the thing it just did.

3. Rate limit and throttle by identity, not just by IP

IP-based rate limiting alone is weak — attackers rotate IPs, and legitimate users behind NAT or corporate proxies get unfairly throttled. Rate limit by API key or token instead, with IP-based limits as a secondary defense against unauthenticated flooding.

Set limits at multiple levels:

per-key requests/minute   -> stops a single client from hammering you
per-key concurrent streams -> stops resource exhaustion from long-lived connections
global backend limit       -> protects the upstream service (LLM API, database, etc.)

If your gateway sits in front of a metered upstream — like a Claude subscription being exposed as an API — usage metadata per key matters as much as the rate limit itself. You want to see spend and volume by application before a runaway script burns your quota. That's part of why usage metadata is a core feature of gateways like SubToAPI: you can see per-key consumption, not just aggregate traffic.

4. Enforce TLS everywhere, including internally

This one sounds obvious but is skipped more often than you'd expect, especially between the gateway and internal services.

• Terminate TLS at the edge, but also encrypt gateway-to-backend traffic if it crosses a network boundary you don't fully control (multi-cloud, third-party VPC, etc.)
• Disable TLS 1.0/1.1 and weak ciphers
• Redirect all HTTP to HTTPS at the gateway, don't rely on backend services to do it
• Rotate TLS certificates before expiry with automated renewal, not a calendar reminder

A gateway that's authenticated and rate-limited but still accepting plaintext HTTP anywhere in the chain is one packet capture away from a credential leak.

5. Log, alert, and rotate keys as routine, not incident response

Security isn't a one-time configuration — it's an operational habit. At minimum, log:

• Every request with key/client ID, route, status code, and latency
• Every 401/403 response, since spikes usually mean either an attack or a broken integration
• Key creation, rotation, and revocation events

Set alerts on unusual patterns: a key suddenly making 50x its normal volume, requests from a new geography, or repeated failed auth attempts against the same key. Most gateway breaches aren't sophisticated — they're a leaked key sitting unused for weeks before someone finds it and starts hammering the API. Regular key rotation (quarterly at minimum, immediately on employee offboarding) limits the blast radius even if a key does leak.

Practical checklist

If you're auditing an existing gateway or standing up a new one, go through this in order:

1. Every route requires a valid, scoped credential — no exceptions for "internal" endpoints
2. Keys are issued per application/client, never shared
3. Authorization is checked separately from authentication at the route level
4. Rate limits are set per-key, with a global backend ceiling as backstop
5. TLS is enforced end-to-end with modern ciphers only
6. All auth failures and key lifecycle events are logged and alertable
7. Keys are rotated on a schedule and immediately on suspected compromise

For teams exposing a metered third-party service — for example, turning a Claude subscription into an internal API for multiple apps — the same checklist applies, plus one addition: make sure streaming connections (docs/streaming) and tool-use calls (/docs/tools) are subject to the same per-key limits as regular requests. Long-lived streams are an easy place for rate limiting to quietly get skipped.

FAQ

Is an API gateway enough security on its own? No. A gateway enforces authentication, rate limiting, and routing, but you still need input validation, proper error handling, and secure coding practices in the backend services it protects. Think of the gateway as the first checkpoint, not the whole security model.

What's the minimum setup for a small team's first API gateway? Per-client API keys, HTTPS enforced everywhere, per-key rate limits, and request logging with alerting on auth failures. That covers the most common real-world attack patterns without requiring a full OAuth2 or mTLS rollout.

How often should API keys be rotated? Quarterly as a baseline for active keys, immediately after any suspected leak, and instantly upon offboarding a team member or retiring an integration. If your gateway makes revocation and reissuing painless — as with SubToAPI's per-application keys — rotate more often rather than less.