This post is part of a series.
- Part 1: What’s Wrong with the Current OWASP Microservice Security Cheat Sheet? (this post)
- Part 2: Updating OWASP’s Microservice Security Cheat Sheet: Core Concepts
At this year’s OWASP AppSec EU conference, I delivered a talk that critically examined the OWASP Microservice Security Cheat Sheet — a well-known resource that, despite its influence, overlooks several important aspects of modern system design. Rather than stopping at criticism, I highlighted specific gaps, such as the widespread use of “accept by default” patterns, and pointed to real-world consequences, like the Volkswagen breach, where inadequate access controls exposed sensitive customer data. My aim was not just to challenge the status quo, but to contribute to a more complete and realistic perspective on secure architectures.
So, What’s Wrong With It?
For those who didn’t attend the conference or chose a different talk during that slot, here’s a quick summary of my critique.
The current cheat sheet is well-intentioned and already valuable in many ways. One of its strengths is that it does not reduce authentication and authorization to a simple checklist, which is a good thing. Instead, it tries to describe different patterns and trade-offs to help readers make informed decisions. But this is also where it falls short. The descriptions are often too shallow to offer real guidance. Without enough context or practical advice, readers are left with high-level statements that make confident decision-making difficult.
There are also contradictions within the cheat sheet itself. For example, when discussing “Centralized Access Control with embedded PDP”, it warns:
“It should be mentioned that caching authorization decisions may lead to applying outdated authorization rules and access control violations.”
Yet in the section on “Centralized Access Control with external PDP”, it states:
“This pattern can cause latency issues due to additional network calls to the remote PDP endpoint, but it can be mitigated by caching authorization policy decisions at the microservice level.”
This kind of inconsistency creates confusion.
Another recurring issue is the presence of implicit bias in examples, which can be misleading. Take the description of the “Decentralized Service-Level Access Control” pattern. It says:
“Existing programming language frameworks allow development teams to implement authorization at the microservice layer. For example, Spring Security allows developers to enable scopes checking (e.g., using scopes extracted from incoming JWT) in the resource server and use it to enforce authorization.”
Without stating whether the context is first-party or third-party, this advice is misleading. Scopes are meant for third-party scenarios. Using them in a first-party context often results in brittle and unclear access control. Similarly, while JWTs have their place, using them everywhere is more likely to cause problems than solve them.
These kinds of misunderstandings and misapplications of patterns often lead to “accept-by-default” behavior. This is exactly the kind of posture that contributes to “Broken Access Control”, which is currently number one in the OWASP Top 10.
The cheat sheet also shows its age in several areas. For example, in its discussion of edge-level authorization, it labels the approach as “useful but fundamentally limited” and advises always combining it with other methods. While recommending a layered approach to authorization is generally sound, the blanket characterization of edge-level authorization as inherently limited is misleading. Its effectiveness and suitability depend not only on the capabilities of the solution used but also on the specific authorization requirements of the service. Generalizing its limitations without nuance does a disservice to more advanced implementations and diverse use cases.
Finally, the cheat sheet lacks practical examples for most of the more complex patterns. Where examples do exist, they often refer to internal implementations at companies like Netflix. That’s fine in principle, but not particularly helpful for teams who understandably think, “We’re not Netflix”. Without actionable, real-world advice, teams often fall back on the simplest options, which completes the circle: weak or vague recommendations obscure the risks, leading to insecure defaults and insufficient access control, even when teams believe they’re following best practices.
And that brings us to a broader, more subtle issue I encounter regularly in my work. It is not just about the cheat sheet itself, but also about how such documents are used. As a security professional working with many different teams and organizations, I often try to help people make better decisions based on real-world risk and context. But the moment I question a practice that is claimed to be based on OWASP or similar guidance, I usually face immediate pushback:
Developers say: “Our security team requires this”.
Security teams say: “We follow OWASP. It is the gold standard”.
Because of this, practices that may be risky or outdated gain immunity from scrutiny simply because they are rooted in a respected source. This dynamic makes it extremely difficult to challenge entrenched guidance, even when there are good reasons to do so — and that is one reason why the problems I have described continue to surface again and again. As already said, this phenomenon isn’t unique to OWASP. Similar issues have played out in other well-known security guidance, like the widely adopted but later criticized NIST password policies originally shaped by Bill Burr, whose own reflections highlight how even well-meaning recommendations can unintentionally cause widespread security problems.
How My Talk Fits In
If you followed the link to the talk above, you might now be wondering how it relates to what I’m writing here. Despite the title and description, which admittedly include a bit of positioning :), the talk explored many of the same challenges discussed above and, as also mentioned, highlighted what’s currently missing in order to build better guidance.
It also addressed the practical side of tackling these issues, including the kinds of mechanisms needed for identity propagation, policy enforcement, and authorization. That includes approaches like those implemented in heimdall, the open source project I maintain, which is designed to support some of these advanced patterns in practice.
In that sense, the talk wasn’t a product showcase, but rather a way of setting the stage for revisiting and revising outdated or misleading patterns in the cheat sheet. Think of it as the opening argument in a longer conversation.
What’s Next?
Having outlined the challenges and how my talk ties into this work, it’s time to look ahead. How can we address these gaps? Rather than stopping at critique, my talk and this post together mark the beginning of a broader series that offers concrete alternatives and improvements. The next entry will introduce the first installment of a revised OWASP Microservice Security Cheat Sheet and lay out foundational concepts essential for understanding the wider topic. Future posts will explore authentication, identity propagation, authorization, and other key areas, all with the goal of building a practical framework for making better decisions.
Where possible, the updated content is intended as a direct contribution to the official cheat sheet. Background information and explanatory notes will be clearly marked to separate them from prescriptive guidance.
Beyond sharing ideas, this is also a call for input from the wider security and development communities. Before submitting a pull request to update the cheat sheet, I want to gather feedback, critiques, and suggestions to help ensure the final result truly reflects the needs of those relying on it in their day-to-day work. In other words, I’d love to hear your input — once I announce the blog post on my LinkedIn profile, please feel free to share your perspective by commenting on that post, or by sending me a direct message there. Alternatively, you’re welcome to join the discussion in heimdall’s Discord server, where I’ll also share each blog post in the #off-topic channel.
With that context in mind, let’s jump into the first part of the proposed updated cheat sheet.