OWASP ASVS 3.0 CheatSheet

The primary aim of the OWASP Application Security Verification Standard (ASVS) is to normalize the range in the coverage and level of rigor available in the market when it comes to performing web application security verification. The ASVS standard provides a basis for verifying application technical security controls, as well as any technical security controls in the environment that are relied on to protect against vulnerabilities such as Cross-Site Scripting (XSS) and SQL injection. This standard can be used to establish a level of confidence in the security of Web applications. It is composed of 16 categories containing 175 check points to validate in your application. Of course not all are applicable but the global method is wide enough to cover most of web applications.

As a member of OWASP and regularly performing Security oriented Code-Review in various languages, the Application Security Verification Standard became the basis on which I rely to deliver security reports to my customers and a proper way to measure the confidence you can put in the application. This article is not about presenting ASVS which I trust you can discover by yourself on the website of OWASP, but it is only to share a worksheet I have been using along with the document written by OWASP.

This spreadsheet takes the shape of a checklist you can browse in order to assess the level of confidence of the application. In this article I will enclose this spreadsheet and explain how I am using it. You can directly download the cheatsheet at the end of the post.

Basically the spreadsheet is really simple but I have never seen it elsewhere. You have one tab sheet for each category of the ASVS. For each category the criteria is documented with its ASVS Level and description in full text. Then your job will be to fill in the rest of the field as follow:

• Valid (Valid/ Non valid / Not Applicable)
• Source Code Reference (If the code is not valid, insert the reference to the files/lines which lack of security)
• Comment (Field to comment the vulnerability and keep track of changes with developers)
• Tool used (If the vulnerability was found using a tool , you can include the name of the tool / version and sometimes the output)

Once you’ve done that, do not forget to tag the irrelevant criteria with Non Applicable,  and the report located in the first tab sheet will be automatically generated as well as the radar graph, you can directly enclose in your analysis document or report.

Ideally this assessment should be done before any major release of your software, especially if you work with Agile methodology. It should be part of your recipe before shipping to validate this worksheet. Along the security analysis you can share this document with developers to keep tracks of change and also keep the graph at each release to see the evolution of security of your application through time.

Here is the repository for CheatSheet for OWASP 3.0.