Last updated: 2026-07-27
An application can authenticate every user correctly and still expose personal data to the wrong people.
That is the central risk illustrated by a public data-breach notice issued by Türkiye’s Personal Data Protection Authority on 22 July 2026 concerning Global Bilgisayar Kontrol Sistemleri San. ve Tic. A.Ş.
According to the notice, an attacker exploited an authorization weakness in the controller’s application infrastructure and obtained unauthorized access. An endpoint could return up to 1,000 basic-profile records in a single call. The announced breach affected 1,022 people, including users, personnel and patients.
The notice is important, but technically limited. It does not state that the endpoint was an API, explain the authorization logic that failed, give the duration of the unauthorized access or say whether the attacker merely viewed the records or retained copies.
Organizations should therefore avoid assigning a definitive OWASP classification to this specific incident. The more useful lesson is broader: authentication, response-size limits and user-role fields do not protect personal data unless authorization is enforced for every object, function, property and business context.
The distinction between confirmed facts and technical interpretation matters, particularly while the KVKK investigation remains open.
The notice does not disclose:
These points should not be inferred from the brief description. In particular, the words “endpoint” and “call” are consistent with API terminology but do not conclusively establish that the affected interface was an API.
Authorization determines what an identified user, service or device is permitted to do.
An authorization vulnerability exists when an application does not correctly enforce those permissions. A person may be legitimately signed in but still be able to:
Authorization should normally be enforced on the server for every relevant request. Hiding a button, removing a menu option or relying on restrictions in a browser or mobile application is insufficient because client-side controls can often be bypassed.
Authentication and authorization solve different problems.
Multi-factor authentication can make account takeover more difficult. It does not prevent a properly authenticated account from exploiting a broken authorization rule.
Similarly, a valid session token only proves that the application accepted the user’s identity. It does not prove that every request made with that token is permissible.
The 2026 public notice does not provide enough detail to classify the vulnerability. Nevertheless, organizations operating APIs or comparable application endpoints should test for several recurring authorization failures.
An application receives an identifier for a user, patient, order, file or other record but does not verify whether the requester is entitled to access that specific object.
For example, changing:
/patients/4812to:
/patients/4813should not return another patient’s information merely because both records exist.
The control must evaluate the relationship between the requester and the requested object, not simply whether the requester has logged in.
A standard user can invoke a function intended for an administrator, clinician, support employee or another privileged role.
This can occur when the interface hides the function but the server does not independently enforce the role restriction.
A user is entitled to access an object but receives fields that are unnecessary for their role.
For example, a scheduling user may need a patient’s name and appointment time but not clinical notes, identity-document details or internal risk flags.
Field-level restrictions should be applied before the response is generated. Sending all fields to the client and merely hiding some of them in the interface does not provide effective protection.
A system may contain roles such as standard user, employee, clinician, administrator or support operator but apply those roles inconsistently across endpoints.
A role label in a database is not itself an access control. Each protected operation must map the role—and any additional conditions—to a specific permission.
In multi-tenant systems, authorization must prevent one customer’s users from accessing another customer’s records.
Filtering only by record identifier, without also enforcing the relevant tenant or organization identifier, can create cross-customer exposure.
Roles alone are often too broad for healthcare and other sensitive environments.
A clinician’s role may establish a general capability to access patient information, but access may still need to depend on an active treatment relationship, assigned department, location, emergency-access procedure or another documented context.
A maximum response size can reduce resource consumption and, in some circumstances, limit the amount of data returned by one request. It is not an authorization control.
A limit of 1,000 records does not answer the central question: was the requester permitted to see those records?
Even a single unlawfully disclosed record can constitute a personal-data security incident. The seriousness of the impact depends on more than the percentage of the database affected. Relevant factors can include:
Response-size limits, pagination, rate limits and query-cost controls remain useful defence-in-depth measures. But they should operate alongside authorization, not substitute for it.
A secure endpoint should generally determine:
The public notice lists names, telephone numbers, email addresses and system roles as the affected data. It does not state that diagnoses, medical records, treatment details or other health information were accessed.
That limitation should be preserved when reporting the incident.
However, context still matters when evaluating possible harm. Connecting an identified person with a patient group, healthcare-related service or particular system can be more sensitive than exposing the same contact details without that context. It may support convincing phishing messages, impersonation attempts or unwanted inferences about the individual.
Organizations should therefore assess both the fields exposed and what those fields reveal when combined with:
For patient-facing systems, authorization design should also consider whether a user has a legitimate relationship with the particular patient. Giving every employee with a broad “staff” or “healthcare professional” role access to all patient records is rarely an adequate least-privilege model.
Possible controls include:
The appropriate model depends on the application, applicable sector rules and operational requirements.
Authorization controls can fail because of coding errors, configuration changes, undocumented endpoints or inconsistent rules between application versions. Logging and monitoring are therefore necessary both for early detection and for later breach assessment.
Relevant logs may include:
Logs should not unnecessarily reproduce the sensitive data contained in the response. They must also be protected from unauthorized modification and retained for a period aligned with the organization’s risk assessment, legal requirements and incident-response needs.
Useful detection scenarios include:
Monitoring should be based on expected behaviour for each role. A request volume that is ordinary for an authorized reporting service may be highly abnormal for a standard user.
When unauthorized access is suspected, the organization needs to contain the exposure without destroying the evidence required to understand it.
A practical response should include the following stages.
Record when the alert was received, when the organization first became aware of a possible personal-data breach, when the incident was confirmed and who made each decision.
The KVKK notification period is linked to when the controller learned of the breach. That makes a documented discovery timeline particularly important.
Depending on the incident, containment may involve:
Emergency changes should be documented and tested. A rushed patch can create another exposure or remove evidence.
Before logs rotate or systems are rebuilt, preserve relevant:
Evidence should be handled in a manner that preserves integrity, access history and chain of custody where appropriate.
The investigation should distinguish among:
Absence of evidence of downloading is not automatically evidence that data remained unseen. The conclusion should be based on available logs, response records, attacker activity and the limitations of the monitoring environment.
Before restoring normal access, test the endpoint across:
Regression tests should be added so the same authorization failure does not return during a later release.
Article 12 of Law No. 6698 requires data controllers to take the technical and administrative measures necessary to prevent unlawful processing and access and to ensure the protection of personal data.
Under Article 12(5), when processed personal data is obtained by others through unlawful means, the controller must notify the affected person and the Personal Data Protection Board as soon as possible.
The Board’s Decision No. 2019/10 interprets “as soon as possible” as requiring notification to the Board without delay and no later than 72 hours after the controller learns of the breach.
If all information is not immediately available, the controller may provide it progressively without undue delay. A controller that cannot notify within 72 hours for a justified reason must explain the delay.
The decision also requires controllers to:
Affected individuals must be informed within a reasonable period after they have been identified. Where contact information is available, communication should be made directly. If direct communication is not possible, another appropriate method, such as publication on the controller’s website, may be used.
Under Decision No. 2019/271, the affected-person communication should use clear and plain language and contain at least:
The July 2026 notice does not disclose the controller’s discovery date, its notification date or whether affected individuals were contacted directly. It therefore does not provide enough information to assess notification timing or communication compliance.
Organizations should not delay an initial Board notification merely because forensic analysis is incomplete. The staged-notification mechanism exists for situations where the controller knows that a reportable breach has occurred but is still determining its full cause or scope.
The disclosed record limit and the percentage of the overall database affected provide useful scope information, but they should not distract from the control failure at the centre of the notice.
An endpoint that returns 10, 100 or 1,000 records still needs to decide whether the requester is entitled to receive each record and each returned field. Authentication, pagination and rate limiting cannot make that decision.
Organizations handling customer, employee or patient information should test authorization as a distinct security layer. That means testing not only who can log in, but what each user can access, under which role, for which organization, in relation to which person and in what operational context.
The final regulatory conclusions in this incident remain unknown. Until the KVKK Authority completes its examination or publishes a later decision, the technical cause should be described only at the level confirmed by the public notice: exploitation of an authorization vulnerability in the application infrastructure resulting in unauthorized access.
Kooch Cybersecurity & Compliance helps organizations examine how application security, access governance, incident response and KVKK obligations connect in practice.
This can include reviewing access-control documentation, incident-response processes, processor arrangements, evidence retention and the privacy implications identified through a KVKK/GDPR Gap Analysis or ongoing compliance engagement. Product-specific vulnerability testing may require coordination with appropriately qualified application-security specialists.
