Security-first API Design

What is API Security?

API security is the application of any security best practice applied to web APIs, which are prevalent in modern applications. API security includes API access control and privacy, as well as the detection and remediation of attacks on APIs through API reverse engineering and the exploitation of API vulnerabilities as described in OWASP API Security Top 10.

Because APIs (REST, GraphQL, SOAP) are often available over public networks (access from anywhere) and in many cases they are typically well documented, they are highly sensitive to denial of service (DDOS) type incidents. In general, APIs are attractive targets for bad actors. An attack might include bypassing the client-side application in an attempt to disrupt the functioning of an application for other users or to breach private information.

API security is focused on securing this application layer and addressing what can happen if a malicious hacker were to interact with the API directly.

API Security Is A Growing Concern

In a new report released on Monday by ImVision, "API Security is Coming," the company asked over 100 cybersecurity professionals in the US and Europe for insight on the current state of enterprise API security.

Some highlights from the report:

Over the next 24 months, 91% of security leaders will be making API security a priority, while 80% would like to gain more control over their APIs.
This is not surprising given how many APIs companies currently have: 73% of enterprises use more than 50 APIs, and growing.
This is tough to manage, especially when you consider that 4 out of 5 publish APIs for external consumption by partners and clients.
Ultimately, only 1/3 of security leaders think their APIs get the protection they need.

API development has increased astronomically in the past few years, fueled by digital transformation and the central role APIs play in both mobile apps and IoT. This growth is making API security a top concern, as we clearly also can see from the report.

Understanding API Security Vulnerabilities

A common understanding of the specific threats that enterprises need to defend against is essential. Long known for and relied upon for its original OWASP Top 10 web security vulnerabilities, OWASP recently launched an API-specific list: the OWASP API Security Top 10 vulnerabilities.

OWASP API Security Top 10

API1: Broken Object Level Authorization
API2: Broken Authentication
API3: Excessive Data Exposure
API4: Lack of Resource & Rate Limiting
API5: Broken Function Level Auth
API6: Mass Assignment
API7: Security Misconfiguration
API8: Injection
API9: Improper Asset Management
API10: Insufficient Logging & Monitoring

Security in API Specifications

Let's consider the #1 in the OWASP Top 10 Web Application Security Risks which is Injection. Injection flaws, such as SQL, NoSQL, OS, and LDAP injection, occur when untrusted data is sent to an interpreter as part of a command or query. The attacker’s hostile data can trick the interpreter into executing unintended commands or accessing data without proper authorization.

API specifications like OpenAPI or AsyncAPI support security schemes that can be defined across the APIs, they also support JSON schema for defining the schemas for the parameters, objects that describe the inputs for an API. However, most API specifications are not secure 100% since they are not describing the JSON schema to the full extent possible leaving security holes that can be exploited.

Pet Store API - Example 1

Consider the following parameter called username - taken from Pet Store example):

{
  "name": "username",
  "description": "The name that needs to be fetched. Use user1 for testing. ",
  "schema": {
    "type": "string"
  },
  "in": "path",
  "required": true
}

You have to limit what is accepted as an input, otherwise it could open your backend server to various attacks, like SQL injections or buffer overflows. Try adding a pattern and maxLength to the schema.

Pet Store API - Example 2

Consider the following section in OpenAPI specification - PetStore:

{
  "securitySchemes": {
    "type": "apiKey",
    "name": "api_key",
    "in": "header"
  }
}

We can see that the API is using the api_key header and not the standard Authorization header. This can lead to potential data exposure since the API provides access to dynamic data that are scoped to each API key.

Any caching implementation should have the ability to scope to an API key to prevent cross-pollution. Even if you don’t cache anything in your infrastructure, you could expose your customers to security holes. If a customer with a proxy server was using multiple API keys, such as one for development and one for production, they could see cross-pollinated data.

Here, the recommendation is to ensure Cache-Control headers are properly configured and if possible try to use the common Authorization header since every server knows not to cache based on that header.

app.use((req, res, next) => {  
res.setHeader('Cache-Control', 'no-store, no-cache, must-revalidate');  
res.setHeader('Pragma', 'no-cache');  
// ...
});

RestCase API Insights

Here the example is causing sensitive data exposure which is #3 in the OWASP Top 10 list.

RestCase helps to identify API security flaws during the design phase through automated API schema analysis (register for free here and check-it out for yourself).

Design-first approach security focusing

I already wrote about the importance of API-first or design-first approaches here, but we also must remember that the API security should start with API design. If you wait until you’ve already created your API to think about security, you’re fighting an uphill battle, because you’ll be trying to plug security holes that you could have prevented in the first place.

This was also one of the topics I wrote about that is the future of API security.

Most of the API public documentation is based on API specifications and once are exposed to a client, it is also a potential risk of exposing your API security holes.

Keep in mind, of course, that designing an API that is totally flawless from a security perspective is impossible. You should never assume that your API is so well designed that it has no vulnerabilities. But you can, and should, take steps starting early in the design process to mitigate the risk of security problems within your API.

Summary

Secure API design is the first step toward API security.

API security includes API access control and privacy, as well as the detection and remediation of attacks on APIs through API reverse engineering and the exploitation of API vulnerabilities as described in OWASP API Security Top 10.

Defining the API specification as detailed and secure as possible will increase the confidence of your clients twards your API and will make it much more secure while allowing your developers to learn about the vulnerabilities to watch for before and while implementing the API.