API Security Best Practices for SaaS Applications

Fifty-seven percent of organizations suffered an API-related breach in the past two years. That is from Traceable AI's 2025 State of API Security Report, which pulled data from over 1,500 IT and security professionals. Of those breached organizations, nearly three-quarters faced three or more incidents. Over 40% faced five or more. These are not flukes. They are patterns people are living with and, somehow, still failing to fully act on.

The year-over-year jump is what actually stops me. The share of organizations reporting breaches more than doubled in a single year: 17% in 2023, 37% in 2024. That is not a trend line gently sloping upward. That is something breaking — like a dam that held for years and then gave way.

The incidents behind those numbers are not abstract data points:

• Trello (January 2024): an exposed API linked private email addresses to over 15 million user accounts.
• GitHub (March 2024): nearly 13 million API secrets exposed through public repositories.
• T-Mobile: a single API without proper access control exposed 37 million customer records. For more than 40 days.
• Optus: 10 million customer records exposed through a legacy API that had simply been neglected.

The financial picture is what you would expect given that scale. Average remediation costs per incident in the US sit near $600,000 (Akamai). Nearly 70% of organizations experienced breach costs exceeding $1 million (Imperva). Across industries in 2024, API breaches exposed 1.6 billion records (FireTail).

What makes all of this worse is how badly the detection side is failing. About one in five organizations report a strong ability to detect API-layer attacks. Only around one in eight can prevent more than half of API attacks. Just 7.5% have implemented dedicated API testing and threat modeling programs at all (Salt Security).

The problem is known. It is just, somehow, still mostly unaddressed.

The Vulnerability Classes That Account for Most Successful API Attacks

There is a clear pattern to how APIs actually get exploited. It is not exotic.

The top vulnerability class in the OWASP API Security Top 10 is Broken Object Level Authorization, or BOLA. The concept is blunt: an API exposes endpoints that use object identifiers like user IDs or account numbers, and when the API fails to check whether the person calling it actually owns that object, any authenticated user can query any object. You swap out one ID for another and you are reading someone else's data. It keeps showing up at the top of the list because it is genuinely easy to miss during development and genuinely easy to exploit afterward. Think of it like a filing cabinet where the lock on the drawer is real, but once you are in the room, you can open any drawer you want.

The 2025 production vulnerability breakdown tells a similar story:

• Path Traversal: 27.3% of vulnerabilities. The single most common class.
• SQL Injection: 20.0%.
• Server-Side Request Forgery (SSRF): 14.5%.
• Denial-of-Service: 10.9%.

Path traversal and SQL injection have been on security lists for decades. They keep showing up because APIs keep trusting user-supplied input they should not trust. That is the whole story.

The 2025 OWASP update also moved Security Misconfiguration to the number two spot, up from number five. Misconfiguration is now nearly as common a root cause as access control failure, which is its own kind of uncomfortable finding. And the newest OWASP category worth paying attention to is Mishandling of Exceptional Conditions: verbose error messages, unhandled exceptions, services that fail open instead of closed. Attackers learn a surprising amount about your internals from a stack trace you did not mean to return.

Why Strong Authentication Is Necessary but Not Sufficient on Its Own

Let's get the baseline right first. For user-facing APIs, OAuth 2.0 and OpenID Connect are standard. For service-to-service communication, strong randomly generated API keys or mutual TLS are appropriate. JWT tokens should be short-lived, somewhere between 15 and 60 minutes. Long-lived refresh tokens handle re-authentication without forcing users to log in constantly.

All of that is correct. None of it is wrong. Here is the problem anyway.

Ninety-five percent of API attacks use authenticated sessions (Salt Security). Attackers are not breaking through authentication. They are walking through the front door with valid credentials and exploiting what those credentials are allowed to do once inside. A valid token proves identity. It does not prove intent, and it does not prove scope. Authentication is the front door. The rest of the house is a separate problem — and most breaches happen in the living room.

AI agents complicate this in a specific way. OAuth tokens and API keys used by agents often carry broad permissions across multiple SaaS applications, because whoever configured the agent requested more scope than was strictly necessary and never rotated the credential. Wallarm's 2025 API ThreatStats analysis found that 89% of AI-powered APIs lacked secure authentication. The fastest-growing part of the API surface is running with the most basic control missing.

