API gateways have spent the last few years collecting responsibilities that used to live in dozens of services, and the result is that a misconfigured gateway is now one of the highest-leverage attack surfaces in a typical stack. The good news is that the configuration surface that matters most has stabilized. This post collects the baseline we recommend for production gateways in 2026, based on what has held up against the attacks we have seen this year.
What does the authentication baseline look like?
The non-negotiable starting point is that every route requires authentication unless explicitly carved out, with the default policy being deny rather than allow. We still find gateways in 2026 where the implicit default is open and individual routes are protected by per-route policies, which is the configuration that produces the most incidents. Flip the default. Anything that should be public, login endpoints, health checks, marketing pages, gets an explicit public marker that shows up in audit logs.
For the authenticated paths, prefer short-lived JWTs with issuer verification and audience checks on every request. API keys remain acceptable for service-to-service calls but should be issued per-consumer, scope-limited, and rotatable from a single control plane. The 2024 Kong incident and the Tyk advisory in early 2025 both involved long-lived credentials with too-broad scope, and both would have been contained by tighter issuance discipline.
How should rate limiting be configured?
Rate limiting at the gateway is doing two distinct jobs: it protects backends from accidental overload, and it slows credential stuffing and resource enumeration attacks. These need different limits. Backend protection limits are typically per-API-key or per-consumer and sized to the backend's known capacity, perhaps 100 to 1000 requests per second for a typical service. Attack-mitigation limits are per-IP or per-token and sized much lower, often 10 to 50 requests per second, with sliding window enforcement to catch bursts.
The trap that produces incidents is a single rate limit policy serving both jobs and being tuned for one. The credential stuffing attacker who comes in under the backend protection limit but well above the attack mitigation threshold gets through if you only configured the first. Layer the limits explicitly and observe what each one blocks.
What about schema validation and request shaping?
Schema validation at the gateway, OpenAPI or GraphQL schema enforcement, catches a meaningful share of injection and mass-assignment vulnerabilities before they reach the backend. The 2025 advisory on a major Express middleware involved unvalidated JSON that triggered prototype pollution in three downstream services. A gateway that enforced the documented schema for that endpoint would have rejected the payload at the perimeter.
The implementation cost is real: maintaining a schema that accurately describes the API requires discipline, and the schema must evolve with the API. The shortcut of generating a schema once and leaving it stale produces worse outcomes than no schema validation, because it creates false confidence. Bake schema generation into the API release process and validate that the deployed schema matches the deployed code, then reject anything that does not match.
How do you handle observability without leaking secrets?
Gateway logs are gold for incident response and a hazard for compliance. The defaults on most gateways log full request and response payloads, which means credentials, tokens, and PII end up in your log aggregator within minutes of go-live. The right baseline is structured logging with explicit allowlists for fields that get captured rather than blocklists for fields that get redacted. Headers like authorization, x-api-key, and cookie should be redacted by default at the gateway level, and bodies should be sampled at low rates with active PII detection.
Trace propagation, ideally W3C trace context, should be enforced at the gateway so backend correlation works without per-service implementation. The combination of structured logs, sampled bodies, and trace IDs gives incident responders enough to reconstruct attacks without producing a credentials leak by way of your SIEM.
What about the gateway's own supply chain?
The gateway itself runs code, often a substantial amount of plugin code, and that code base is part of your supply chain. Kong, Tyk, Apigee, and the various Envoy-based options each have their own CVE history, and at least one major incident per year is now traceable to a vulnerability in the gateway runtime or one of its plugins. Treat the gateway like any other production service: SBOM, scanning, signed deploys, and a patching cadence faster than your application services because the blast radius is larger.
The plugin question is the subtle one. Custom Lua or WASM plugins in Kong, custom middleware in Tyk, all of these can ship code that bypasses the gateway's own security model. Review and sign plugin code as carefully as you review the core gateway, and prefer first-party plugins from the upstream project when functionality overlaps.
How Safeguard Helps
Safeguard treats your API gateway as a first-class service in your supply chain posture. SBOM ingestion covers Kong, Tyk, Envoy, and the major Apigee distributions, and Griffin AI correlates gateway-specific CVEs with your deployed plugins and configuration to surface exposure within hours of disclosure. Reachability analysis on gateway plugin code distinguishes loaded-and-exposed plugins from installed-but-disabled ones, dramatically reducing the CVE noise that gateway scanners typically produce. Policy gates can require schema validation, authentication-by-default, and signed plugin code before allowing gateway deploys, and TPRM scoring tracks gateway vendor patching cadence so you can see which products are actually keeping up with the threat surface.