API security means protecting application programming interfaces (API) you own and that you use from threats and vulnerability exploits that may lead to data loss, fraud, and business disruption. Historically, APIs were used for high speed, machine-to-machine communications but now they are core to everything we do digitally. Our cars, the smart appliances we use, the apps on our mobile devices that help us manage our lives are all API-based. This means that APIs play a critical role in your organizations revenue generation and profitability.
The explosive use of APIs, and their importance to your business has also made them the top target for attackers. Most security professionals would agree that the speed of API adoption has outpaced their efforts to apply oversight or implement appropriate security measures making API protection a top 2023 priority.
Types of API Security Risks and API Threats
The three types of API risks/threats that your API security solution must address are those defined by the Open Web Application Security Project (OWASP) API Security Top 10; those classified as business logic attacks and those that are vulnerabilities resulting from API coding errors.
- OWASP API Security Top 10: Common API security risks found in the public domain are tracked by OWASP, analyzed, and condensed into a top 10 list every few years. The list includes a definition of the risk and best practices on how to address it. The top 10 list is a great starting point, but it should not be your team’s sole focus – they must look beyond for complete API protection.
- Business Logic Abuse or OWASP API 10+: API business logic abuse is also known informally as OWASP API 10+, a category that encompasses the different ways attackers target perfectly coded APIs using techniques that are not categorized by, or use a combination of the OWASP API Security Top 10 Threats. Examples of OWASP API 10+ include large scale shopping bots, enumeration attacks and account takeovers – all against properly coded APIs.
- Coding Errors and Vulnerabilities: The last group of API security risks are coding errors that are publicly exposed and exploited by attackers. This group of API security risks places significant emphasis not only on pre-production API testing to find and fix the errors, but also on the actively detecting and mitigating the threat to protect the improperly coded API while development teams work to fix it.
API Security Requirements
Defining API security requirements for 2023 should entail three basic principles: discovery of all APIs, detection of risks and threats against the APIs and the remediation and mitigation of the risks and threats.
- API Discovery and Inventory: Most organizations underestimate the number of APIs they have because APIs are typically owned by development teams, who were often in different groups, and locations with little security oversight. The result is a wide range of API categories – managed, unmanaged, shadow, zombie, third-party, internal and external – that are difficult to discover and inventory. Keeping the fact that you cannot protect what you cannot see in mind, API discovery and inventory is the most critical first step and must encompass both an outside-in view and an inside-out view of all APIs.
- API Risk Analysis and Threat Detection: API risks are those that may result from a coding error which if left alone, could result in the threat of an exploit. Runtime API analysis can uncover APIs that do not have a specification or are out of conformance with existing specifications, which can then be addressed by development. Threat detection means finding vulnerabilities in pre-production as well as business logic attacks on perfectly coded APIs.
- API Risk Remediation and Threat Prevention: Remediation and mitigation of risks and threats detected via the runtime analysis in the detection phase is critical to API security. Remediation means notifying development teams of the risk detected and tracking the API fixes via continuous analysis and testing. Threat mitigation requires real-time responses without the need to signal a third-party infrastructure element such as a web application firewall (WAF). Mitigation responses such as block, rate limit, deception, and geo-fencing will help minimize the impact of an attack.
How is API Security Different?
API security differs from web application security and other forms of threat protection because APIs are different. APIs are computer code, with no user interface or front-end. This means traditional forms of web security such as a WAF, an API gateway, or API specific tools are ineffective at addressing the API protection requirements outlined above.
- Web Application Firewalls: Designed to address specific Payment Card Industry (PCI) requirements focusing on the OWASP Web Application Top 10 Threats list, WAFs do not perform automated API discovery, they struggle to detect unknown threats, and are unable to perform risk assessments or generate testing traffic.
- API Gateways: Designed to help organizations aggregate and manage APIs, an API gateway controls access and provides some basic security functions (e.g., rate limiting, IP block lists). API gateways are unable to proactively discover APIs that need to be managed, nor can they perform risk analysis, threat detection, remediation or mitigation.
- API Specific Toolsets: Like API gateways and WAFs, these tools address a portion of the API security requirements. Most are designed to try and help development produce APIs with fewer errors, which helps make APIs more secure, but they fall short of addressing the complete set of API security requirements as defined above.
The most effective form of API security is to make sure that the solution you choose addresses all phases of API development, not just run-time protection, or dev-ops coding analysis, or risk assessment.
API Security Best Practices
While each organization may approach API security from a different starting point, it’s important that you look at protecting your APIs across the entire lifecycle, not just at the management or development phase.
- Outside-in discovery: Gain an understanding of your public-facing API footprint to see what an attacker may see.
- Inside-out inventory: Complement an external view of your APIs and related resources with a comprehensive inside-out API inventory, including all existing APIs and connections.
- Compliance monitoring: Continually analyze existing and new APIs to keep them in compliance with specifications such as the OpenAPI specification and ensure high API coding quality, consistency, and governance.
- Threat detection: Even perfectly coded APIs can be attacked, so it’s critical to continuously scanning your entire API inventory for threats, including subtle business logic abuses and malicious activity that has not yet been observed.
- Threat prevention: It’s critical to be able to respond quickly and natively with countermeasures such as alerts, real-time blocking and even deception, without the need for added third-party data security tools.
- Ongoing API testing: Integrate API protection into development to complement API security efforts defined by shift left efforts within the organization, so risky code doesn’t go live.
Whether you are just starting your API security journey, or you are deeply entrenched in an API-first methodology, your 2023 API security initiatives should include a holistic view, across all phases, not just development, management or risk assessment. Following the recommended best practices ensures that even the most innovative and resourceful bad actors will experience fatigue, and ultimately, failure, while ensuring that your APIs and your data are protected.
Never miss an update!