Why do we need the A10 entry in the OWASP Top 10?

Without any doubt, APIs have redefined the enterprise architecture landscape by becoming the building blocks of internal and external enterprise applications. APIs are now the entry point into most architectures, much like servlets and JSPs were in the application server era. APIs give access to a wide range of applications, systems, databases and now things with the expansion of IoT. 

In the latest edition of the Top 10 OWASP threats list, APIs have been singled out under “A10: unprotected APIs“. Granted, the threats associated to APIs are not new, and one might wonder why APIs deserve their own entry. But as Jeff Williams (OWASP Top 10 project creator and co-author) mentioned in an interview to the SDTimes, the goal of this list is primarily to draw attention to the problem at hand.

I can only agree with Jeff’s statement.

False assumptions regarding API Security

The nature of APIs and the clients consuming them have little impact on whether APIs should be properly secured or not:

1. An API must be protected even if it’s only used by applications and not exposed publicly to consumers. Applications can be reverse-engineered and APIs calls uncovered. Do not count on obscurity to protect your assets.
2. Do not count on clients to filter or validate data: if your API accepts a credit card number, the format must be validated at the API level. Don’t expect the application to have done this properly.
3. Do not trust any client, internal or external (e.g. public), as any of them could have been compromised.
4. 3rd party APIs (typically to SaaS applications) must be secured and monitored just like your own APIs. Although they are exposed by a 3rd party, they manipulate sensitive enterprise data and could also have been compromised.

Challenges of API security

While API security is one of the core concerns of enterprises, applying API security is often a challenge. We have spoken with many customers in the past year and the following patterns emerged from those discussions:

• The need for innovation often collides with the need to protect enterprise assets: while innovation calls for openness and easy access to data and process, security teams scramble to keep the fuzzy borders of their enterprise safe.
• API security is a complex topic, often poorly understood by development and security teams
• Applying security is often seen as an obstacle to rapid delivery.
• Current API Management platforms do not address the need for developers, security teams and infrastructure teams to efficiently collaborate around APIs development and deployment.
• Security is often an afterthought and not considered at development time: APIs are “thrown over the fence” to security teams, often at the last minute, with no sufficient information on the APIs usage for security teams to take proper decisions.

All those challenges lead to under-protected APIs, which pose a real risk to the enterprise.

How do we address API Security ?

The under-protected APIs threat must be addressed by enterprises along three axes :

1. The democratization of API security and standards: a set of pre-approved, pre-tested policies are selected by describing the security level required, rather than by coding security. For example, an API is tagged as a financial API, with read-only access to data. From this information, a threat level is evaluated. The proper TLS, OAuth, OpenID Connect configuration and data confidentiality/integrity settings are then applied to the API.
2. The collaboration of development, security and operations teams during the API lifecycle: this collaborative space allows all constituencies to understand the API definition, where it will be deployed, by who it will be used, and in-fine evaluate the risk associated to the API.
3. The industrialization of security, by implementing “security as code” a.k.a DevSecOps: security must be part of the API lifecycle and fully automated. Same threats detection and protection tools are used from the development stage throughout production. Security policies are applied to APIs as part of the continuous delivery/testing process.

At 42Crunch, we are building a platform which lets enterprises address the A10-Unprotected APIs OWASP threat: it features API attacks protection through our self-configured API firewall, automatic generation of security policies from API risk evaluation, a collaboration space for all teams as well as a DevSecOps friendly architecture. We will deep dive in each of those in further blogs.