Heeding the security advice of leading community groups – like the Open Web Application Security Project (OWASP) – is a best practice for developers. But so is original, creative thinking about security issues. While the tips from organizations like OWASP provide an excellent foundation for building secure apps, they don’t necessarily cover every risk developers may face in a given context or prioritize risks in the right order.
To illustrate the point, here’s a look at the OWASP’s top 10 list of API risks, along with an analysis of what it does well and what it’s arguably missing.
What Is OWASP?
OWASP is a nonprofit organization dedicated to improving software security. Founded in 2001, the group originally focused on security for simple Web applications, but it has more recently expanded its focus to address the security of API-first development and cloud-native architectures.
OWASP is not a regulatory body or an industry group. It doesn’t set standards with which developers have to comply in order to avoid compliance issues.
Nonetheless, OWASP enjoys an established reputation in the software development and security communities as a leading resource for best-practice guidance on building secure applications. It’s no single source of truth for securing software, but its recommendations are one essential reference point for modern developers.
The OWASP API Top 10 List
OWASP periodically publishes lists of security risks for both Web applications and APIs (obviously, there is overlap between these categories because many Web applications use APIs, but OWASP assesses the risks separately, which makes sense because not all Web applications use APIs, and not all APIs are used in Web applications).
Here’s a summary of the latest version of the API risk list:
- Lack of object-level authorization checks.
- Flawed user authentication.
- Exposure of more data than necessary.
- Lack of resource quotas or limits.
- Flawed function authorization.
- Lack of filtering for client data.
- Reliance on default security configurations or configurations that are flawed.
- Injection attacks.
- Insufficient tracking of exposed resources.
- Insufficient monitoring.
Improving the OWASP Top 10
Again, the OWASP top 10 list is a vital starting-point for establishing best practices that developers should follow when working with APIs. But for my money, it has some weaknesses.
Third-Party APIs
One of the most surprising things to me about the OWASP top 10 list of API risks is that it draws no distinction between in-house APIs and third-party APIs.
Although both types of APIs may work in the same way in a technical sense, third-party APIs pose additional risks in the sense that developers’ ability to monitor them is limited. So, in many cases, is their ability to manage authentication and authorization. If developers don’t build the APIs themselves, they can only interact with the APIs in whichever way the APIs support.
In this sense, I think the list ought to include a tip about being extra careful when using third-party APIs. Developers certainly need not avoid third-party APIs, but they should understand their origins and limits.
Redundancy
Like many “top 10” lists, OWASP’s API risk list is a bit redundant. That makes it harder to work with and arguably gives developers a false impression of which items to prioritize.
For instance, items 2 and 5, both of which involve authentication or authorization, could probably be consolidated into a single point about ensuring that APIs properly authenticate and authorize all resources.
I suppose you could claim that improper user authentication is a greater risk than broken function-level authorization. But you could also argue the opposite. Either way, I’m not sure the difference here is significant enough to merit two separate items. The main takeaway is that reliable, granular authentication and authorization is essential for every API interaction, and I don’t think the list states that as clearly as it could.
Insufficient Emphasis on Monitoring
Only the last two items on OWASP’s list deal with monitoring API resources and behavior. I tend to think that comprehensive monitoring and logging should be near the very top of the list, because you can’t manage API security risks very effectively if you lack visibility into them.
Granted, logging and monitoring tend to be jobs for IT engineers more than for developers. Perhaps that’s why OWASP gives them relatively little weight on this list, which is geared toward developers. Still, we live in a DevOps-centric world, where the line separating developers from IT teams is blurred. Plus, you can’t track API resources and behavior if the APIs don’t provide proper facilities for logging and monitoring, which is something developers have to implement.
Training and Culture
Talk about “building a security culture” or “training developers in security” often sounds fluffy, especially when it is not accompanied by specific advice on achieving these goals. Nonetheless, I’m surprised that the OWASP list includes nothing in the way of warning about lack of shared visibility or collaboration between developers and security teams.
I think this topic could be added in a way that isn’t so abstract or generic that it’s meaningless. For example, the list could mention the importance of making API monitoring and log data available to both security teams and developers, which is one small step toward building a security culture.
Conclusion
The OWASP top 10 list of API risks is a must-read for any developer who cares about securely designing and using APIs. But at the end of the day, the list represents only one set of perspectives about API security. It’s crucial to think through the guidance for yourself and adapt its recommendations to your own application and environment.
Chris Tozzi has worked as a journalist and Linux systems administrator. He has particular interests in open source, agile infrastructure, and networking. He is Senior Editor of content and a DevOps Analyst at Fixate IO. His latest book, For Fun and Profit: A History of the Free and Open Source Software Revolution, was published in 2017.
Download our Ultimate Guide to SCA here.
