The OWASP Testing Guide v4

Use Dradis to create your own OWASP reports with the help of our compliance packages.

The OWASP testing guide is one of the most commonly used standards for web application penetration testing and testing software throughout the development life cycle. The testing framework was created to help people understand how, where, when, why, and where to test web applications. While other frameworks focus on creating an exhaustive checklist of tasks, OWASP focuses on creating a framework that testers can use when developing their own programs or methodologies.

Learn more about OWASP

The Testing Guide is broken up into distinct phases. Within Dradis, each testing phase is given a section in our methodology template with the individual tasks needed to complete each section. Below is an overview of each phase of testing. For more details, visit the OWASP website.

Information Gathering

During the information gathering phase, the tester gets a high-level view of the server, the application, and gathers information for the next phases of the test. The tests in the information gathering phase should allow the tester to collect basic data like the web server version and type of a running web server, figure out what web applications are hosted on a web server and the frameworks used for those applications, understand typical requests/responses and map the application, and check search engines, robots.txt files, folder paths, commments, metadata, and more for information leakage.

Configuration and Deployment Management

This phase builds on the information gathered previously to start digging deeper. The tester has already mapped out the application, now they dig into how the infrastructure identified impacts the application security (e.g. testing for known vulnerabilities).

Next, the focus switches back to the server, looking at and testing aspects like the platform configuration and architecture, then testing how the server handles different file extensions, and finally checking "forgotten" files for important data. The tester also looks for administrator interfaces in the server or the web application that can be exploited.

Finally, the tester puts their focus back on the web application itself by testing to see what HTTP methods are supported by the web server, testing whether HSTS header is present, and testing for cross-site or cross-domain policies that they can exploit.

Identity Management Testing

This section deals with account, priviliges, and access. The tester spends most of their during this phase on the login page working to understand how the application allows users to sign up and whether this system can be exploited if you know part of the login information (like the username).

During the configuration and deployment management testing, the tester looked for administrator interfaces. During Identity management testing, all possible application roles (user, administrator, author, etc) are to understand what access or priviliges come with different roles.

Next, the tester checks the requirements and the process to create an account and how accounts are deleted. Finally, the tester digs into the system to prepare for future tests by checking whether error messages give clues about existing usernames and trying to find username patterns to help them find those existing usernames and accounts.

Authentication Testing

Identigy Management testing is all about understanding the user accounts, usernames, and roles. However, during Authentication Testing, the tester is almost completely focused on passwords.

The tester spends time looking at default and simple username/password combinations. How many systems can you log in using the username/password combination of administrator/password123 or a similarly simple combination? You'd be surprised. Because of this, the tester also checks password strength rules during this phase of testing because without rules to force complexity, the average user will default to passwords like "password" and "qwerty".

Test lockout mechanisms. Strong security measures should include a lockout measure so that multiple incorrect login attempts kick the user out and prevent them from trying to log in again for a period of time. This measure prevents a brute-force attack where an attacker bombards the application with password guesses until they guess the correct password and gain access.

Most applications have security questions to help verify your identity in case you need to reset your password or if you log in from a new system. These questions can be an important security measure but if the answers are easily guessable (e.g. "what's your favorite color?"), they aren't going to be particularly effective. The tester looks at the strength of the existing questions to see whether they can be exploited to give an attacker access.

The tester also looks at more technical aspects like whether a user's login data is transmitted via an encrypted channed or in a non-secure clear text form. Or, whether it is possible to bypass the login process altogether. They check whether the browser cache and history store any sensitive data. If they do, this data is easily accessible through something as simple as the "Back" button. They also examine how passwords are stored to make sure they aren't in clear text form that is vulnerable to attackers. And, the tester examines the password reset process to see whether any aspects of the process are insecure.

Finally, the tester repeats this whole process for any alternative login channels. In some cases, users may be able to log in through the main website, a mobile-optimized version, a mobile application, or a host of other similar alternative channels. All of the different channels need to be tested for security vulnerabilities.

