Today’s digital economy runs on application programming interfaces, or APIs (Application Programming Interfaces). They have become the invisible but absolutely crucial bloodstream that powers almost every modern service. Your mobile app communicates with your server via APIs. Your online store processes payments by calling the payment provider’s API. Your ERP system integrates with your partner’s CRM platform via an API. These are the silent heroes, working in the background, who enable the seamless exchange of data between thousands of different systems, creating a cohesive and connected digital ecosystem.
However, this key role has also made APIs the number one target for cybercriminals. Attackers have realized that instead of trying to push through complex, multi-layered web application security, it is often much easier to attack directly its “back-end” - APIs, which by design are created for programmatic data exchange. Unprotected, misconfigured or simply “forgotten” by the security department, APIs are a simple and direct route to a company’s most valuable data and business logic. Protecting APIs has ceased to be a technical detail and has become a strategic necessity.
Shortcuts
- What are APIs and why is their role in modern applications so crucial?
- Why has API security become one of the biggest challenges for SecOps teams?
- What are the biggest threats to APIs according to the OWASP API Security Top 10 project?
- What is the “Broken object level authorization” (BOLA) threat and how to protect against it?
- What role do OAuth 2.0 and OpenID Connect standards play in secure authentication and authorization?
- What is an API gateway and what role does it play as the first line of defense?
- How does nFlo help companies audit and comprehensively secure their APIs?
What are APIs and why is their role in modern applications so crucial?
An Application Programming Interface (API) is a set of rules and protocols that allows two different applications to communicate with each other and exchange data in a structured way. The API works like a waiter in a restaurant: You (the client application) give him an order in a certain way, he carries it to the kitchen (the server application), and then returns with the finished dish (data). You don’t need to know how the kitchen works - it’s enough that you know the “language” (query format) that the waiter uses.
In today’s world, dominated by microservices architecture, mobile applications and cloud services, the role of APIs is fundamental. Applications are no longer monolithic building blocks, but complex systems consisting of dozens of smaller, independent services that communicate with each other precisely through APIs. APIs have become the de facto language of modern software.
With APIs, your company can share its data and functionality with business partners, create feature-rich mobile applications and integrate with global platforms. This “API economy” drives innovation, but at the same time creates hundreds of new publicly or internally accessible “entry points” into your systems, each of which must be carefully secured.
📚 Read the complete guide: Cloud Security / AWS: Bezpieczeństwo chmury publicznej - AWS, Azure, best practices
Why has API security become one of the biggest challenges for SecOps teams?
API security has become such a major challenge for several reasons that stem from the very nature and evolution of the technology. First, traditional security tools often fail. Classic Web Application Firewalls (WAFs) were designed primarily to protect traditional, server-side rendered, human-operated web pages. They can have trouble correctly interpreting and protecting structured, machine-readable API communications (e.g., in JSON format), leading to bypassing their rules.
Second, APIs dramatically increase the attack surface. Each publicly available API endpoint is a new potential “doorway” into a system. In complex applications, these endpoints can number in the hundreds, and each can contain unique vulnerabilities in business logic, authentication or authorization. Security teams often don’t even have full visibility and inventory of all the APIs running in an organization.
Third, responsibility for API security is diluted. Developers, focused on functionality and rapid product delivery, often lack deep knowledge of the specific attack vectors on an API. SecOps teams, in turn, may not fully understand the business logic implemented in a given API, making it difficult for them to assess risk. Successful API security requires close collaboration within the DevSecOps model.
What are the biggest threats to APIs according to the OWASP API Security Top 10 project?
As with web applications, the Open Web Application Security Project (OWASP) has created a dedicated list of the biggest threats to APIs, known as the OWASP API Security Top 10, which serves as a key guide for anyone involved in developing or protecting APIs. The top and most common threats used by attackers include:
-
API1:2023 - Broken object level authorization: The most serious and common threat. Occurs when the API fails to properly verify that the user making the request actually has authorization for the object (data) it is requesting.
-
API2:2023 - Broken authentication: Errors in the implementation of authentication mechanisms that allow an attacker to assume the identity of other users.
-
API3:2023 - Broken object property level authorization: Similar to BOLA, but more granular. Occurs when a user is allowed to access or modify particular fields (properties) of an object to which he should not have authorization.
-
API4:2023 - Unrestricted resource consumption: No limits on the number or size of requests, allowing Denial of Service (DoS) attacks or excessive load on the system.
-
API5:2023 - Broken function level authorization: Similar to BOLA, but applies to access to various functions/operations in the API, not to data.
Understanding and being able to test for these risks is absolutely key.
What is the “Broken object level authorization” (BOLA) threat and how to protect against it?
BOLA (Broken Object Level Authorization), ranked as the number one threat by OWASP, is the scourge of modern APIs. The bug is that an application, after authenticating a user, fails at a later stage to verify that the user has the right to access the specific data record (object) he or she is requesting.
Let’s imagine a simple scenario: a banking app provides an API with the /api/v1/accounts/{accountId}/balance endpoint to retrieve the account balance. User Jan Kowalski, with ID 123, logs in and his mobile app sends a request to /api/v1/accounts/123/balance. The server correctly verifies that Jan is logged in and returns his balance. However, an attacker, who is also a logged-in user (e.g., with ID 456), modifies this query and sends it to the server, but with a changed ID: /api/v1/accounts/123/balance.
If the API is vulnerable to BOLA, the server will only check that the attacker is a logged-in valid user, but will not check that the ID in the query (123) is the same as the ID of the logged-in user (456). As a result, it will return the balance of John Smith’s account to the attacker. BOLA protection requires that for every, absolutely every, data operation, the application logic should explicitly verify the privileges of the logged-in user to the specific object it is trying to access.
The most important threats to API (according to OWASP) and how to protect yourself
| Hazard category (OWASP) | Risk description | A key defense mechanism |
|---|---|---|
| Erroneous authorization at the object level (BOLA) | The API does not check whether the user has the right to access the specific data record they are requesting. | Rigorous verification of authorization for each object at each operation. Centralization of authorization logic. |
| Faulty authentication | Weak passwords, lack of protection against brute-force attacks, faulty implementation of JWT, lack of MFA. | Use of standards (OAuth 2.0, OIDC), enforcing strong passwords and MFA, account lockout mechanisms. |
| Data overexposure | The API returns more fields and data than the client needs, potentially exposing sensitive data. | Designing the API according to the “minimum necessary data” principle. Server-side response filtering. |
| No resource constraints | No limits on the number of requests, allowing DoS attacks and excessive resource consumption. | Implementation of mechanisms for limiting requests (rate limiting) and limits on the size of transmitted data. |
What role do OAuth 2.0 and OpenID Connect standards play in secure authentication and authorization?
Trying to “invent from scratch” authentication and authorization mechanisms for APIs on your own is a straight road to disaster. Cryptography and identity management are extremely complex domains where it is easy to make a subtle but critical mistake. Therefore, the absolute best practice is to rely on open, battle-tested and internationally recognized standards.
OAuth 2.0 is an open standard for authentication. Its main purpose is to allow a client application to gain limited access to a user’s resources on an HTTP server, without having to share the user’s password with that application. It works on the principle of delegation of privileges. The user, by logging into the authorization server, grants the client application permission (in the form of an access token) to access certain resources on his behalf. This token has a limited lifetime and range of permissions (scopes).
OpenID Connect (OIDC) is a simple identity layer built on top of the OAuth 2.0 protocol. While OAuth 2.0 deals with authorization (“what can an application do?”), OIDC deals with authentication (“who is the user?”). It allows applications to verify a user’s identity based on the authentication performed by the authorization server. OIDC provides a standard way to obtain basic user profile information in a secure manner. Using these standards significantly improves API security and interoperability.
What is an API gateway and what role does it play as the first line of defense?
An API Gateway is an intermediary server that acts as a single, unified entry point for all requests directed to one or more internal APIs. Instead of allowing client applications to call individual microservices directly, all traffic is first routed to the API Gateway, which acts as a central “gatekeeper” and “dispatcher.”
From a security perspective, API Gateway is a key centralized policy enforcement point and first line of defense. It relieves individual microservices developers of the need to implement many repetitive security functions by centralizing them in one place.
A modern API Gateway can perform a number of critical security functions, such as:
-
Authentication verification: Verifying the correctness and validity of access tokens (e.g., JWT) before passing the request on.
-
Limiting the number of requests (Rate Limiting): Protecting backend services from DoS attacks and abuse.
-
Traffic inspection (WAF): Many API gateways have built-in application firewall (WAF) functions that can filter traffic for known attack patterns.
-
Logging and monitoring: Centrally collect logs from all API requests in one place.
-
Routing and transformation: routing requests to appropriate internal services.
How does nFlo help companies audit and comprehensively secure their APIs?
At nFlo, we view API security as a critical, though often underestimated, component of the overall security posture of the application and the organization as a whole. Our approach is comprehensive and based on a deep understanding of both the technology and the business logic behind APIs.
Our core and most important service in this area is specialized API security testing. Our team of experts performs in-depth manual and automated analysis of APIs, simulating the actions of real attackers and systematically testing them against all threats on the OWASP API Security Top 10 list. We focus on finding critical, often subtle flaws in authorization logic (such as BOLA) that are invisible to automated scanners.
We don’t stop at testing. We also offer consulting services in the design of secure API architecture. We help select, implement and configure API Gateway, design secure authentication schemes based on OAuth 2.0 / OIDC, and help define rate limiting policies. As part of our DevSecOps services, we support organizations in integrating automated API security testing tools (DAST for APIs) directly into their CI/CD pipelines, promoting a “security by design” culture and ensuring that API security is an integral part of the development process.
Related Terms
Learn key terms related to this article in our cybersecurity glossary:
- API Security Testing — API security testing is the process of evaluating and verifying the security of…
- CSPM (Cloud Security Posture Management) — CSPM (Cloud Security Posture Management) is a category of cloud security tools…
- Cybersecurity — Cybersecurity is a collection of techniques, processes, and practices used to…
- Cybersecurity Incident Management — Cybersecurity incident management is the process of identifying, analyzing,…
- Cloud Environment Security — Cloud environment security refers to the technologies, procedures, policies,…
Learn More
Explore related articles in our knowledge base:
- FortiSASE - comprehensive cloud security for modern organizations
- IoT and embedded systems security: How to test and protect smart devices?
- Kubernetes security: How to protect K8s clusters and containers from attacks?
- Microsoft 365 and Google Workspace security: 12 steps to protect your data
- Mobile app security testing: How to protect data on Android and iOS platforms?
Explore Our Services
Need cybersecurity support? Check out:
- Security Audits - comprehensive security assessment
- Penetration Testing - identify vulnerabilities in your infrastructure
- SOC as a Service - 24/7 security monitoring
Explore Our Products
Solutions mentioned in this article that can help protect your organization:
- FortiSASE — Fortinet
