API Management vs API Security: What Gateways Enforce and What They Miss

Many organisations buy an API management platform, put a gateway in front of their APIs and report the API attack surface as covered, when the risks that cause most API breaches sit in places a gateway cannot see. API management is the discipline of publishing, versioning, governing and metering APIs: a gateway, a control plane, a developer portal and the consumer keys and subscriptions that go with them. API security is the discipline of finding every API, testing it, and detecting and stopping abuse of its logic at runtime. The two overlap at the gateway, which is why they get confused. This guide sets out what each one enforces, what each one misses, how token and key governance for API consumers sits across both, and how to combine them. It is for API platform owners, AppSec leads and architects. For the controls themselves, see the API Security Guide and the API Gateway Security Guide; this page covers the boundary between the two disciplines.

Key takeaways

• A gateway enforces what can be written as a rule about a request. Authentication, token validation, quotas, schema checks, method allowlists and coarse authorisation all fit. Whether this caller may read this specific record usually does not, because the gateway does not know who owns the record.
• Most of the OWASP API Security Top 10 2023 lives behind the gateway. Broken object level authorisation (API1), broken object property level authorisation (API3) and unrestricted access to sensitive business flows (API6) need business context. Improper inventory management (API9) is, by definition, about APIs the gateway never saw.
• API management is a governance tool first. Its real security value is the catalogue, the product and subscription model, version retirement and consistent policy. Used that way it shrinks the attack surface; used only as a proxy, it adds one more hop.
• API security adds the outside view and the behavioural view. Discovery from traffic, code and cloud configuration finds the APIs nobody registered. Testing and runtime analysis find logic flaws and slow, authenticated abuse that no static policy catches.
• Consumer credentials are the join between the two. Every API key, client secret and access token is a non-human identity. The management layer issues and meters them; the security layer has to notice when one is stolen, over-scoped or used in a way its owner never intended.

The short answer

You need both, and they answer different questions. API management answers "which APIs do we publish, to whom, under what terms, and through which front door?" API security answers "which APIs actually exist, are they safe to expose, and is anyone abusing them right now?" A gateway is a control point that both disciplines use. If you can fund only one first, fund the governance half of API management (a catalogue, one ingress pattern, consumer onboarding with owned credentials) for any organisation with more than a handful of APIs, because without it there is nothing for API security tooling to compare against. Then add discovery and object-level authorisation testing.

NIST SP 800-228, Guidelines for API Protection for Cloud-Native Systems (June 2025, with updates as of March 2026), frames this as controls across the API lifecycle, split into pre-runtime and runtime stages, with basic and advanced levels for each. Management and security tools each cover parts of both stages.

What each discipline covers

What a gateway enforces well

NIST SP 800-204, Security Strategies for Microservices-based Application Systems, lists the supporting capabilities that microservices need, including access management, secure communication, security monitoring, throttling and load balancing, and notes that API gateways and service meshes bundle many of them. In practice the gateway is the right place for controls that apply to every request regardless of business meaning:

