The idea of this article is to serve as an introduction to API security. We’ll look from a high-level view at all the different problems that are stacking up around APIs right now and give you some highlights of recommendations.
It will be no surprise to anyone that API breaches are really on the rise. A recent report stated that only 6% of companies are lucky enough to report there are no API-related problems for them. Most issues are related to the security and validation of data. It’s about rate-limiting problems, authorization, and authentication. As we deep dive into these issues, we observe some common patterns.
Change of architecture
Nowadays, we are building very different applications than when we started working on APIs and integration. We have already completely API-centric API-driven architecture. This has expanded the attack surface. The reason is that we used to do a lot of validation and work on the server-side. There was a lot of control on the server-side. But now, the control has shifted to the client-side. Now, we have APIs that turn raw data. This raw data needs to be exposed through some interface. A lot of the business logic, data filtering, and data grouping is being done on the client-side, which means that if I go straight into the API, none of that logic or control is happening. A lot of problems arise because of this.
API security does not scale
The number of APIs has exploded; this new type of architecture is different and has a significant impact. The more distributed our applications, the more APIs we have and have to manage. And on top of the number of APIs, we also have very agile and very productive development teams that have built many tools and helped write APIs and applications as fast as possible. But we haven’t equipped our security people with the same means to scale security. A lot of the problems we see are because API security is really scaling enough.
APIs are all about data.
APIs are all about data, and it is about protecting data. Protecting data requires context. Traditional security is not working anymore because they don’t understand that context. They don’t understand that data; they have a no different way of working based on how architecture or applications were five or ten years ago. This leads to different vulnerabilities.
There are three main groups in those problems around APIs – problems around data, problems around authentication and authorization, and problems around governance and operations.
Authentication – In many of the issues we have with APIs today, authentication is a big problem. It’s all about defining and enforcing how authentication will work and making sure nobody can break access to your APIs.
We need to know our APIs; we need to understand the risk associated with those APIs to define the correct way of authentication. Authentication will vary for banking and weather apps because risks to consumer data transported through our APIs are very different. One size does not fit all. You first need to decide how authentication will be done based on threat modeling, manipulation of data, consumption of data, sensitivity, etc. Different data, different use cases.
Misconception regarding using API Keys and bearer tokens needs to be looked at. When you use keys of tokens for authentication, you get an API key or get an access token through some way of authentication. Once you have that, that doesn’t prove who I am anymore. The easiest way to think about this is if you think of a token as a hotel key, you go to the reception; you present your passport, present a credit card, and then get the hotel key. You can then go to your door and open it or give it to someone else because you forgot something in your room. Even if it is not the original person who took the key, the key will work.
We have some well-done security profiles in the open banking world and across many applications. They use OpenID connect, as opposed to AUTH for authentication. Multi-factor authentication is a requirement in most banks. We have seen many problems around APIs happening on authentication and password reset endpoints. Those are the keys to the kingdom, and if I can abuse that, they can break that.
Two things are recommended for this. One is to design rate-limiting around those specific endpoints specifically. You have to adapt your rate limiting to a human interacting with the system.
The other thing that you have to be very careful about is the discovery processes. We have to find a sweet equilibrium between helping a genuine user and not giving too much away to a potential hacker. For example, when someone enters an incorrect user-id password combination, we don’t want to give them any hints of what is wrong. If we give a specific error message, e.g., user-id is correct, the password is wrong, the hacker can find it easier to get data, so we give them generic error messages that convey the message but do not give away specifics.
Authorization – The other aspect is an authorization. Similar problems arise for authorization as well. This is about specific users being allowed to use specific areas of an application or specific account accessing a specific resource. In an external decision engine, you need to enforce these rules, which can be pretty complicated because you have to consider who the user is, what they want to access, and what they want to do on that specific resource. As mitigation, do not use iterative IDs, don’t expose internal IDs, and use rate-limiting. Please make sure no one can call an operation that you don’t want them to. The easiest thing to do is make a positive security approach by blocking calls that are not allowed.
To summarize –
- Take a positive security approach – block unknown verbs and operations.
- Design policies and test them
- Do not mix admin and non-admin operations in the same API
- Restrict access to admin APIs
- Do not rely on the client apps to “hide” operations on the UI
Data – Validation of data is essential. It’s all about mastering your data, knowing your data, and ensuring that you do not accept any unexpected inbound or outbound data. You need to know what this data is; you need to know how to enforce that inbound and outbound. You want to control what comes in and what comes out. That’s critical. It’s also making sure you properly design your error responses and don’t give away too much information. This is all about design.
Proactive Security –
Bad design decisions are hard to undo and fix. Start worrying about API security at design time.
Build a threat model – evaluate the risk each time and API changes. Create ten negative tests for each functional test—Hammer your APIs with bad data, tokens, and users. Automate security.
Interface Design – what are we exposing and to who
These are ways to protect yourself against human errors.
