Insights · Security guide

API and API gateway security: a practical guide

Secure an API by checking who is calling, what exactly they may touch, and how much they may do, and by enforcing those checks both at the gateway and in the backend. A gateway is a strong control point, but it does not replace authorisation in the application, and it is itself software that must be patched. This guide covers the main risks, a hardening checklist, patching, inventory, testing and response.

Updated: 6 November 2026

Why APIs and gateways attract attackers

APIs expose business functions and data in a structured, predictable way. That makes them easy for attackers to explore and automate. An API gateway sits in front of many services, so a weakness in it, such as a bypassed authentication check or a missing rate limit, can affect everything behind it.

When news reports a flaw in a popular gateway, the useful reaction is not panic but a routine: know which gateways and plugins you run, know their versions, and have a way to update them quickly. Examples of widely used gateways are Kong, Tyk, Apigee, Amazon API Gateway and Azure API Management. Each is one option among many, and the principles below apply to all of them.

The OWASP API Security Top 10

OWASP's list is the standard starting point for API risk. As of November 2026 the current edition is still the 2023 one, and the project pages show no newer edition. Use it as a checklist for design reviews and tests. The ten categories are:

• API1: Broken Object Level Authorization
• API2: Broken Authentication
• API3: Broken Object Property Level Authorization
• API4: Unrestricted Resource Consumption
• API5: Broken Function Level Authorization
• API6: Unrestricted Access to Sensitive Business Flows
• API7: Server Side Request Forgery
• API8: Security Misconfiguration
• API9: Improper Inventory Management
• API10: Unsafe Consumption of APIs

Hardening the gateway

Start with identity. Authenticate every request with established standards rather than home-made schemes. OWASP stresses that API keys alone do not identify a user and should not protect sensitive resources by themselves. If you use JWTs, reject unsigned tokens, choose the verification algorithm from your own configuration rather than the token header, and check issuer, audience and expiry.

Authorisation needs two levels. Object-level checks make sure the caller may access the specific record named in the request; changing an ID in the path is the classic attack, and unguessable IDs only help as an extra layer. Function-level checks deny access by default and grant each function by role, without assuming that a URL path tells you whether an endpoint is administrative. The gateway can enforce coarse rules, but the final decision about an object usually belongs in the service that owns the data.

Control consumption. Set rate limits and quotas per client, apply stricter limits to sensitive operations such as password recovery or one-time codes, cap request and payload sizes, and set spending limits or billing alerts for paid third-party APIs. Azure API Management, for example, documents quotas and rate limits as gateway policies, and other products offer similar features.

Validate input and output. Check type, length, format and range, allow only the HTTP methods and content types each API needs, return clean error messages without stack traces, and log validation failures because a spike often signals probing. Encrypt all traffic with TLS, including between the gateway and backends, and consider mutual TLS for highly privileged or machine-to-machine services. Keep secrets such as keys and certificates in a secrets manager, rotate them, and never place them in gateway configuration files that live in version control.

• Deny by default, then allow per role and per object
• Rate limits, quotas and size limits on every route
• TLS everywhere, mutual TLS for sensitive service links
• Secrets in a vault, short-lived tokens, rotation
• Admin and management interfaces on a separate, restricted network
• Structured logs with request IDs, without secrets or personal data

Patching gateways and plugins

A gateway is internet-facing software with its own dependencies and third-party plugins. Keep a list of every gateway, version and plugin, including custom ones, and assign an owner for each. Subscribe to the vendor's security advisory channel or release notes, and check the vendor's version support policy so you know how long your version receives fixes.

Support windows matter. Kong, for instance, states that regular minor versions are supported for one year and long-term-support versions for up to three years, after which a sunset period brings no patches. Other vendors have their own rules, so read them before you choose a version.

NIST published guidelines for API protection in cloud-native systems as SP 800-228 in June 2025 and issued an update in March 2026. They describe basic and advanced controls for the pre-runtime and runtime stages of the API lifecycle and are a useful reference for a risk-based roadmap. When an advisory affects you, test the update in a staging environment, roll it out quickly, and review logs from before the patch for signs of earlier abuse.

API inventory and shadow APIs

You cannot protect what you do not know about. OWASP lists improper inventory management as a risk because forgotten hosts, old versions and undocumented endpoints often lack current controls, and old versions may even share a database with production. Attackers find them with simple methods such as DNS enumeration and search engines.

Record every API host with its environment, audience and version. Document endpoints, authentication and limits from a machine-readable specification kept in your CI/CD pipeline. Define a retirement plan for each version, protect all exposed versions and not just the newest, and keep production data out of test systems. Compare your inventory against what traffic logs and DNS actually show to find shadow APIs.

Testing APIs

Combine several methods. Automated dynamic scanners import an OpenAPI, SOAP or GraphQL definition and probe each endpoint; the open-source ZAP API scan is one example, and note that it runs active attacks by default, so aim it at a test environment. Fuzzing sends malformed and unexpected input to find parsing and error-handling flaws.

Automation rarely finds authorisation logic flaws, such as one customer reading another customer's order. That is where manual penetration testing earns its place: a tester uses two or more accounts with different roles and tries to cross the boundaries. Also write automated authorisation tests into your own pipeline so that a change that breaks them cannot ship. Retest after major gateway upgrades and configuration changes.

Monitoring and incident response

Log authentication failures, token validation errors, authorisation denials, rate-limit hits and administrative changes, and send them to central monitoring. Useful alerts include sudden growth of 401, 403 or 429 responses, enumeration patterns across sequential IDs, and traffic to endpoints that should be unused.

Prepare a playbook before you need it. It should say how to revoke keys and tokens, how to block a client or route at the gateway, who may roll back a configuration, how to preserve logs, and who decides about notifying customers and authorities. Practise it once, and include the vendor's support contact.