• Caller authentication: validate access tokens and client certificates before traffic reaches a backend. The OWASP REST Security Cheat Sheet says to reject unsecured JWTs, never to choose the verification algorithm from the token header, and to require and validate iss, aud and exp by default.
• Audience and scope checks: RFC 9700, the OAuth 2.0 Security Best Current Practice (BCP 240, January 2025), says resource servers must reject tokens not intended for them and that token privileges should be limited to the minimum needed. A gateway can reject a token whose aud or scope does not match the route.
• Sender-constrained tokens: RFC 9700 recommends mutual TLS (RFC 8705) or DPoP (RFC 9449) so a stolen token cannot be replayed from elsewhere. The gateway is a natural place to check the binding.
• Quotas and rate limits: per consumer, per route and per method, returning HTTP 429 when exceeded. These blunt credential stuffing and scraping, but they are traffic shaping, not a spend control or a guarantee: quota enforcement in distributed gateways is often approximate, so set backend limits as well.
• Schema and method enforcement: reject requests that do not match the published OpenAPI or GraphQL schema, oversized payloads, unknown parameters and HTTP methods outside an allowlist (the cheat sheet recommends 405 Method Not Allowed for the rest).
• Coarse authorisation: route-level and function-level rules (only clients with the admin scope may call /admin/*), which addresses much of broken function level authorisation (API5) when the function map is complete.

See the WAF vs API Gateway guide for the risk-by-risk layer split between a web application firewall and a gateway, and the API Gateway vs In-Service Token Validation guide for where token checks should be duplicated.

What a gateway misses

OWASP's own API9 example shows the inventory gap precisely: a social network enforced rate limiting on password reset tokens in a separate component in front of its main API, and a researcher found a beta host running the same API without that component, then brute forced the six-digit reset token. The control was correct; the inventory was not. The BOLA vs BFLA guide explains why object-level and function-level authorisation need different fixes.

The governance layer: what API management adds beyond the gateway

Treating API management as "the gateway" undersells it. The parts that do the most for security are governance features, and they work only if every API goes through them.

• Catalogue as the source of truth: each API registered with an owner, environment, audience (public, partner, internal), data classification and specification. OWASP API9 lists exactly these questions (which environment, who should have network access, which version) as the test for a "documentation blindspot".
• Products and subscriptions: APIs grouped into products with an approval step before a consumer receives credentials. This turns "anyone with a key" into "a named consumer with an approved purpose".
• Versioning and retirement: published deprecation dates, traffic monitoring on old versions and a hard shutdown step. Zombie APIs are mostly versions that were deprecated in documentation but never switched off.
• Policy as configuration: authentication, quota and header policies applied at global, product, API and operation scope, so new APIs inherit the baseline rather than each team writing its own.
• Design-time linting: specification rules in CI (authentication on every operation, no sensitive data in query strings) before publication.

The API Inventory Template gives a starting catalogue structure, and the OpenAPI Specification Security Guide covers specification rules.

Token and key governance for API consumers

Every external partner, internal service, mobile app and AI agent that calls your APIs holds a credential. Together these credentials are one of the largest non-human identity populations in most organisations, and governance of them is split across the two disciplines.

Three rules matter most. First, an API key identifies and meters a caller; it should not be the only thing that authorises access to sensitive data. The OWASP REST Security Cheat Sheet says not to rely exclusively on API keys to protect sensitive, critical or high-value resources. Second, prefer short-lived OAuth access tokens with audience restriction for service and partner access, and sender-constrain them where the client can support it. Third, give every credential an owner and an expiry, so revocation is a known process rather than a search. See the API Keys vs OAuth Tokens Guide, the Machine-to-Machine OAuth (Client Credentials) Guide and the API Key Management Guide.

Each option in depth

API management

• Threat model: unauthenticated callers, volumetric abuse, malformed input, uncontrolled exposure and inconsistent per-team security. It assumes the APIs it fronts are known and that traffic passes through it.
• Architecture in words: clients reach a gateway cluster at the edge or per environment; the gateway validates credentials against the identity provider or its own subscription store, applies policy, and forwards to backends. A control plane holds configuration, the catalogue and analytics; a developer portal handles onboarding.
• Failure modes: backends reachable directly, bypassing the gateway; the gateway trusted as the only authorisation layer; long-lived keys with no owner; the management plane itself under-protected, which gives an attacker every API at once. See If your API gateway is compromised.
• Controls that make it work: network rules so backends accept traffic only from the gateway or with mTLS from it; privileged access to the control plane; configuration as code with review; per-consumer credentials.

API security

• Threat model: authenticated attackers and abusive customers using valid credentials, logic and authorisation flaws, forgotten endpoints and data exposure. It assumes the gateway will be passed or bypassed.
• Architecture in words: sensors read mirrored traffic, gateway and load balancer logs, traces, cloud configuration and code repositories; an analysis layer builds an inventory and per-endpoint baselines, compares observed traffic with specifications and flags sensitive data flows; a testing component runs authorisation and logic tests in CI or against staging; response actions are pushed to the gateway, WAF or identity provider.
• Failure modes: alert-only deployments nobody triages; discovery limited to one traffic source; tests run without real authorisation context (two users with different data), which miss BOLA entirely; sensitive data copied into the analysis platform without data handling review.
• Controls that make it work: agreed response playbooks; feeds from every ingress, not just the main gateway; test identities per role; data minimisation in captured payloads.

Worked scenario: a retailer with 300 APIs

A retailer runs a public mobile API, a partner API for marketplaces and around 250 internal service APIs. It has an API management platform fronting the public and partner APIs.

Management already gives it partner onboarding with approval, per-partner keys and quotas, token validation for the mobile app, and a catalogue of 50 published APIs.

What discovery finds. Traffic and cloud scanning find 31 internet-reachable endpoints not in the catalogue: two old mobile API versions still answering, a staging host with production data, and a loyalty service called directly by the app because a team bypassed the gateway for latency.

What testing finds. Authorisation tests with two customer identities show the order history endpoint returns any customer's orders when the order ID is changed (API1), and the gift card balance endpoint can be enumerated under quota (API6).

What the retailer does. It shuts down the old versions through the management platform's retirement process, moves the loyalty service behind the gateway and blocks direct access at the network layer, fixes the order check in code, adds a per-account limit and behavioural alerting on the gift card flow, and moves partner access from static keys to short-lived client credentials tokens with audience restriction.

When to lead with each

• Few APIs, one team: a lightweight gateway or the cloud platform's built-in API front door, plus authorisation tests in CI. A simple catalogue and code review of authorisation logic go further than a platform at this size.
• Many teams publishing APIs: lead with API management governance, because inconsistency is the main risk. Mandate one ingress pattern and catalogue registration as a release gate.
• Large, long-lived estate with acquisitions: lead with discovery, because you do not know what you have. Feed findings into the catalogue.
• Public APIs with valuable business flows (payments, ticketing, loyalty, account recovery): invest early in runtime behavioural detection, because abuse will come from valid callers.
• Regulated data behind partner APIs: both, with emphasis on consumer credential governance and data flow inventory, since OWASP API9 calls out third-party data flows without business justification as a blindspot.
• AI agents as consumers: treat each agent as a distinct consumer with its own credential and scopes; see API Security vs MCP Security.

How to combine them: a phased approach

1. Inventory first. Export the gateway catalogue, then run discovery across traffic, DNS, cloud and code. The difference between the two lists is your first remediation backlog.
2. One front door. Route every external API through the managed gateway and restrict backends to accept only gateway traffic (mTLS or network policy). Test by attempting direct access from outside; roll back per API if latency or compatibility breaks.
3. Baseline policy. Apply authentication, token validation (iss, aud, exp, algorithm allowlist), method allowlists, payload limits and per-consumer quotas at global scope. Run new policies in log-only mode for a week where the platform allows it.
4. Consumer credential clean-up. Assign owners, set expiry, rotate keys older than your policy limit, and move sensitive access to OAuth with audience-restricted tokens.
5. Authorisation testing. Add BOLA and BFLA tests with multiple test identities to CI for every API that handles customer or tenant data.
6. Runtime detection. Feed gateway and backend logs into behavioural analysis; start with alerts on bulk retrieval per consumer and enumeration patterns, then automate blocking for high-confidence cases.
7. Retirement loop. Tie version deprecation to traffic monitoring and a shutdown date, and remove the version from the gateway, DNS and backend.

Detection and measurement

Log at the gateway: consumer identity (client ID or key ID, never the secret), route, method, status, response size and latency. Log at the backend: the authorisation decision and the object accessed. Join the two on a request ID. Useful metrics:

• Percentage of discovered APIs that are registered in the catalogue with an owner.
• Percentage of external API traffic passing through a managed gateway.
• Percentage of APIs handling customer data with automated object-level authorisation tests.
• Percentage of consumer credentials with an owner and an expiry, and median credential age.
• Number of deprecated API versions still receiving traffic past their shutdown date.
• Time from first anomalous bulk retrieval by a consumer to block.

The last metric matters. In the T-Mobile API Breach 2023, T-Mobile reported that a bad actor retrieved data through a single API from around 25 November 2022 until detection on 5 January 2023: six weeks of retrieval by one caller that per-consumer volume baselining is designed to catch.

Common failure patterns

• Gateway as the only authorisation layer. Route-level rules pass, and object-level checks were never written because "the gateway handles auth".
• Controls in front of one host only. Rate limiting or WAF rules apply to the production hostname while beta, staging or regional hosts expose the same API without them, exactly the OWASP API9 scenario.
• API keys as sole authorisation for sensitive data. A shared, long-lived key embedded in a mobile app or partner script becomes a credential anyone can extract and reuse.
• Quotas treated as a security boundary. Abuse that stays under the quota, or is spread across many keys, is invisible to quota enforcement.
• Discovery without ownership. An API security tool produces an inventory that never feeds the catalogue, so shadow APIs are rediscovered every quarter.

Framework mapping

Relevant MITRE ATT&CK techniques include T1190 Exploit Public-Facing Application for flaws in exposed APIs, T1528 Steal Application Access Token and T1550.001 Application Access Token for theft and reuse of consumer tokens, and T1078 Valid Accounts for abuse with legitimate credentials.

Practitioner checklist

• Reconcile the gateway catalogue with discovered APIs and assign an owner to every gap.
• Block direct access to backends so the managed gateway is the only external path.
• Enforce token validation with iss, aud, exp and an algorithm allowlist at the gateway, and repeat critical checks in the service.
• Implement object-level authorisation in code and test it with at least two identities per role.
• Give every API consumer its own credential with an owner, scope and expiry; stop using API keys as sole authorisation for sensitive data.
• Design per-flow limits and behavioural alerts for sensitive business flows with the business owner.
• Retire deprecated versions on a published date and confirm zero traffic before removal.
• Protect the API management control plane with privileged access controls and configuration review.

Standards and references

• NIST: SP 800-228 Guidelines for API Protection for Cloud-Native Systems
• NIST: SP 800-204 Security Strategies for Microservices-based Application Systems
• OWASP: API Security Top 10 2023
• OWASP: API9:2023 Improper Inventory Management
• OWASP: REST Security Cheat Sheet
• IETF: RFC 9700 Best Current Practice for OAuth 2.0 Security
• NIST: SP 800-53 Rev. 5 Security and Privacy Controls

Related NHI Mgmt Group resources: API Security Guide · API Gateway Security Guide · WAF vs API Gateway · API Key Management Guide · API Security Buyer's Guide