This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit

OWASP Common Numbering Project

Revision as of 19:02, 13 January 2010 by Michael Boman (talk | contribs) (Changed to a 3 column table)

Jump to: navigation, search


Here is the generally agreed-upon new numbering scheme. Additional explanatory text coming soon. Questions/Comments? Email Mike.

          1         2         3
  • 0-4 OWASP
  • 6-7 Detailed requirement identifier (major)
  • 8-9 Detailed requirement identifier (minor)
  • 11-12 Document code (DG=Development Guide, TG=Testing Guide, CG=Code Review Guide, AR, ED, RM, OR, others reserved)
  • 14-40 (Optional: DEPRECATED, or # for iterations, or legacy identifiers)

Mapping to Legacy Testing Guide IDs

Ref. Number
Test Name
New Common Ref.
Information Gathering
OWASP-IG-001 Spiders, Robots and Crawlers
OWASP-IG-002 Search Engine Discovery/Reconnaissance
OWASP-IG-003 Identify application entry points
OWASP-IG-004 Testing for Web Application Fingerprint
OWASP-IG-005 Application Discovery
OWASP-IG-006 Analysis of Error Codes
Configuration Management Testing
OWASP-CM-001 SSL/TLS Testing (SSL Version, Algorithms, Key length, Digital Cert. Validity)
OWASP-CM-002 DB Listener Testing
OWASP-CM-003 Infrastructure Configuration Management Testing
OWASP-CM-004 Application Configuration Management Testing
OWASP-CM-005 Testing for File Extensions Handling
OWASP-CM-006 Old, backup and unreferenced files
OWASP-CM-007 Infrastructure and Application Admin Interfaces
OWASP-CM-008 Testing for HTTP Methods and XST
Authentication Testing
OWASP-AT-001 Credentials transport over an encrypted channel
OWASP-AT-002 Testing for user enumeration
OWASP-AT-003 Testing for Guessable (Dictionary) User Account
OWASP-AT-004 Brute Force Testing
OWASP-AT-005 Testing for bypassing authentication schema
OWASP-AT-006 Testing for vulnerable remember password and pwd reset
OWASP-AT-007 Testing for Logout and Browser Cache Management
OWASP-AT-008 Testing for CAPTCHA
OWASP-AT-009 Testing Multiple Factors Authentication
OWASP-AT-010 Testing for Race Conditions
Session Management
OWASP-SM-001 Testing for Session Management Schema
OWASP-SM-002 Testing for Cookies attributes
OWASP-SM-003 Testing for Session Fixation
OWASP-SM-004 Testing for Exposed Session Variables
OWASP-SM-005 Testing for CSRF
Authorization Testing
OWASP-AZ-001 Testing for Path Traversal
OWASP-AZ-002 Testing for bypassing authorization schema
OWASP-AZ-003 Testing for Privilege Escalation
Business logic testing
OWASP-BL-001 Testing for business logic
Data Validation Testing
OWASP-DV-001 Testing for Reflected Cross Site Scripting
OWASP-DV-002 Testing for Stored Cross Site Scripting
OWASP-DV-003 Testing for DOM based Cross Site Scripting
OWASP-DV-004 Testing for Cross Site Flashing
OWASP-DV-005 SQL Injection
OWASP-DV-006 LDAP Injection
OWASP-DV-007 ORM Injection
OWASP-DV-008 XML Injection
OWASP-DV-009 SSI Injection
OWASP-DV-010 XPath Injection
OWASP-DV-011 IMAP/SMTP Injection
OWASP-DV-012 Code Injection
OWASP-DV-013 OS Commanding
OWASP-DV-014 Buffer overflow
OWASP-DV-015 Incubated vulnerability Testing
OWASP-DV-016 Testing for HTTP Splitting/Smuggling
Denial of Service Testing
OWASP-DS-001 Testing for SQL Wildcard Attacks
OWASP-DS-002 Locking Customer Accounts
OWASP-DS-003 Testing for DoS Buffer Overflows
OWASP-DS-004 User Specified Object Allocation
OWASP-DS-005 User Input as a Loop Counter
OWASP-DS-006 Writing User Provided Data to Disk
OWASP-DS-007 Failure to Release Resources
OWASP-DS-008 Storing too Much Data in Session
Web Services Testing
OWASP-WS-001 WS Information Gathering
OWASP-WS-002 Testing WSDL
OWASP-WS-003 XML Structural Testing
OWASP-WS-004 XML content-level Testing
OWASP-WS-005 HTTP GET parameters/REST Testing
OWASP-WS-006 Naughty SOAP attachments
OWASP-WS-007 Replay Testing
AJAX Testing
OWASP-AJ-001 AJAX Vulnerabilities
OWASP-AJ-002 AJAX Testing


  • adding the (release) year into the numbering scheme can be problematic, because the document has a life cycle that goes over years ....
  • One should rather try to accommodate a versioning scheme that is human readable in the reference number as well (e.g. V02, or RevA, or...)

  • don't try to encode any information into the ID that is likely to change or be subject to debate. In the olden days of CVE, we used to have "CAN-1999-0067" which would change into "CVE-1999-0067" once the item was considered stable and sufficiently verified. That made the ID hard to use. Right now, OWASP-DV-001 encodes the term "data validation" in the DV acronym, but what happens if in a couple of years, some new and better term occurs, or the focus changes from validation to something else? (As an example, it's only recently that the "data validation" term itself has become popular.)
  • carefully consider the range of values that your ID space supports, and if possible, allow it to expand. CVE has a "CVE-10K" problem because we never expected that we would ever come close to tracking 10,000 vulnerabilities a year. Red Hat had to change their advisory numbering scheme a couple years ago. etc.
  • don't change the fundamental meaning of the ID once you've assigned it. This causes confusion, and more importantly, it immediately invalidates almost everyone's mappings to that ID - including people who you don't even know are using that ID.
  • closely monitor the mappings that get made. Typos and misunderstandings are rarely caught. People may make assumptions about what "the item" really is, based only on a quick scan of a short name or title. Since you're dealing with diverse sources, there are likely to be many-to-many relationships in dealing with mappings.
  • determine some kind of procedure for handling duplicates. They're gonna happen.
  • the more you distribute the process of creating and assigning IDs between multiple people, the more inconsistencies and duplicates you will wind up with. This may be unavoidable, since the job is usually bigger than one person.
  • determine some kind of procedure for deprecating IDs, i.e., "retiring" them and discouraging their use by others. This will probably happen for reasons other than duplicates. There should be some final record, somewhere, of what happened to the deprecated item - i.e., it shouldn't just disappear off the face of the earth.

Much of the discussion surrounding the establishment of "Common OWASP Numbering" can be found on the various OWASP mailing lists. (For your convenience here is a direct link to the OWASP Testing Guide Mailing List Archive.)