API security is the set of controls that protect your APIs from attack and misuse. They decide who gets in, what each person can do once inside, how much they can ask for, and what data comes back. If an API connects your apps to customers or partners, it needs these controls.

The pressure is building for a simple reason. In Salt's survey,[ _32% of organizations had an API security incident in the past year_](https://salt.security/api-security-trends) _32% of organizations had an API security incident in the past year_. The same survey found that 66% saw their API count grow by more than 50%. That's a lot more doors to guard, and security teams didn't grow by half.

AI makes the math harder. Agents call APIs on their own and at machine speed, using whatever permissions you give them. Every one of those calls needs, at a minumum, the same checks you'd put on a human request.

Most teams already know what good security looks like. The trouble is applying it the same way everywhere. If 40 teams each build authentication policies their own way, you end up with 40 versions of authentication. The rest of this guide is about avoiding that.

Let's start with the money. IBM's[ _Cost of a Data Breach Report_](https://www.ibm.com/reports/data-breach) _Cost of a Data Breach Report_ puts the 2026 global average at $4.99 million. That's a record, and it's up 12% from the year before. API breaches are a common contributor to this number.[ _Traceable's State of API Security_](https://www.traceable.ai/2025-state-of-api-security) _Traceable's State of API Security_ found that 57% of organizations had an API-related data breach within a two-year window.

If you work in finance, healthcare, or government, the stakes are even higher. Auditors will ask you to prove you have access control, encryption, and logging in place. An API that has no owner and no logs can fail that audit before an attacker ever finds it.

There's a quieter cost as well. Salt reports that nearly half of organizations have delayed releases because of API security concerns. Gaps in security slow your teams down long before any breach does.

Before we get to the tactics, let’s talk about a simple way to organize them. API security rests on three pillars:

1. - **Visibility.** You know every API you run, who owns it, and what data it touches.
2. - **Access control.** You check who's calling and what they're allowed to do.
3. - **Traffic protection.** You encrypt what moves, validate what arrives, and limit how much comes in.

Four principles hold those pillars up:

• - **Zero trust.** Check every request, even ones from inside your network. The[ _zero-trust security_](https://konghq.com/solutions/zero-trust-security) _zero-trust security_ model treats where a request comes from as proof of nothing.
• - **Least privilege.** Give every caller the smallest set of permissions that gets the job done, and make those permissions expire.
• - **Secure by design.** Think through how an API could be abused before anyone writes code for it.
• - **Defense in depth.** Stack your controls so that one failure doesn't expose everything.

With that framework in place, let's get into the practices.

No single control will protect you. Each practice below covers a different kind of failure, and together they close the gaps between them. For each one, you'll see what to do, how to check that it's working, and where a gateway can enforce it for you. If you'd like one platform behind all of it, take a look at[ _Kong API security_](https://konghq.com/solutions/api-security) _Kong API security_.

You can't protect an API you don't know about. Shadow APIs, which got built without a review, and zombie APIs, which were forgotten but never switched off, are the first places attackers look. Here's how to find yours:

1. - **Compare three sources.** Pull the routes from your gateway config, your load balancer or DNS logs, and the OpenAPI files in your code repos. If an API shows up in your traffic but not in your gateway, you've found a shadow API.
2. - **Document every API.** Note the owner (a team and an on-call contact), the data classification, the authentication method, the version, and the sunset date.
3. - **Retire zombies.** If an API has had no traffic for 90 days, mark it for retirement. Announce the shutdown with a Sunset header so clients get fair warning, and then remove the route.
4. - **Don't forget the internal ones.** Internal APIs often carry the same data as public ones, and an attacker who gets inside will move through them. The[ _common API security risks_](https://konghq.com/blog/engineering/api-security-risks-and-how-to-mitigate-them) _common API security risks_ tend to hide in the APIs nobody reviews.

Repeat the three-way comparison every quarter.

Once you know what you have, you can protect it while it travels. Here's the baseline to aim for:

1. - **Set TLS 1.2 as the minimum and prefer 1.3.** Switch off TLS 1.0 and 1.1 entirely.
2. - **Accept HTTPS only.** Close port 80 on your API endpoints. A redirect still lets the very first request, credentials included, leave the client unencrypted.
3. - **Add HSTS for APIs that browsers call.** This header tells browsers to skip plain HTTP on every later visit.
4. - **Use mutual TLS (mTLS) for service-to-service calls and sensitive partner APIs.** With mTLS, both sides show a certificate, so the server knows exactly who's calling.
5. - **Verify upstream certificates.** Your gateway should check the certificate of every service it forwards traffic to.
6. - **Encrypt data at rest.** Use managed keys, and rotate them on a schedule.

In Kong Gateway, the minimum TLS version is a setting in the gateway configuration. HTTPS-only routes, upstream certificate checks, and the HSTS header are set on each service and route.

Regulated industries often need a little more. The[ _Kong API gateway_](https://konghq.com/products/kong-gateway) _Kong API gateway_ supports FIPS 140-3 and post-quantum TLS as of 2026, so you can meet those requirements without adding a separate proxy.

Encryption protects the road. Authentication checks who's driving. For most production APIs, the standard choice is OAuth 2.0 with JSON Web Tokens (JWTs). A few rules will keep you on solid ground:

1. - **Keep access tokens short-lived.** A lifetime of 5 to 15 minutes works well, and refresh tokens can cover longer sessions.
2. - **Validate four things on every request.** Check the signature, the expiration, the issuer, and the audience. Also pin the signing algorithm, and reject any token that claims it doesn't need one.
3. - **Treat API keys as app identifiers.** A key tells you which application is calling, and it says nothing about which person is behind it. Never rely on a key alone to protect anything sensitive.
4. - **Scope your keys and make them expire.** Give each key the narrowest access that works, and set a lifetime of 60 to 90 days.
5. - **Keep secrets out of your source code.** Store keys and signing credentials in a vault, and have your config point to them.

Kong's JWT plugin checks the signature and expiration on every request. It can also reject any token whose lifetime runs longer than your maximum, such as 15 minutes. For API keys, you can set a time-to-live when you create the credential, and the key then expires on its own.

If you're wondering how authentication differs from what comes next, here's a quick read on[ _authentication vs authorization_](https://konghq.com/blog/engineering/api-authentication-vs-api-authorization) _authentication vs authorization_. The difference between them is what the next practice is all about.

Authentication tells you who someone is. Authorization decides what they’re allowed to touch. Skip it and you get the invoice scenario from the start of this post.

That problem is called Broken Object Level Authorization, or BOLA. It’s the number one risk in the[ _OWASP API Security Top 10 (2023)_](https://owasp.org/API-Security/editions/2023/en/0x11-t10) _OWASP API Security Top 10 (2023)_: a logged-in user changes an ID in a request and gets back someone else’s data. Five steps close the door:

1. - **Validate the token at the gateway.** Check the signature, issuer, audience, and expiry, and pin the allowed signing algorithms. In Kong, the JWT or OpenID Connect plugin does this before the request reaches your service.
2. - **Take identity from the token’s claims.** Use the verified sub claim (or a tenant claim like `org_id`) as the owner. Ignore any user ID in the URL or request body.
3. - **Use claims for coarse access, and the data for the rest.** Scopes and roles say whether a caller can use a route at all. They can’t say whether this invoice is theirs, and you shouldn’t try to cram object IDs into the token. Ownership lives in your data.
4. - **Pass verified identity to the service, and lock the door behind it.** Have the gateway forward the claims your service needs as headers. Strip any versions the client sent, and accept traffic only from the gateway, or re-validate the JWT in the service.
5. - **Check ownership in the service, and deny by default.** Scope the query to the caller, so a mismatch returns nothing:

Authorization controls who is calling. Validation controls what they send. Treat every parameter, header, and request body as untrusted until it passes a check:

1. - **Validate against a schema.** Reject anything your OpenAPI or JSON Schema doesn't allow, extra fields included. That stops mass assignment, where a caller sneaks in a field like `"role": "admin"`.
2. - **Write allowlists.** Define what's valid, such as "a SKU is 6 to 20 uppercase characters," instead of trying to list everything that's bad.
3. - **Set size and type limits.** Cap payloads at 1 MB unless an endpoint truly needs more, and reject content types you don't expect.
4. - **Always validate on the server.** Client-side checks are there for your users' convenience, and attackers skip them.
5. - **Return only what the client needs.** Build explicit response objects so you never send out a raw database row.
6. - **Keep error messages generic.** Send a short code and a request ID, and keep the stack trace in your logs.

Kong's Request Validator plugin checks every request against your schema before it reaches your service. A bad payload gets a 400 at the gateway, so your service never has to deal with it. The Request Size Limiting plugin handles the payload cap. This is also the heart of REST API security: the contract you publish becomes the contract you enforce.

Even valid input can be abusive when it arrives in bulk. Brute force, credential stuffing, scraping, and resource exhaustion all look like normal requests, just far too many of them. Rate limits are how you push back.

These numbers are good starting points. Tune them against your own traffic:

After that, a few more steps make the limits hold up:

1. - **Return a 429 with a **`**Retry-After **`**header.** Well-behaved clients will back off without anyone asking.
2. - **Share counters across gateway nodes.** If each node counts on its own, an attacker effectively multiplies your limit by the number of nodes. A shared store such as Redis solves this.
3. - **Add idempotency keys to payment and order endpoints.** A retried request then can't create a second charge.
4. - **Load test your limits.** A tool like k6 can confirm that the 429s start at your limit and not at double it.

Kong's Rate Limiting plugin covers all of this. You pick the limit, what it's keyed by (IP, consumer, or credential), and whether the counters are shared across nodes.

By this point you have a long list of controls, and each one has to run on every API. Doing that service by service is how drift sneaks in. One team forgets the rate limits, and another ships with a weaker JWT check.

An API gateway fixes this by moving enforcement to a single layer that all traffic passes through. Here's how to set that up:

1. - **Apply baseline plugins globally.** Authentication, rate limits, size limits, request IDs, and logging should run on every route by default. Teams can then add stricter rules, and nobody can quietly remove the baseline.
2. - **Keep your policy in Git.** Store the gateway config in a repo, review changes the same way you review code, and deploy them with decK, Kong's declarative configuration tool.
3. - **Extend the same policy to AI traffic.** Calls to LLMs and MCP (Model Context Protocol) tools need authentication, limits, and logs too.[ _Kong AI Gateway_](https://konghq.com/products/kong-gateway) _Kong AI Gateway_ applies the same model to that traffic.

This is the thinking behind the[ _Kong API gateway_](https://konghq.com/products/kong-gateway) _Kong API gateway_. You get one policy engine across every API, so a brand-new service starts out secure on day one.

Because the gateway enforces your policy, it also sees all your traffic. That makes it your best source of evidence, as long as you log the right things and know which patterns to watch for.

**Information to log:**

• - Failed authentication attempts
• - Every 403 and 429 response
• - Changes to config, keys, and permissions
• - The consumer ID, route, status code, latency, and a request ID on every call

**Keep these out of your logs:** passwords, tokens, full card numbers, and personal data from request bodies. If you need to know an Authorization header was present, log that it was there and leave out its value.

**Set alerts for these patterns:**

• - A 401 rate that runs more than 5 times your 7-day baseline for 5 minutes. This usually means credential stuffing.
• - One consumer collecting 403s across 20 or more different object IDs within 10 minutes. This usually means someone is probing for BOLA.
• - A sudden jump in 429s from a single key.
• - Bulk-export endpoints called outside business hours.

Failed-login alerts won't be enough on their own. Since nearly all attacks arrive with valid credentials, you also need alerts on what logged-in users do. Behavioral and AI-based anomaly detection can help, because it learns what normal looks like for each consumer.

Speed matters here because time drives cost. IBM's 2026 data shows that breaches contained within 200 days averaged $4.32 million, compared with $5.65 million for the ones that dragged on longer. Good[ _API monitoring_](https://konghq.com/blog/learning-center/what-is-api-monitoring) _API monitoring_ shortens that window.

Monitoring catches what slips through. Testing keeps most of it from slipping through at all. Here's what to build into your pipeline:

1. - **Threat-model every new API.** Review the design and ask how each endpoint could be abused. Do it before the code is generated, while changes are still easy.
2. - **Lint your API spec on every pull request.** Fail the build if an endpoint has no authentication defined.
3. - **Run static analysis (SAST) on every commit.** Tools such as Semgrep or CodeQL work well for this.
4. - **Run dynamic scans (DAST) against staging.** OWASP ZAP can scan directly from your OpenAPI file.
5. - **Fuzz your schema.** Schemathesis generates unexpected inputs from your spec and finds the crashes you didn't think to test.
6. - **Automate your authorization tests.** The two-user BOLA test from practice 4 belongs here, along with tests for expired tokens, missing scopes, and rate-limit behavior.
7. - **Schedule penetration tests.** Run one every year, and run another after any major change to authentication.

Set your build gate at high-severity findings. A check that can never fail won't protect anything.

Standards give your team a shared checklist and give auditors something familiar to work from. Two of them matter most.

The first is the[ _OWASP API Security Top 10_](https://owasp.org/API-Security/editions/2023/en/0x11-t10) _OWASP API Security Top 10_, which lists the most common API risks. The second is[ _NIST's API protection guidelines_](https://www.nist.gov/publications/guidelines-api-protection-cloud-native-systems-march-2026-update) _NIST's API protection guidelines_ for cloud-native systems (SP 800-228, updated March 2026). NIST sorts controls into pre-runtime and runtime stages, and into basic and advanced tiers. It also recommends a gradual, risk-based rollout, which is how most teams end up adopting it.

Here's how the OWASP risks map to the practices in this guide:

If you want a deeper walkthrough, Kong's guide to the[ _OWASP API Security Top 10_](https://konghq.com/blog/engineering/owasp-top-10-api-security-2023) _OWASP API Security Top 10_ covers each risk in detail.

Even teams that follow the list trip over the same handful of things. Here's what to check your APIs for:

• - **API keys as the only authentication.** Add OAuth 2.0 or JWT validation, and scope the keys.
• - **Sending back too much data.** Compare each response with what the client actually uses, and cut the rest.
• - **Skipping per-resource authorization.** Any endpoint that takes an ID needs an ownership check.
• - **Weaker rules for internal APIs.** Apply the same global baseline everywhere.
• - **Outdated dependencies.** Turn on automated dependency updates, and fail builds that contain known critical vulnerabilities.
• - **Detailed errors in production.** Send a code and a request ID, and keep the stack trace in your logs.
• - **Keys that never expire.** Give every key a lifetime when you issue it.

Look back over the nine practices and you'll notice something. Most of them are enforced in the same spot, which is the path every request takes to reach your services. That spot is the connectivity layer.

Kong Gateway enforces authentication, rate limiting, TLS and mTLS, validation, and logging as plugins on a single runtime. Konnect adds central policy, observability, and governance across every API, whether it runs in multi-cloud, hybrid, or on-prem environments. The same approach covers AI, MCP, and agent traffic, so the controls you build for your APIs also apply to the agents calling them.

Thousands of organizations rely on Kong, including more than half the Fortune 500. For regulated industries, Kong Gateway supports FIPS 140-3. You can see how the pieces fit together on the[ _Kong API security_](https://konghq.com/solutions/api-security) _Kong API security_ page.

[_Request a demo to explore Kong's API platform capabilities._](https://konghq.com/contact-sales)_Request a demo to explore Kong's API platform capabilities._

**What are the most important API security best practices?**

Start with an inventory of your APIs. Then add TLS, strong authentication (OAuth 2.0 and JWT), per-resource authorization, input validation, rate limiting, and monitoring. Each control covers a different failure, and no single one is enough on its own.

**What is BOLA and why is it the most critical API vulnerability?**

Broken Object Level Authorization happens when a logged-in user reaches objects they don't own, usually by changing an ID in the request. It tops the OWASP API Security Top 10 because it's easy to exploit and hard for generic tools to catch. The fix is an ownership check on every endpoint that accepts an ID.

**Are API keys enough for API security, or do you need OAuth 2.0?**

API keys identify applications and not users, so they aren't enough for sensitive data. Pair them with OAuth 2.0 and JWT validation. Give each key a narrow scope, rotate it often, and store it in a vault.

**How does zero trust apply to API security?**

Zero trust means every request gets verified, no matter where it comes from. For APIs, that means authenticating each call, granting the least privilege that works, denying by default, and limiting how far one stolen credential can reach.

**Should internal APIs follow the same security controls as public APIs?**

Yes. An attacker who gets into your network will move through internal APIs, so a weaker baseline there becomes the easiest path. A gateway applies the same authentication, limits, and logging to both.

**How often should I rotate API keys and audit my APIs?**

Rotate keys at least every 60 to 90 days, and rotate them right away after any suspected exposure. Repeat your API inventory comparison every quarter, and schedule a penetration test every year.

**How can I test my API security effectively?**

Threat-model new APIs before you write code. Then run SAST and DAST in your CI/CD pipeline, fuzz the schema, and automate tests for authentication, authorization, validation, and rate limits. Add a penetration test each year.

**How does an API gateway improve API security?**

A gateway puts authentication, validation, rate limiting, and logging at one enforcement point instead of inside every service. Every API then gets the same baseline policy in every environment.