So You Want to Be an API Security Expert?
In his oft-quoted book, “The Art of War,” Chinese general Sun Tzu said, “If you know the enemy and know yourself, you need not fear the result of a hundred battles.” In the context of cybersecurity, what he said next is even more important: “If you know yourself but not the enemy, for every victory gained you will also suffer a defeat.”
In summary: To know your enemy, you must become your enemy.
Security pros know the importance of maintaining an inventory of APIs, staying abreast of the constant changes in risk landscape and monitoring for potential security exposures. But to truly become an API security expert, you need to think like an attacker, anticipate tactics and techniques and build in safeguards and countermeasures to mitigate risk.
API Security Experts Train in the Art of Threat Modeling
OWASP
The Open Web Application Security Project (OWASP) is a nonprofit foundation that works to improve the security of software. The foundation’s flagship project is the OWASP Top 10 list of the most critical security risks faced by web applications. OWASP also maintains an API Security Top 10 list focused on the unique security risks for application programming interfaces (APIs).
Let’s dive into the top risks for API security that you need to consider during threat modeling:
| Risk | Name | Description |
| API1:2019 | Broken Object-Level Authorization | Attackers exploit API endpoints by manipulating the ID of an object that is sent within the request, potentially leading to data disclosure to unauthorized parties, data loss, data manipulation and full account takeover. |
| API2:2019 | Broken User Authentication | Bad actors target authentication components potentially vulnerable to exploits and abuse to gain control of accounts, exfiltrate sensitive data and execute fraudulent transactions. |
| API3:2019 | Excessive Data Exposure | A hacker intercepts sensitive data returned by an API that fails to filter properly. |
| API4:2019 | Lack of Resources & Rate Limiting | Bad actors abuse APIs that don’t have proper rate limiting, resulting in requests consuming resources such as network, CPU, memory and storage — leading to denial of service (DoS) — making the API unresponsive or even unavailable. |
| API5:2019 | Broken Function-Level Authorization | An attacker gains access to unauthorized functionality, such as administrative functions, by sending legitimate API calls to an endpoint they should not have access to. |
| API6:2019 | Mass Assignment | Bad actors capitalize on functions that automatically bind input from the client into code variables and internal objects to update or overwrite properties — leading to privilege escalation, data tampering and bypass of security mechanisms. |
| API7:2019 | Security Misconfiguration | Attackers find unpatched flaws, common endpoints, or unprotected files and directories to gain unauthorized access or knowledge of the system – exposing sensitive data and uncovering details that may lead to full system compromise. |
| API8:2019 | Injection | Attackers feed an API with malicious data through injection vectors, such as direct input, parameters and integrated services, which is then sent to and executed by the interpreter — leading to information disclosure, data loss, DoS or system takeover. |
| API9:2019 | Improper Assets Management | Bad actors exploit a vulnerable/unpatched API, resulting in access to sensitive data and potential system takeover. |
| API10:2019 | Insufficient Logging & Monitoring | Attackers take advantage of inadequate logging and monitoring to abuse systems without being noticed. Without visibility over ongoing malicious activities, attackers have plenty of time to fully compromise the system. |
Figure 1 – OWASP API Security Top 10
STRIDE and DREAD
Microsoft created the STRIDE methodology as a security threat model for use during the design phase to identify threats its products might be exposed to in production.
| Category |
Description |
|
| S | Spoofing | Impersonation of a valid user or resource to gain unauthorized access. |
| T | Tampering | Modification of system or user data with or without detection. |
| R | Repudiation | Execution of an untrusted or illegal operation in an untraceable way. |
| I | Information Disclosure | Exfiltration of private and/or business-critical information. |
| D | Denial of Service | Attack on a system that leaves it temporarily unavailable or unusable. |
| E | Elevation of Privilege | Tactic where an attacker gains privileged access to a system with the ability to compromise or destroy it. |
Figure 2 – STRIDE Methodology
Microsoft also has a qualitative risk calculation for evaluating threats, known as DREAD.
| Category |
Impact on Scoring System |
|
| D | Damage | How bad would an attack be? |
| R | Reproducibility | Can an attack be easily reproduced? |
| E | Exploitability | How easy is it to mount a successful attack? |
| A | Affected Users | How many users are impacted? |
| D | Discoverability | What is the likelihood of this threat being discovered? |
Figure 3 – DREAD Risk Calculation
Guidance from OWASP, STRIDE and DREAD can help you analyze various threat scenarios. For example, the OWASP vulnerability API4:2019 Lack of Resources & Rate Limiting details several scenarios where attackers target APIs where rate limiting is not properly configured or not implemented at all.
In this screenshot, the Microsoft STRIDE/DREAD tool uses a data flow diagram (DFD) to evaluate a DoS threat against an API gateway where no rate limiting is in place, revealing the high risk of a system crash.
Figure 4: Microsoft Threat Modeling Tool
The Zone of Zero Trust
A traditional zonal network architecture, or perimeter-based network design, is based on the concept of security “zones,” which are logical groupings in a network that share policies and requirements. Instead of a completely open or flat network, this architecture segments infrastructure services into zones to mitigate risk by containing the “blast radius” of an attack.
A key feature of this architecture is that all users and devices within a zone are implicitly trusted and thus authorized to set or change the policies, requirements and other security settings for the zone.
This is akin to a “castle and moat” defense. But even the best castles and moats can be breached. The traditional approach of trusting users and devices within a “corporate perimeter” is not relevant in complex modern environments that span architectures, clouds and organizational responsibilities. One reason security is evolving toward a zero-trust architecture is to mitigate scenarios where an attacker gets inside the castle walls.
Zero trust represents a paradigm shift to perimeter-less security, built on the foundational premise of “never trust, always verify.” There is no implicit trust, even for a messenger cleared to cross the network moat and enter the application castle.
Zero trust mandates that authentication and authorization are continuously evaluated and assessed, including verification of identity and integrity, without relying on factors such as user class (administrator, authenticated/non-authenticated, partner) or device location. It aims to provide a minimal level of access to apps, APIs and services based on risk.
Key principles of zero trust include:
- Know your architecture, including users, devices, services and data.
- Know your user, service and device identities.
- Assess user behavior, device and service health.
- Use policies to authorize requests.
- Authenticate and authorize everywhere.
- Monitor all access by users, devices and services.
- Don’t trust any network, including your own.
- Choose and design services for zero trust.
Adopting zero trust principles allows API security ninjas to support zero trust and zonal network architectures, bridging the gap between on-premises and cloud-based systems, and enforcing consistent security across hybrid environments — for example, with a service mesh that facilitates micro-segmentation.
What’s Next?
After building a solid foundation encompassing API fundamentals, management and security, let’s put these concepts into action and modernize a legacy app by re-platforming it for the cloud. Follow a hypothetical case study in the free O’Reilly eBook, “Mastering API Architecture,” to further explore methods for redesigning applications into API-driven architectures and weighing the operational and security benefits of cloud-based platforms.
