Inon Shkedy
OWASP API Top 10 for Dummies: Part III
Welcome back to our blog series on the OWASP API Top 10!
This is continued from Part I and Part II. If you haven’t read the first two parts in this blog series, check them out! These blogs are written for a non-technical audience, and are meant to give fun analogies to explain, what are often, some challenging technical concepts.
Part I of this blog series addressed Broken Object Level Authorization (BOLA), Broken User Authentication, and Excessive Data Exposure. Part II tackled Lack of Rate Limiting, Broken Function Level Authorization (BFLA), and Mass Assignment. And now in Part III, we talk about Security Misconfiguration, Injection, Improper Asset Management, and Insufficient Logging and Monitoring.
Let’s get started.
API #7 – Security Misconfiguration
Security Misconfiguration is like bad habits – we all have them.
For those of us who aspire to live a safer lifestyle, and avoid potential risks, there are some pretty straightforward guidelines we should follow.
- Get vaccinated against recent viruses
- Never leave the door key under the doormat, nor store your Credit Card pin in your wallet.
- Follow the FDA recommendations when it comes to nutrition and medication.
Similarly, our APIs require similar attention:
- APIs must be updated regularly – “vaccinated” against known threats, such as Log4Shell.
- Secrets, such as passwords and keys, should be encrypted and stored in safe places
- Follow OWASP recommendations on how to configure your encryption and application server (HTTP headers, TLS version, etc)
As you can see, security misconfiguration is a pretty broad category that guides us on how to give our APIs a “healthier lifestyle”.
API #8 – Injection
We have all heard about Injections, such as SQLi and Shell Injections – and it isn’t an intuitive concept to comprehend. Honestly, I’ve been trying to think about a simple and easy-to-digest analogy to describe this concept. I couldn’t, so I approached Google Instead and found the following answer on StackExchange: https://security.stackexchange.com/a/25710
It’s a pretty brilliant example.
For many years, Injection used to be the most critical and prevalent AppSec vulnerability.
During the creation process of the OWASP API List, we decided to move it to number #8, and we got criticized for doing it.
The reality is that it’s harder to find injections in APIs of modern applications, because of different trends in application development, which makes it much harder for software engineers to write vulnerable code.
To learn more about those trends you can check my blog post.
API #9 – Improper Assets Management
I’ve been watching the show “Narcos” to learn some Spanish, and I got inspired by one example of Improper Assets Management.
Throughout the show, we can see how Pablo Escobar is struggling to store his $30 Billion wealth – since banks wouldn’t accept the money, he has to conceal it in different places, such as walls of buildings, underground, etc.
To manage this operation, he has multiple accountants who are responsible for documenting the hiding places.
Some of the problems Pablo faces
- Accountants are being assassinated and Pablo loses track of the money
- Cash is concealed in the wrong places and gets eaten by rats
- Unreadable handwriting of coordinates of the hiding places
Storing your most important assets in distributed places with wacky documentation sounds absurd, verdad? Guess what? The same thing happens with your APIs!
Modern companies have dozens of APIs and thousands of API Endpoints of different types (Mobile, web, B2B, internal, etc..) – and it’s very difficult to keep on track with them:
- Developers are usually (and fortunately) not being assassinated, but they tend to switch companies pretty frequently, leaving black holes after them, without anybody knowing what is the purpose of“Backend-2nd-john–temp-do-not-delete”?
- Developers need to deliver fast, especially in startups, leading them to neglect documentation and document only some parts of the API.
Improper Assets Management is a problem that exists in almost every company, where the APIs are not documented properly. It can lead to many problems – because you can’t protect what you don’t know.
API #10 – Insufficient Logging and Monitoring
You can think about your API as the Met museum in NYC. They both have sensitive assets (such as rare paintings or sensitive customers’ information), but at the same time accommodate visitors from all over the world.
If you were the director of security at the Met, you would probably want to purchase the best safes and hire the sharpest security guards. But this isn’t enough, right? Even if you have decent preventative security measures, you still need tools that would help you to manage crises when things go south – cameras and policies to document which employees worked at which times.
In the world of APIs, this concept is called “Logging in Monitoring” – those are security measures within and outside the code, and are used by your security team as tools to continuously make sure everything is safe, or investigate in case of a crisis.
When a company suffers from Insufficient Logging & Monitoring, in case of a breach, they wouldn’t know what data was accessed by the attacker, and even worse, wouldn’t even know about the breach.
About Traceable
Traceable is the industry’s leading API security platform that identifies APIs, evaluates API risk posture, stops API attacks, and provides deep analytics for threat hunting and forensic research. With visual depictions of API paths at the core of its technology, its platform applies the power of distributed tracing and machine learning models for API security across the entire software development lifecycle. Book a demo today.