What strong authentication actually buys you: it narrows the entry surface and forces attackers to work harder for a valid credential. That matters. It just cannot be the last line of defense, because in practice, it demonstrably is not.

Enforcing What Authenticated Users Are Actually Allowed to Do

Authorization is where most breaches actually live. BOLA sits at the top of the OWASP list for a reason: object-level checks often get implemented at the route level and never at the data access layer. Someone built the route-level check, felt good about it, and moved on.

Doing this correctly means checking permissions at every function that accesses a data source using a user-supplied ID. Not just at the router. Not just on the endpoints that feel sensitive. Every function, every time, without exception.

The T-Mobile case is instructive here. Picture a security guard posted at the front entrance of a building, checking badges at the door, while every office inside sits unlocked and unattended. Thirty-seven million records. More than 40 days. Not from a sophisticated, multi-stage attack. From a missing authorization check on a single endpoint. That is what BOLA looks like when it lands.

For structuring access control practically:

• Role-Based Access Control (RBAC): Assign roles like admin, editor, and viewer, enforce least privilege at each level, and make sure each role can only see what its function actually requires.
• Zero Trust for internal services: Internal microservices are not automatically trustworthy just because the traffic came from inside the cluster. East-west, service-to-service calls deserve the same scrutiny as external calls. This one gets skipped constantly.
• Service identity: Use mTLS, signed internal tokens, and service mesh policies to prove which workload is calling, not just which network it came from.

Compromised internal services move laterally precisely because internal authorization rarely gets enforced as strictly as external-facing authorization. That assumption of internal trust is an attack path, and it is a comfortable assumption to make right up until it is not.

Rate Limiting and Throttling as a First Line of Defense Against Abuse at Scale

Rate limiting addresses two distinct threat types that are easy to lump together. First: brute-force credential attacks, where high volumes of login attempts hammer authentication endpoints. Second: resource exhaustion and DDoS against the API hosts themselves. The controls overlap, but the threat models are different enough that it is worth being clear about which one you are solving for.

Indusface data from the first half of 2025 puts real numbers on the second type. SaaS and tech platforms experienced 74 times higher API attack volumes and 121 times more API-layer DDoS attacks compared to traditional enterprises during that period. API endpoints are now the preferred DDoS target, not the web layer. DDoS attacks on API hosts outpaced attacks on websites by 388% in the same window.

A practical approach to rate limiting:

• Per-user and per-IP limits on sensitive endpoints like authentication, password reset, and data export.
• Graduated throttling. Slow responses before hard blocks. This frustrates automated tooling without visibly breaking the experience for real users trying to get things done.
• Separate limits for unauthenticated versus authenticated requests. Unauthenticated calls carry higher risk per request and should face tighter restrictions.
• Limits on enumeration endpoints. Even when authorization checks are imperfect, volume limits meaningfully slow down a BOLA harvesting attempt.

Your API gateway is the right enforcement point for all of this. Centralized, consistent, not reliant on every individual service team implementing it correctly on their own. The real tradeoff: limits tuned too aggressively degrade your product, limits set too loosely protect nothing, and calibrating between those two outcomes requires actual observability data about your normal traffic patterns. There is no shortcut there.

Input Validation and Schema Enforcement as the Control That Stops Injection Attacks Before They Reach the Database

Path traversal and SQL injection together account for nearly half of production API vulnerabilities in 2025. Both are failures of the same underlying thing: the API trusted user-supplied input and passed it into a downstream system without checking what it actually contained.

The schema-first approach addresses this at the entry point. Define a strict schema for every API request and response using the OpenAPI Specification. The gateway or application logic rejects anything that does not conform before it ever reaches business logic. Even if an individual service has a validation gap, malformed input gets turned away upstream.

For SQL injection specifically, parameterized queries and prepared statements are the control. The root cause of SQL injection is constructing queries by concatenating strings with user input. Parameterization eliminates that construction entirely. It is not a mitigation. It is the fix.

