API Security 101

What Is API Security

API security means protecting the APIs and their associated digital assets. With so much of our digital world supported by APIs, the need for API security is staggering. The speed of API adoption had far outpaced most organizations efforts to apply oversight or implement appropriate API security measures.

The shopping, financial management, food delivery, or ridesharing apps we use are API-based. The cars we drive, the tablets, mobile devices, and smart home appliances we use are API-based. History has shown that the rapid adoption of a particular technology is followed by an equivalent growth in cyber threats as exemplified by the rash of API security related incidents over the past 2 years. The market has responded with a wide range of solutions designed to address the need for improved API security, resulting in confusion.

Organizations are being told that their WAF and API gateway are sufficient to protect their APIs. In other cases, they are told that a shift-left, DevOps effort combined with better testing is how API security is defined. Lacking from these recommendations is how to protect a perfectly coded API. The truth is all phases of API development must be considered and a great place to start is with the resources available from the Open Web Application Security Project (OWASP).

Secure APIs from Common Attacks – OWASP API Security

OWASP has published data regarding the API Security Top 10, which describes the ten most common API security flaws. The OWASP API Security Top 10 is a good starting point for securing APIs and understanding common security vulnerabilities in APIs. The OWASP API Security Top 10, and the risks they introduce are:

• API1:2019 Broken object level authorization (BOLA): Insufficient validation of an object access request allows an attacker to perform an unauthorized action by reusing an access token.
• API2:2019 Broken user authentication: Poorly implemented user authentication allows attackers to impersonate legitimate users by exploiting implementation flaws in authentication mechanisms.
• API3:2019 Excessive data exposure: A published API might expose more data than necessary, relying on the client app to perform the necessary filtering.
• API4:2019 Lack of resources & rate limiting: By not implementing rate limiting policies, attackers can overwhelm the backend with denial-of-service attacks.
• API5:2019 Broken function level authorization: Allows an attacker to perform actions by sending requests to functions they are unauthorized to access.
• API6:2019 Mass assignment: Unfiltered data provided via APIs to client apps allows attackers to guess object properties via requests.
• API7:2019 Security misconfiguration: Commonly a result of insecure, incomplete or ad-hoc configurations, verbose error messages containing sensitive information and other HTTP related coding errors.
• API8:2019 Injection: Untrusted injection of data, such as SQL, NoSQL, XML Parsers, ORM, LDAP, OS Commands, and JavaScript, resulting in the execution of unintended commands or unauthorized data access.
• API9:2019 Improper assets management: Insufficient environment management and environment segregation allows attackers to access under-secured API endpoints.
• API10:2019 Insufficient logging & monitoring: Insufficient logging, monitoring, and alerts allows attacks in progress to go undetected.

Successful API Attacks

API security incidents are on the rise with attackers finding exploitable errors as defined in the OWASP API Top 10 and targeting gaps in business logic. One of the more recent API security attacks was against Optus Telecom where the malicious actor was able to retrieve the personal information by exploiting several exploits listed in the OWASP API Security Top 10 list. Much like previous API security incidents that have made the news, the attacks have a significant impact on the business bottom line.

How Has Security Changed to Protect API Data?

As noted above, organizations are approaching the API security challenge in an ad hoc manner. The problem with this approach is that they have no way to uncover all the (shadow, or zombie) APIs and API vulnerabilities without knowing where to look. Even if all APIs are discovered and known, attackers can still leverage seemingly legitimate transactions to steal data or commit fraud. Traditional approaches that use WAFs or API gateways depend on easily evadable detection, lack the real-time ability to discern good from bad API activity and are reliant on static, least common denominator protection spread across multiple technology components.

API Protection Best Practices

While each organization may approach their API security efforts from a different starting point or focus, its important that they look at ways to protect their APIs across the entire lifecycle, not just at the management or development phase. Improving your API key protection posture requires a collaborative effort that includes developers, application owners and the security team.

• 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 protection journey, or you are deeply entrenched in an API-first methodology, it is critical that you look at API security holistically, across all phases, not just development, management, or detection. Being able to see the attack traffic, analyze it, respond, and adjust based on the results is not something that can easily be accomplished when pieces of the puzzle are missing or when using multiple solutions. 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.