API security: the 5 flaws that expose your company's data (and how to fix them)

Firewall configured, HTTPS on, website up to date. Even so, your customers' data may be a single request away from anyone on the internet. The reason is almost always the same: APIs. In this article we show where the flaws that expose companies most today are, how they are fixed in code and infrastructure, and what to assess before the problem turns into an incident.

Most companies' blind spot

Every modern integration runs through an API: the app that looks up orders, the online store that talks to the ERP, the CRM that receives WhatsApp messages, the partner that pulls your catalog. According to Cloudflare Radar, 58% of dynamic HTTP traffic on the internet is already API traffic.

The problem is that security has not kept up. Gartner predicted that by 2025 fewer than half of enterprise APIs would be managed. In practice, many companies do not know how many APIs they run, who consumes them or what data they return.

That is exactly the gap attackers exploit. The main website usually gets a firewall, testing and attention. The API was built for an integration on a tight deadline and never reviewed again. APIs were behind cases such as the scraping of around 700 million LinkedIn profiles and the flaws exploited for years at T-Mobile.

What is at stake for the business

API security is not just a matter for the tech team. A flaw here has a direct cost:

• Privacy laws: under Brazil's LGPD, a personal data leak can lead to fines of up to 2% of revenue, capped at R$ 50 million per violation, plus the duty to notify affected people. GDPR and similar laws carry comparable penalties.
• Downtime: an API with no usage limit can be knocked over by excess requests, taking the app, checkout and integrations down with it.
• Competition: overly open APIs let third parties copy catalog, prices and stock automatically.
• Trust: a customer told their data was leaked rarely buys again.

Why protecting the website is not enough

Tools built for websites look at forms, scripts and browsing. An API works differently: it takes and returns raw data (JSON), is consumed by systems rather than people and talks directly to the database. A malicious API call usually looks identical to a legitimate one. The difference lies in context: who is asking, for what and how often.

That is why the core rule is: every API operation must validate the caller's identity and permission on every request. Being authenticated does not mean being authorized.

The 5 flaws that expose companies most

The industry reference on the subject is the OWASP API Security Top 10, the list of the most exploited API vulnerabilities. The five below account for most incidents and are the first ones we assess in a review.

1. Access to other users' data (OWASP API1: BOLA)

This is number one on the list. The API confirms the user logged in, but not that the requested record belongs to them:

GET /api/orders/1042   → 200 OK  (the user's order)
GET /api/orders/1043   → 200 OK  (another customer's order)

With a simple script, someone walks through every ID and downloads the whole database. The fix lives in the code: every query filters by the resource owner, taken from the token, never from what the client sends.

[Authorize]
[HttpGet("{id:int}")]
public async Task<IActionResult> Get(int id)
{
    var customerId = User.FindFirstValue(ClaimTypes.NameIdentifier);

    var order = await _db.Orders
        .Where(o => o.Id == id && o.CustomerId == customerId)
        .Select(o => new OrderDto(o.Id, o.Status, o.Total))
        .FirstOrDefaultAsync();

    // 404 instead of 403: does not confirm the order exists
    return order is null ? NotFound() : Ok(order);
}

2. Weak authentication (OWASP API2)

Tokens that never expire, API keys hardcoded in the app, login endpoints with no protection against trial and error. One leaked token is enough for someone to act on a customer's behalf.

How we fix it: short-lived JWT or OAuth 2.0 tokens, with signature, issuer and expiry checked on every request; mTLS for server-to-server integrations; and progressive lockout on login and password recovery.

3. Excessive data exposure (OWASP API3)

The screen shows the customer's name, but the API response returns ID number, phone, address and sometimes even the password hash. Anyone who opens the browser's dev tools sees it all.

How we fix it: the API never returns the database entity directly. Each endpoint has a DTO with only the fields it needs, like the OrderDto above. At the edge, sensitive data detection alerts when ID numbers, cards or credentials show up in a response.

4. Unrestricted consumption (OWASP API4)

Without request limits, the API is open to password brute force, catalog scraping and denial of service. A list with no pagination lets someone download millions of records in one call.

How we fix it: rate limiting in code and at the edge, with limits calibrated to each endpoint's real traffic, and mandatory pagination. Modern frameworks ship with this out of the box, whether in .NET, Node.js, Java, PHP or Python. An example in ASP.NET Core:

builder.Services.AddRateLimiter(o =>
{
    o.RejectionStatusCode = StatusCodes.Status429TooManyRequests;
    o.AddFixedWindowLimiter("api", l =>
    {
        l.PermitLimit = 100;                // 100 requests
        l.Window = TimeSpan.FromMinutes(1); // per minute
    });
});

app.MapControllers().RequireRateLimiting("api");

5. Forgotten APIs (OWASP API9)

The /api/v1 that should have been switched off, the test endpoint that made it to production, an old vendor's integration. These are shadow APIs: they appear in no documentation, get no fixes and are the favorite of anyone looking for an open door.

How we fix it: continuous inventory based on real traffic, OpenAPI documentation generated from the code itself, old versions with a shutdown date and a named owner for every API.

Layered security: code, edge and monitoring

No single tool solves the problem. Protection that works combines three layers:

1. In the code: per-resource authorization, DTOs, input validation and rate limiting. This is where the root cause is removed.
2. At the edge: an API gateway with a WAF, such as Cloudflare's, in front of the server. It validates tokens, enforces limits, blocks known attacks and discovers undocumented endpoints before traffic reaches your infrastructure.
3. In monitoring: audit logs of who accessed what and when, alerts on abnormal behavior and records that meet privacy-law requirements.

Approach	Suited to	Limitation
API observability	Understanding traffic in staging	Identifies, but does not block
Lifecycle management	Regulated industries and legacy APIs	Strong on governance, weak on active protection
Web application and API protection (WAAP)	Production APIs	Must be combined with fixes in the code

Is your company exposed? Answer honestly

• Do you have an up-to-date list of every API in production, including vendors' ones?
• Does every query check that the record belongs to the token's user?
• Do tokens expire, and are they validated on every request?
• Do responses return only the fields the application uses?
• Is there a per-endpoint request limit and pagination on lists?
• Are there logs showing who accessed which personal data?
• Is there a protection layer (WAF or gateway) in front of the APIs?

If you answered “no” or “I don't know” to any item, your API probably has an open door, and it is better that you find it before someone else does.

How CPW protects your APIs

For more than 10 years we have been designing, building and maintaining APIs in whatever technology makes the most sense for each business, and security is part of the project from the first line of code, not a fix at the end. For companies that already have APIs in production, whatever the language or cloud, the work follows three steps:

1. Assessment: API inventory and tests based on the OWASP API Security Top 10, with a risk report prioritized by business impact.
2. Remediation: code changes such as per-resource authorization, DTOs, tokens and rate limiting, without stopping operations.
3. Ongoing protection: edge layer setup, monitoring and managed hosting with HTTPS and CDN.

Want to know whether your company's APIs are exposed? Talk to us on WhatsApp and book an assessment.

Cloudflare Radar and Gartner figures cited from Cloudflare's eBook “The CISO Guide to API Security” (2023). Vulnerability classification: OWASP API Security Top 10 (2023).