5 min read

You don't know OWASP

About a year ago I was just getting involved with the CSA Working Group for CCM version 4 when I came across the OWASP CSA Project and went on a little adventure to learn more about OWASP. Many readers probably think they're aware of OWASP, as I once thought I did, but you likely have no idea.

So you've heard about the OWASP Top 10 and maybe some tools like ZAP, Amass, Dependency-Check, or DevSlop made famous by Tanya Janca (@shehackspurple). But how many OWASP Top 10 projects do you know about (hint: there are 10+), and these projects are just a few of hundreds.

If  you've ever visited owasp.org I feel your pain on how hard it is to navigate and find anything.. So I've done that hard work and the following is a Top 10 (that's a joke) list of what I found interesting or useful;

OWASP Top 10 Projects



Standards, Frameworks, Training, and Guidance


Defensive Security (Blue Team)

Offensive Security (Red Team)

Practical use of OWASP

As a developer of 20 years, a consultant, and startup founder - the following examples are some practical uses of OWASP from my own experiences that hopefully help you too.


As a consultant I am often engaged in conversation with customers in high level positions, either as a deliberate part of the delivery which could be an advisory capacity, or just casually by some accident of being in the right place or meeting. There are also the many great people i get to work alongside that often take the opportunity to pick the brain of the consultant - which being human can often be quite the challenging predicament if you don't remain humble or are not completely honest. Essentially, consults need to be informed at the least, and the really trusted consultants tend to also have great sources to freely provide customers their own path to come to the same conclusions you provide as advice.

This preparedness is nothing more than the same kind of learning everyone experiences in school, the only difference is that you must adapt a wider breadth of sources to take from each where they fit the unique customer's situation.

Sources that have become immensely useful are;

  1. Proactive Controls; when I needed to define some preventative measures for a new capability being proposed, these controls are mostly useful on their own merits but are a great tool to get the creative thinking started if you are stuck.
  2. OWASP Benchmark; for the predictable question we are always asked about "hardening". It's fine to be opinionated and have your own bespoke solutions that work, but it helps to lean on standards and highly scrutinised benchmarks like this and the ones from CIS so any friction can be addressed by a community of experiences, not personal opinions of the individual that hold little weight when made alone to a room of people who work together.
  3. List of Open Source Application Security Tools; basically the dream source for any qualitative analysis exercise in appsec. Are the client or team member proposing a proprietary tool without a community and they charge for supporting the simplest of use cases because they don't offer usable documentation? Find a more feature rich and battle tested option here, you'd be sure these are heavily scrutinised in public so any flaws are known up front instead of a 3 month project spike that ends in using one of these  tools anyway.

Project sanity checks

Before handing over a proposal or solution, take a quick look at the top 10s to make sure you're not going to miss something that would embarrass yourself or your employer. In fact, check back in on these top 10s and the standards listed above as the project kicks off and before a showcase just to make sure you're armed with a good roadmap and concise project plan that you understand well and can speak about articulately when those security related questions are asked, they always are right?

Pull Request / Code reviews

Secure code reviews, or just a typical pull request code review, often means you are making suggested changes. The Code Review Guide and following items are some great ways to approach this task;

  1. Secure Headers Project; I can't stress this one enough. In the hundreds of projects i've code reviewed for customers, a memorable few came close to having no HTTP related bugs. The remaining were all easily compromised, by common trivial techniques that are preventable with some simple headers.
  2. Cheat Sheet Series, particularly V3 Session Management from the ASVS Index as this is another one of those defects that is responsible for common trivial vulnerabilities like session-riding that allows attackers to perform actions using legitimate sessions that were previously established and remain trusted indefinitely or for a significantly long time.
    These cheat sheets have real code examples - seriously a superpower when providing constructive criticism to improve code. We all know that suggesting changes is a loaded gun that often fires off into heated debate and often hurt feelings. Using real code samples from these cheat sheets has not only defused these situations more time than i can count, it has also made the developer feel empowered to figure things out for themselves with only the slightest nudge from my efforts. I like to think these interactions have led to some of these developers getting interested in security rather than hating or avoiding it.
  3. Logging and validation seem to always make an appearance in the Tops 10 lists, so make sure you check out the standards and guidance above. So many secrets are exposed through poor logging practices and if validation is used at all it is best to make sure you're not opening your app to vulnerabilities when you think you're doing the right thing by all validating inputs like you were taught.
I could go on

So there you have it, all the good parts of OWASP demystified.

Enjoy, spread the good word.