OWASP Development Guide – what do you want in, and what do you want out?

It’s time to do some curating of the OWASP Developer Guide. This is where my tastes meet the community’s – what do you want in the Guide, and what do you want out of the guide?

As much as I want to be comprehensive, there is a real risk that a 800 page book would never be read. There ARE easter eggs in the Guide that no one has found or bothered to e-mail me about yet, so I know it’s not being read widely.

I want to ensure the Guide is used, in a way that the OWASP Top 10 and ESAPI are used daily throughout our industry.

  • What would you like to see IN the Guide? Why?
  • What would you like to see OUT of the Guide? Why?

Let me know by June. I’ll be sure to share your thoughts with the Developer Guide mail list.

Published by vanderaj

Just another security geek

Join the Conversation


  1. There are a lot of empty sections in the guide. I think that it’s better not to have section at all, then to have it empty/in draft or incomplete status. Clicking on those empty sections takes a lot of time. I think that if section is empty but is self-explanatory (OWASP-0602 Verify that all output encoding/escaping controls are implemented on the server side.), then it will be better to put it’s name into higher level list and to cut off list item that doesn’t contain information inside

  2. The empty sections are to be written 🙂 It’s early days as yet. However, my commitment is to high quality. I want the Guide to be THE reference architects, tech leads and developers have nearby

  3. Working on the programming side I would like to see a “summary” document with code examples for each of the techniques that can be handed to programmers. I find the current documentation too high level for the average programmer to interpret. I just want to be able to say, when you are writing code, or doing quality check walk-throughs use the following coding techniques instead of the “bad” examples.
    We can edit the docs to eliminate or de-emphasize techniques that don’t apply to our specific situations.

    The more different languages you can provide the examples in, the better chance we have of finding one that we can “transliterate” into what-ever unique langauge we are using.

  4. I am going to be eliminating bad examples and code, just to make the guide shorter. I intend to use GoF design pattern templates and UML at the abstract, and code examples in the concrete. Do your devs know about the abstract architectural stuff? I do need to get a feel for the average dev, because I really want the Guide to be more widely used.

    I want to use positive patterns in their place, with concrete examples in at least PHP, and hopefully other languages.

    The summary version of the OWASP Developer Guide is / will become the existing Application Security Verification Standard. If you need a checklist, that’s exactly what it is. There’s an update in the works right now, so feel free to help those guys produce exactly what you need, because we are going to be tracking the ASVS document.

Leave a comment

Your email address will not be published. Required fields are marked *