The document provides an introduction and overview of the OWASP Testing Guide 3.0. It discusses who should use the guide, including software developers, testers, and security specialists. It describes the different OWASP guides that work together, including the Testing Guide, Developer's Guide, Code Review Guide, and Application Security Desk Reference. It emphasizes that security testing is important but not sufficient on its own, and that prioritization and choosing the right techniques is important to provide effective security coverage. Automated tools have limitations and manual techniques may be more effective for finding serious flaws. Developers are encouraged to get familiar with the guidance to help build more secure software.

1. OWASP TESTING GUIDE 3.0 Release
FOREWORD
The problem of insecure software is perhaps the most important technical challenge of our time.
Security is now the key limiting factor on what we are able to create with information technology. At
The Open Web Application Security Project (OWASP), we're trying to make the world a place where
insecure software is the anomaly, not the norm, and the OWASP Testing Guide is an important piece
of the puzzle.
It goes without saying that you can't build a secure application without performing security testing on it.
Yet many software development organizations do not include security testing as part of their standard
software development process. Still, security testing, by itself, isn't a particularly good measure of how
secure an application is, because there are an infinite number of ways that an attacker might be able
to make an application break, and it simply isn't possible to test them all. However, security testing has
the unique power to absolutely convince naysayers that there is a problem. So security testing has
proven itself as a key ingredient in any organization that needs to trust the software it produces or
uses.
WHO?
Software developers – you need to use this guide to make sure the code you deliver is not
vulnerable to attack. You cannot rely on downstream testers or security groups to do this for you.
Those groups will never understand your software as well as you do, and therefore will never be able
to test your software as effectively as you can. The responsibility for the security of your code is
emphatically yours!
Software testers – you should use this guide to enhance your testing abilities. While security testing
has been a dark art for a long time, OWASP is working hard to making this knowledge free and open
for everyone. Many of the tests described in this guide are not that complicated, and don’t require
special skills or tools. You can help your company and enhance your career by learning about security.
Security specialists – you have a special responsibility to ensure that applications do not go live with
vulnerabilities. You can use this guide to help ensure the coverage and rigor of your security testing.
Don’t fall victim to the trap of simply looking for a few holes. Your job is to verify the security of the
entire application. We strongly recommend using the OWASP Application Security Verification
Standard (ASVS) as a guide as well.
THE OWASP GUIDES
OWASP has produced several Guides that work together to capture the application security
knowledgebase:

2. OWASP Application Security Desk Reference – The ASDR contains basic definitions and
descriptions of all the important principles, threat agents, attacks, vulnerabilities, countermeasures,
technical impacts, and business impacts in application security. This is the foundational reference work
for all the other Guides, and is referred to frequently by these other volumes.
OWASP Developer’s Guide – The Developer’s Guide covers all the security controls that software
developers should put in place. These are the ‘positive’ protections that developers must build into
their applications. While there are hundreds of types of software vulnerabilities, they can all be
prevented with a handful of strong security controls.
OWASP Testing Guide – The Testing Guide you are reading covers the procedures and tools for
testing the security of applications. The best use of this guide is as part of a comprehensive
application security verification.
OWASP Code Review Guide – The Code Review Guide is best used alongside the Testing Guide.
Verifying applications with code review is often far more cost-effective than testing, and you can
choose the most effective approach for the application you are working on.
Taken together, OWASP's guides are a great start towards building and maintaining secure
applications. I highly recommend using these guides as part of your application security initiatives.
WHY OWASP?
Creating a guide like this is a massive undertaking, representing the expertise of hundreds of people
around the world. There are many different ways to test for security flaws and this guide captures the
consensus of the leading experts on how to perform this testing quickly, accurately, and efficiently.
It's impossible to underestimate the importance of having this guide available in a completely free and
open way. Security should not be a black art that only a few can practice. Much of the available
security guidance is only detailed enough to get people worried about a problem, without providing
enough information to find, diagnose, and solve security problems. The project to build this guide
keeps this expertise in the hands of the people who need it.
This guide must make its way into the hands of developers and software testers. There are not nearly
enough application security experts in the world to make any significant dent in the overall
problem.The initial responsibility for application security must fall on the shoulders of the developers. It
shouldn't be a surprise that developers aren't producing secure code if they're not testing for it.
Keeping this information up to date is a critical aspect of this guide project. By adopting the wiki
approach, the OWASP community can evolve and expand the information in this guide to keep pace
with the fast moving application security threat landscape.

3. PRIORITIZING
This guide is best viewed as a set of techniques that you can use to find different types of security
holes. But not all the techniques are equally important. Try to avoid using the guide as a checklist.
Probably the most important aspect of application security testing to keep in mind is that you will have
limited time and you need to provide as much coverage as possible. I strongly recommend that you do
not just flip open this book and start testing. Ideally, you would do some threat modeling to determine
what the most important security concerns to your enterprise. You should end up with a prioritized list
of security requirements to verify.
The next step is to decide how to verify these requirements. There are a number of different options.
You can use manual security testing or manual code review. You can also use automated vulnerability
scanning or automated code scanning (static analysis). You might even use security architecture
review or discussions with developers and architects to verify these requirements. The important thing
is to decide which of these techniques will be the most accurate and efficient for your particular
application.
THE ROLE OF AUTOMATED TOOLS
The automated approaches are seductive. It seems like they will provide reasonable coverage in a
relatively short time period. Unfortunately, these assumptions are far less true for application security
than they are for network security.
First, the coverage isn’t very good because these tools are generic - meaning that they are not
designed for your custom code. That means that while they can find some generic problems, they do
not have enough knowledge of your application to allow them to detect most flaws. Also, in my
experience, the most serious security issues are the ones that are not generic, but deeply intertwined
in your business logic and custom application design.
Second, the automated tools aren’t even necessarily faster than manual methods. Actually running the
tools doesn't take much time, but the time before and after can be significant. To setup, you have to
teach the tools about all the ins and outs of the application – possibly thousands of fields. Then
afterwards, it can take a significant amount of time to diagnose each of the sometimes thousands of
reported issues, which are frequently non-issues.
If the goal is to find and eliminate the most serious flaws as quickly as possible, choose the most
effective technique for different types of vulnerabilities. Automated tools can be quite effective on
certain issues. Used wisely, they can support your overall processes to produce more secure code.

4. CALL TO ACTION
If you're building software, I strongly encourage you to get familiar with the security testing guidance in
this document. If you find errors, please add a note to the discussion page or make the change
yourself. You'll be helping thousands of others who use this guide.
Please consider joining us as an individual or corporate member so that we can continue to produce
materials like this testing guide and all the other great projects at OWASP. Thank you to all the past
and future contributors to this guide, your work will help to make applications worldwide more secure.
Jeff Williams
OWASP Chair
January 18, 2009