Three Years, Three Decisions, One Breach: The Silent Story of an API Vulnerability

In cybersecurity, the most devastating incidents are usually not the product of a sudden attack, but of small decisions that accumulate over time. In this article, we describe a case that happened to one of our clients and ultimately resulted in a KVKK (Turkish GDPR) breach notification, without any reference to the client's identity. Our goal is not to expose a single incident, but to contribute to preventing its repetition — because we have seen the same decisions made at many different organizations.

2024: The Finding Is Discovered

Our client was an organization serving approximately 3,000 corporate customers in Turkey. During our annual penetration test in 2024, we identified a critical IDOR (Insecure Direct Object Reference) vulnerability in the API layer.

The vulnerability allowed an authenticated user to access another customer's data by manipulating the resource identifier in the URL. In practice, this meant that a single valid session could reach the data of all 3,000 customers.

We flagged the finding as critical, reported it, and worked with the technical team to define the remediation approach. The client implemented the fix promptly. During retest, we confirmed the finding was successfully closed.

Up to this point, everything had gone right.

Late 2024: The Silent Regression

In the months following the delivery of the pentest report, the client's development team made various changes to the API. New features, refactoring work, performance improvements. During one of these cycles, the authorization control logic that had been fixed was reintroduced through a deployment.

Nobody noticed. The developers didn't notice because the change broke nothing functionally — the code worked, tests passed, users didn't complain. The security team didn't notice because there was no mechanism to verify whether a closed finding remained closed.

This is one of the most common situations we encounter in the field. A pentest report is a photograph of the moment its date was stamped. A vulnerability closed at that moment can be silently reopened in subsequent deployment cycles. For an organization that doesn't catch the moment of regression, that finding continues to appear as "closed" in the report.

2025: The Skipped Year

In 2025, our client decided to postpone their annual pentest during budget planning. Viewed in isolation, this seems like a defensible decision: a pentest had been conducted the previous year, critical findings had been closed, and there was an assumption that no major changes had occurred in the environment.

The problem is that the assumption of "no major changes" didn't measure what the development team was actually doing. That year saw dozens of commits to the API, several major releases, and multiple architectural changes. The vulnerability that was closed in 2024 and silently reopened had been running in production throughout 2025.

When a pentest is skipped, what's skipped is not an audit — it's an opportunity to see.

2026: Scope Narrowing

In 2026, our client brought the pentest back onto the agenda. However, this time they decided to narrow the scope due to budget constraints. During the narrowing, the API layer was excluded from scope.

The logic used in making this decision was one we hear frequently in the field: "You tested the API last time, a critical finding came out, it was closed. Let's focus on the web side now."

This logic rests on two separate assumptions:

1. That the previous finding remained closed,
2. That no new vulnerability had emerged in the API since then.

Neither assumption had been tested. Untested assumptions do not form a foundation on which security decisions can be based.

2026: The Breach

While our pentest work was ongoing — while we were conducting our tests on the web layer — an independent attacker scanned the API layer, discovered the IDOR that had been open since 2024, and systematically exploited it.

The attacker logged in with a valid account and then iterated through resource identifiers to pull the entire customer database. The data of 3,000 corporate customers was exfiltrated.

The breach was detected on Saturday. The client reached out to us the same day. Our incident response team engaged on Saturday: log analysis, impact scoping, IoC extraction. On Sunday, we conducted a detailed endpoint examination on WAF logs; we confirmed that the vector used by the attacker was the same endpoint, same pattern as the IDOR we had identified in 2024. This is not an assumption — it is a finding confirmed through log correlation. On Monday, we blocked the relevant endpoint and behavior pattern through the WAF, closing the attack surface.

The response was completed in 48 hours. But the data was already out.

The client filed a breach notification under KVKK. The notification became public.

The Combined Effect of Three Decisions

There is no single error in this incident. Three separate decisions — three decisions that each seem defensible when viewed independently — made a breach inevitable when they accumulated:

First decision: Not establishing a mechanism to verify whether a closed finding remained closed. This started not as a decision but as a decision gap — but the outcome was the same.

Second decision: Skipping a year's pentest cycle. Budget-efficient, risk-blind.

Third decision: Removing from pentest scope a component that had previously produced a critical finding. The logic of "we already looked at it" loses its validity when applied to a system that changes over time.

Each of these decisions is the kind that any organization makes every day. When they don't converge, they go unnoticed. When they do converge, the moment they converge is also unnoticed — the moment they're noticed is the moment the breach is detected.

Three Questions

The lesson we draw from this case is not technical — it is operational. Every organization should be able to answer three questions for their own processes:

1. How do you know when a closed finding is reopened in the next deployment? If the answer is "at the next pentest," the answer is insufficient. Regression operates much faster than pentest frequency.

2. When you postpone a pentest cycle, do you measure how much change accumulates in your system during the postponement? The volume of change determines the true scope of the next test. When unmeasured, there is no foundation for the decision either.

3. When you exclude a component from pentest scope, are you assuming that component is also out of scope for the attacker? The attacker doesn't see your procurement decision. For them, scope is your entire live attack surface.

Closing

What makes this case worth telling is not that it's dramatic — it's that it's ordinary. All three decisions are made at many organizations every year. All three have their own individual justification. And the consequences don't have to be the same every time they converge — but one day, when they do converge, the outcome is exactly this.

A pentest is not a deliverable — it is a step in a cycle. When the other steps of that cycle — finding tracking, regression control, scope discipline — are missing, the delivered report gradually becomes a photograph left in the past. The attacker, however, always looks at today.