Authorization Testing

These tests focus on how web applications authenticate access to file systems.

The tester looks for common vulnerabilities like path traversal or file include flaws. The tester also tries to bypass authorization schemes and verifies how every function of the application is affected by user role, authentication status, and other authorization factors.

Testing for vertical privilege escalation (e.g. gaining Administrator access as an Author) or horizontal privilege escalation (e.g. gaining access to another Author's account).

Session Management Testing

After spending a good amount of time on the login process, the tester checks the logout process in more depth during this phase of testing. Applications allow users to stay logged in for a certain amount of time but if the cookies or session tokens aren't secure, an attacker could hijack legitimate sessions. The tester also checks that session time-out is in place so that a user is automatically logged out after a certain period of time without activity. And, the tester checks the entire logout process to make sure that sessions are effectively terminated.

The tester also checks for common problems related to user sessions. The first is session variable overloading. If the application uses the same session variable for multiple purposes, an attacker could exploit this and gain access to unintended (more priviliged) locations. The tester also looks for potential sross-site reuqest forgery (CSRF) which can force a logged-in user to execute actions within the application. Often, links are sent via email or social media and if clicked, the user has no control over the actions performed (like changing their email address or even transferring money).The tester also looks to see whether session tokens like cookies or session IDs are exposed. If they are, an attacker may be able to impersonate a user to access the application. Then, the tester checks the specific attributes of the cookies to ensure they are adequately protected.

Input Validation Testing

In this phase, the tester goes through a total of 15 different input validation tests looking at everything from Cross-site scripting (XSS) to SQL injection. Why? Input validation is the most common web application security weakness. If all of the data coming from the client or from the environment isn't being validated before it's used, the application is vulnerable a host of different issues.

In the words of Michael Howard, "All input is evil."

Testing for Error Handling

The way that errors are handled by the application can reveal useful information to an attacker. The tester checks whether it is possible to access any stack traces or find relevant information within them. They also look at all of the error codes they come across while testing to try to get more information about the technologies used in the application, bugs, or databases.

Testing for Weak Cryptography

The tests in this phase can be summarized with the question: "is sensitive data protected?". The tester checks whether and how sensitive data is being protected during transmission and whether it is possible for an attacker to decrypt the encrypted data.

Business Logic Testing

The tests in this phase require the tester to "think outside the box" and try to break the application security measures by bypassing the normal processes or patterns. These tests cannot be automated like many other tests can be. Instead, the tester has to try to "outsmart" the application design. This set of tests also draws heavily from the information gathered in earlier phases of testing. The better the tester understands the logic and processes of the application, the better chance they will have to identify creative ways to "break" it.

Client Side Testing

The final phase of testing involves executing code within the browser rather than on the server.

The tester looks at a variety of different client-side aspects of the application to check for common vulnerabilities. Many of the vulnerabilities tested in this phase are related to cross-site scripting (XSS) or injection.

The above is a condensed overview of the OWASP Testing Guide v4, visit the OWASP website for more details.

Based on the project template created by talsoft

Community Edition package

Professional Edition package

Methodology template
Project template
Sample project
HTML report template
Word report template
Issue, Evidence, and Note templates
Download now Download now


These instructions are also available in the instructions.txt file in your Compliance Package.

Methodology template

Filename: OWASPv4-methodology.xml

This project methodology creates a step-by-step checklist of all of the tasks requred for an OWASPv4 test. This methodology can also be useful independently (like for teams that want to structure their projects by IP).


Dradis CE
Place the Methodology template in the templates/methodologies/ folder of your local install.
Dradis Pro

See the Using Methodologies page of the Working with Projects guide.

Project template

Filename: OWASPv4-blank-project-template.xml

This project template is ready to be updated with your results. Unlike the full project export, the Issue #[Status]# fields need to be updated before any will export into the report template(s). Placeholder Issues and instances of Evidence are already created for each section of the OWASPv4 testing guide. Simply update each Issue in the project with the findings from your tests, update the corresponding Evidence for the Issues, and then export using one of the report template options.


Dradis CE

In the header, click Upload output from tool and upload the project template file as Dradis::Plugins::Projects::Upload::Template

Dradis Pro

Create a new (blank) project. In the header, click Upload output from tool and upload the project template file as Dradis::Plugins::Projects::Upload::Template.

See the Project templates page of the Working with Projects guide for more details.

Sample project


This is a full project export ready for you to export and test. This project comes pre-populated with 6 Failed status Issues, 6 Passed status Issues, and 7 Unknown status Issues. Each pre-populated Issue also has an instance of Evidence associated with it.


See the Importing and Exporting Projects page of the Working with Projects guide:

After uploading the project using the instructions above, try the following:

  1. Open the project and navigate to All Issues
  2. Open any un-tagged Issue and click Edit
  3. Edit the value of the #[Status]# field, select Fail, Pass, or Unknown.
  4. Give the Issue the corresponding tag (Failed, Passed, or Unknown).
  5. Click Update to save the Issue
  6. Export the report and confirm that the Issue you just edited now appears in the exported report.

HTML Template

Filename: OWASPv4.v0.3.html.erb

This HTML template will generate a report with the following sections:

  • Failed Tests: this section includes a table showing the Title and Control of every test with a Failed status in your project.
  • Detailed Findings: this section shows the full details for every Failed-status Issue in the project. Each individual finding includes the Issue title, control, summary, reference, and instances of Evidence.
  • Appendix: this table shows the Title, Control, and Status for every Issue in the project.


Dradis CE
Place the HTML report template in the templates/reports/html_export/ folder of your local install.
Dradis Pro

See the Report templates page of the Administration manual.

See the Creating HTML Reports guide for more details.

(Pro) Word Report Template

Filename: dradis_template-owaspv4.v0.3.docm

This custom Dradis template has the following sections:

  • Executive Summary: this section contains a pie chart that displays the number of Issues by status (passed, failed, or unknown). The macro to update this chart will run automatically after you open the document. Save the document as a .docx file after the macro runs to preserve the formatting. The Executive Summary section also contains a Conclusions section that contains the output of the Conclusions Note under the Conclusions Node within your Dradis project.
  • Failed Tests: this section will display all of the Issues from your Dradis project that have a #[Status]# field value of Fail. The Issue's title and control will be displayed along with each instance of Evidence associated with that Issue.
  • Appendix: the table will display the title, control, and status of each Issue in your project. The Unknown Tests subsection shows the Issue and Evidence details for each Issue in your project with a Status of Unknown. And, the Passed Tests subsection displays the Issue and Evidence details for every Issue in your project with a Status of Passed.


Dradis Pro

Upload the Word report template to Dradis using the instructions on the Report Templates page of the Administration guide

(Advanced) Edit the report template properties to filer by the Order field to display the findings in the same order they appear in the OWASPv4 testing guide. See the Report Template Properties page of the Administration guide for details.

(Pro) Issue, Evidence, and Note Templates

Filenames: issue-template.txt, evidence-template.txt, note-template.txt

Use the templates to configure the Plugin Manager so that you can quickly and easily integrate external tool data (Nessus, Burp, Qualys, etc) to match the format of this report template. Or, add any of the templates to your instance as Note templates to painlessly pre-populate manually-created findings with the correct field names.


Dradis Pro
Upload the templates to Dradis as Note templates using the instructions on the Note Templates page of the Administration guide.

Streamline InfoSec Project Delivery

Learn practical tips to reduce the overhead that drags down security assessment delivery with this 5-day course. These proven, innovative, and straightforward techniques will optimize all areas of your next engagement including:

  • Scoping
  • Scheduling
  • Project Planning
  • Delivery
  • Intra-team Collaboration
  • Reporting and much more...

Your email is kept private. We don't do the spam thing.