July 27, 2026
When we order food from our phones, check our bank accounts, or book a hotel via an app, various systems communicate with each other in the background. The structures that facilitate this communication are called APIs.
You can think of an API like a waiter in a restaurant. You place your order with the waiter; the waiter goes to the kitchen, conveys your request, and brings the prepared meal to you. Similarly, an API transmits a user's request to the system and sends the resulting response back to the application.
APIs make our daily lives easier. However, without proper controls, they can also turn into an uncontrolled gateway to the system's data.
Imagine you are viewing your own order in a shopping app. The app sends a request to the system asking it to "retrieve this user's order details."
In this scenario, it is not enough for the system to simply check the order number. It must also verify whether that order actually belongs to your account.
If this check is not performed, a malicious actor could alter the order number to attempt to view other customers' addresses, phone numbers, or purchased items.
A person might be logged into the system, but being logged in does not mean they should have access to every customer's information.
OWASP’s API security guide identifies this situation as one of the most critical API risks. The organization emphasizes that the API must independently verify the user's authorization to access the specific information for every request.
Sometimes, only your name and profile photo appear on the application screen. However, the API might also transmit your email address, account type, membership status, or other private information in the background.
Even if this information does not appear on the screen, it can be examined by individuals with technical expertise.
You can liken this to a scenario where you ask a store clerk only for a receipt, but they hand you the store's entire customer database instead. Even though you did not request this information, the system shared excessive data.
An API should transmit only the information necessary to complete the transaction. Passing unused data to the application with the mindset that it "might come in handy" can pose a serious security risk.
The number of requests that can be sent to an API must also be controlled.
For instance, if a user can send thousands of password reset messages within a few minutes, the system's message budget could be rapidly depleted. Similarly, thousands of requests to generate reports or download files could slow down the server.
This situation can sometimes lead to a complete service outage or incur high costs for the company.
In OWASP’s API Security Top 10 list, unrestricted resource consumption, broken authentication, misconfiguration, and forgotten legacy API versions are identified as significant risks.
Therefore, APIs should implement request limits, file size limits, and checks for suspicious usage.
Companies sometimes forget to shut down an old API when launching a new application. A connection created for testing purposes or an obsolete application version might remain active for years.
When these legacy systems are not updated, they become easier targets for attackers. If a company does not know which of its APIs are active, it cannot protect them. NIST's updated API protection guide emphasizes that security should not be an afterthought, considered only after the API has been made available for use. It recommends that security controls encompass the entire lifecycle, from the API’s design and development to its deployment and operational phase.
An API does not become a security vulnerability solely when subjected to external attacks. Risks also arise when there is a lack of control over the data users can access, the extent of operations they can perform, and the amount of information the system shares.
In short, the issue is not that the API acts as a gateway. The real problem lies in failing to control how far a person entering through that gateway can proceed once inside.
Disclaimer: This content has been prepared solely for general informational purposes. Each organization has a unique API infrastructure, security requirements, and risk profile. The information provided here does not constitute professional cybersecurity consulting. It is recommended that a comprehensive assessment be conducted by qualified security experts before making technical decisions regarding API security.
%201.svg)