SSRF sits at 14.5% of production vulnerabilities and is a specific kind of input validation failure. The API accepts a URL from the user and makes a server-side request to it without verifying whether that destination is legitimate. The fix is allowlisting outbound destinations. If your service should only be calling three external endpoints, only those three should be reachable. Everything else gets blocked by default.

The OWASP category on Mishandling of Exceptional Conditions extends this thinking in a direction people underestimate. Unhandled exceptions and verbose error responses are not just bad user experience. They are information leakage. APIs should fail closed: return generic error messages to callers, log the detail internally, and never expose stack traces or internal state in a response. An attacker reading your error messages is getting a guided tour of your architecture.

Continuous Monitoring and Discovery as the Control That Catches What the Others Miss

About one in five organizations reports a strong ability to detect attacks at the API layer. That number is worth sitting with for a second, because controls being in place is not the same thing as attacks actually being caught.

Before you can monitor an API, you have to know it exists. Shadow APIs, endpoints that are no longer actively maintained or documented but still technically reachable, are a real attack vector. The Optus breach came from exactly this. A legacy API no one was actively watching. Discovery has to happen before monitoring is useful.

What a useful API inventory actually looks like:

• A catalog of all endpoints, including internal and deprecated ones.
• Clarity on which are publicly reachable versus internal-only.
• A real decommissioning process for legacy endpoints. Both the T-Mobile and Optus cases involved endpoints that should have been retired before the breach happened.

What monitoring needs to catch:

• Anomalous request volumes: Rate abuse patterns and credential stuffing attempts.
• Unusual object ID patterns: BOLA enumeration looks like sequential or random ID testing at scale. It has a signature.
• Unexpected outbound requests: SSRF exploitation often shows up as unusual external call patterns.

For logging: capture enough to reconstruct an attack path, including caller identity, endpoint, object IDs accessed, and response codes. Avoid logging sensitive payload data that would itself become a breach if the logs were ever exposed. That second part gets ignored more than it should.

And keep detection time in mind as the actual goal, not just detection capability. The T-Mobile breach was 37 million records over more than 40 days. The duration is where the damage accumulates. Getting alerted on day two instead of day 42 is the difference that matters.

Third-Party Integration Security as a Distinct Category of API Risk in SaaS Products

SaaS products are dense with integrations. Billing, CRM, analytics, identity, communication tools, and hundreds of user-requested connectors. All of them run on API credentials stored inside your product. This creates a risk category that is genuinely different from first-party API risk, and treating it as the same problem leads to gaps.

The 2025 Salesloft-Drift incident is the clearest recent illustration. Attackers exploited OAuth tokens from a compromised third-party app and gained access to hundreds of downstream customer environments. Obsidian Security researchers found the blast radius was roughly 10 times greater than previous supply chain incidents. One integration token. Hundreds of environments. It is the supply chain equivalent of handing a master key to someone who said they only needed to water the plants.

Third-party integration risk differs in kind for a few specific reasons. You do not control the security posture of the third-party API you are connecting to. OAuth tokens granted to integrations routinely carry more scope than the integration actually requires, because whoever configured them requested broad access to reduce friction during setup. And those tokens are often long-lived and rarely audited or rotated. The combination of broad scope and indefinite lifespan is what makes a compromised integration token so valuable to an attacker.

The practical controls:

• Scope minimization. Request only the OAuth scopes the integration genuinely needs. Not the convenient wide ones that make setup easier.
• Token rotation and expiry. Integration credentials should be treated like short-lived secrets, not permanent passwords issued once and forgotten.
• Periodic audits of active OAuth grants. Revoke tokens for integrations no longer in use. Most organizations are on no regular schedule for this.
• Monitor integration behavior. Anomalous data access patterns from a connected app are a signal. Act on it.

The same authentication failure pattern showing up in first-party APIs is now appearing in AI-powered integrations. Wallarm's 2025 data found that 57% of AI-powered APIs were externally accessible while 89% lacked secure authentication. This is the same structural gap appearing on a surface that is growing faster than most teams are securing it.

APIs are exposed by design in SaaS. That is not the problem. The problem is treating the controls that close the most common gaps as optional until something forces the conversation. The breach record is doing a lot of forcing right now, and it is not finished.