API Security Examples: Learn From Breaches & Best Practices

Introduction: Why API Security Examples Matter

In an increasingly connected world, APIs (Application Programming Interfaces) are the backbone of digital services, enabling apps, platforms, and partners to exchange data. But while innovation moves quickly, API security often lags dangerously behind.

According to Raidiam’s API Security Report, 84% of surveyed organizations are exposing sensitive data via weak API security practices. This article explores both bad and good API security examples, including a real-world data breach, to help teams recognize red flags and adopt secure architectures.

→ Check out next: API Security Report: Helping Enterprises Recognize and Address Critical Risks

Bad API Security Examples

Here are some imaginary - but realistic - bad practices seen all too often in the wild.

1. Static API Keys with No Scope or Expiry

A retail API uses a hardcoded API key to authorize mobile apps. The key:

• Never expires
• Has full read/write access to all user accounts
• Is embedded in the mobile app’s code

Attackers reverse-engineer the mobile app, extract the key, and use it to modify other users’ orders.

Why this is bad: Static keys are often leaked and over-privileged. Without scope or expiration, one compromised key can lead to mass data exposure.

2. No Rate Limiting or Behavioral Monitoring

A logistics platform exposes a vehicle-tracking API without any rate limits. Anyone with an API key can send unlimited queries.

Impact:
A competitor scripts calls to scrape data on fleet movements, pricing patterns, and delivery routes — gaining an unfair edge.

Why this is bad: Without throttling, APIs become sitting ducks for scraping, abuse, and brute-force attacks.

→ Related article: The API Security Gap: Why Most Enterprises Are Still Vulnerable

3. Basic Authentication Vulnerabilities

A fintech startup allows third-party providers (TPPs) to access its APIs using only basic OAuth 2.0 client authentication methods such as client_secret_post or client_secret_basic, without enforcing stronger forms of client authentication like private_key_jwt or mutual TLS (mtls).

Why this is bad: Client secrets are part of a symmetric authentication approach - simply put, they must be known to both the resource owner and the client, and are exchanged as part of the authentication process. This leaves open multiple avenues of interception / exposure.

Additionally, as no certificates are involved, access tokens cannot be bound, and are open to interception and replay by unauthorized parties.

Real API Breach Example: Dell (2023)

One of the most illustrative real-world API security failures is the Dell customer data breach.

What Happened?

An attacker posed as a fake partner and gained access to a public API endpoint that revealed full customer records using just a service tag (ID).

• No input validation
• No rate limiting
• No behavior monitoring
  
  

• 49 million records leaked
• Attack executed via automated scripts
• Undetected for weeks

Takeaway: Even one weak API — without proper validation, monitoring, or access control — can compromise millions of users.

Source: Salt Security Review of Dell Breach

Related read: Why API Security Vulnerabilities Should Keep You Up at Night

Good API Security Example: FAPI + Mutual TLS

Now let’s look at what great API security looks like, using a financial-grade setup based on OpenID FAPI (Financial-grade API) and mTLS.

Scenario

A regulated Open Banking API in the UK requires:

• Mutual TLS (RFC 8705): Clients must present a valid certificate
  
  
• Private Key JWT Authentication: Tokens are cryptographically signed by the client
  
  
• Certificate Bound Access Tokens: Tokens are bound to the client’s certificate, making theft useless
  
  
• Fine-grained Scopes: Clients get only the data they’re authorized for
  
  
• Short-lived Tokens: Expire quickly and can’t be reused
  
  

Why this is excellent: mTLS and FAPI enforce cryptographic identity, mitigate replay attacks, and align with Zero Trust architecture.

As noted in Raidiam’s research:

“Only one organization surveyed had implemented a full modern security profile… and it was operating under an Open Banking regime.”
— API Security Report, 2025

→ Related read: The Leaders Are Already Securing APIs with FAPI + mTLS

Best Practices for Securing APIs

Use these principles to upgrade your API security strategy:

1. Implement Strong Client Authentication:
   
   Use OAuth 2.0 with mutual TLS (mTLS) or private_key_jwt to ensure clients are cryptographically bound to their credentials. Avoid static API keys or client secrets alone.
   
   
2. Issue Scope-Limited, Short-Lived Access Tokens (with Refresh Tokens When Needed):
   
   Restrict access tokens to the minimum necessary scopes and durations. Where long-lived access is required, use refresh tokens with appropriate security controls.
   
   
3. Enforce Rate Limits and Anomaly Detection:
   
   Apply rate limiting and monitor for unusual traffic patterns to protect APIs from abuse and credential compromise.
   
   
4. Adopt Fine-Grained Access Control (e.g., ABAC or RBAC):
   
   Move beyond simple role-based permissions by using context-aware access controls such as Attribute-Based Access Control (ABAC).
   
   
5. Continuously Test and Monitor API Security:
   
   Perform regular security testing and maintain continuous monitoring to detect vulnerabilities, misconfigurations, or emerging threats.
   
   
6. Protect Sensitive Data in Transit and at Rest:
   
   Use JWE for encrypting sensitive payloads and JWS to ensure message integrity and authenticity.
   
   
7. Bind Access Tokens to Client Certificates and Rotate Keys Regularly:
   
   Use certificate-bound access tokens (via mTLS or DPoP) to prevent unauthorized token reuse. Regularly rotate keys and certificates to maintain strong cryptography.

Resources like JARM and API Gateway policies can also strengthen runtime protection and trust validation.

Closing the API Security Gap

As the Raidiam survey highlights, most organizations fall into the “Act Urgently” category — especially those outside regulated environments. With APIs now a primary attack surface, the stakes are high.

Forward-looking teams should:

• Adopt cryptographic identity measures like mTLS and JWT
  
  
• Treat API security as a first-class risk
  
  
• Engage partners like Raidiam to build out secure, federated API ecosystems
  
  

Next Step: API Security Report

Download the full API Security Report from Raidiam to explore the critical risks, real-world breaches, and proven solutions shaping modern API security.

This essential report includes:

• A breakdown of API security maturity across industries
  
  
• Real breach case studies (like the Dell API leak)
  
  
• Technical guidance on mTLS, JWT, and FAPI
  
  
• Strategic recommendations to close the API security gap
  
  

👉 Don’t wait for a breach — get the insights now and start hardening your APIs today.