Web Application Security Testing: The Complete Guide

Web application security testing is the practice of checking a web application for weaknesses an attacker could exploit, using a mix of automated tools and manual testing. It covers the source code, the running application, the third-party components inside it, and the APIs behind it. It is finished when the fixes are verified, not when the scan completes.

It is not one activity. It is a set of methods that each catch different problems, and teams get into trouble when they assume one method covers them. This guide breaks down each approach, gives you a checklist built on the OWASP Web Security Testing Guide, explains what manual testing adds, and shows how to combine the methods into a layered program.

The short version:

• Automated tools (SAST, SCA, DAST, IAST) give breadth and speed. Run them continuously.
• Manual testing finds broken access control, business logic flaws, and chained exploits, the issues behind most serious breaches. Run it at least annually and before major releases.
• A layered program uses both, so a flaw has to slip past several different kinds of scrutiny to reach production.

Types of web application security testing

Six methods cover almost everything teams actually run. The table compares them; the notes below explain each one.

Method	What it finds	Blind spot	When it runs	Who runs it
SAST (static analysis)	Insecure code patterns: injection sinks, hardcoded secrets, unsafe functions	Runtime behavior and business intent; noisy without triage	On every commit or pull request	Developers, through the CI pipeline
SCA (software composition analysis)	Known vulnerable open-source and third-party components	Your own code	Continuously, in the pipeline and on the repository	Developers and platform teams
DAST (dynamic analysis)	Runtime issues on reachable pages: injection, misconfigured headers, exposed files	Code it cannot see, logic it cannot understand, paths it cannot reach	Against staging builds, on a schedule	Security or QA teams
IAST (interactive analysis)	Runtime issues traced back to the line of code, with fewer false positives	Needs instrumentation; still misses design and logic flaws	During functional and QA testing	Security and QA teams
Manual penetration testing	Broken access control, business logic abuse, chained exploits, authentication flaws	Point in time; value scales with tester skill	Annually, before major releases, after big changes	Independent senior testers
API testing	Object-level authorization, mass assignment, broken authentication on endpoints the UI never calls	Only as complete as the API inventory	With each major API version	Independent testers, with specs and accounts per role

SAST (Static Application Security Testing). Analyzes source code without running it, catching insecure patterns early in development. Strong on breadth and coverage of the codebase. Blind spot: no view of runtime behavior, and it generates false positives that need triage. Our SAST vs DAST comparison goes deeper on choosing and tuning both.

SCA (Software Composition Analysis). Scans your third-party dependencies for known vulnerable components, essential given how much of any application is open-source code. Blind spot: it says nothing about your own code.

DAST (Dynamic Application Security Testing). Tests the running application from the outside, like an automated attacker. Finds issues that only appear at runtime. Blind spot: no view of the code, it misses business logic, and it only tests the paths it can reach. We compare it directly with manual work in DAST vs penetration testing.

IAST (Interactive Application Security Testing). Instruments the running application to combine static and dynamic views, which makes it more accurate than either alone. Blind spot: it requires instrumentation and still misses design and logic flaws.

Manual penetration testing. A skilled human attacking the application with intent and creativity. This is where the flaws that cause real breaches surface: business logic abuse, chained exploits, and authorization gaps no scanner conceives of. Blind spot: it is point in time, and its value scales with tester skill. Our web application penetration testing services are built around this layer. When the scope spans web, API and mobile together, application penetration testing scopes them as one engagement.

API testing. Most modern web applications are an API with a user interface on top. Testing only what the browser happens to call leaves the rest of the API untested. A dedicated API penetration test works from the specification, with accounts for every role, and our API penetration testing checklist lists the tests to run.

What automation cannot catch

The most damaging web vulnerabilities require understanding what the application is supposed to do, then abusing that intent. Scanners have no concept of intent, so they consistently miss:

• Broken access control and IDOR: whether one user can reach another user’s data. It is the most common serious finding in manual tests, and a scanner sees a normal response because the server answered with valid data.
• Business logic flaws: abusing legitimate workflows in unintended ways, such as applying a discount twice, skipping a payment step, or approving your own request.
• Chained exploits: combining several low-severity issues into one critical impact, such as an information leak that reveals an identifier, which then unlocks an authorization gap.
• Multi-step and multi-role flaws: anything that needs two accounts, a specific sequence of requests, or a race between them.

This is why manual testing remains irreplaceable, and why we go deeper on it in automated vs manual penetration testing.

Web application security testing checklist (OWASP WSTG)

The OWASP Web Security Testing Guide (WSTG, stable version 4.2) organizes web testing into twelve categories. Use it as the backbone of your checklist. The right-hand column shows where automation helps and where a human has to do the work.

WSTG category	What to test	Automated or manual
4.1 Information gathering	Exposed files, directories, and endpoints; technology fingerprinting; entry points; comments and metadata that leak internals	Mostly automated, human review of results
4.2 Configuration and deployment management	Admin interfaces, HTTP methods, HSTS and other security headers, backup and old files, subdomain takeover, cloud storage	Mostly automated
4.3 Identity management	Role definitions, registration, account provisioning, username enumeration	Manual
4.4 Authentication	Default credentials, credential transport, lockout, authentication bypass, password change and reset, remember-me functions, weak password policy, weaker login in alternative channels	Mixed; reset and bypass flows need a human
4.5 Authorization	Directory traversal, privilege escalation, insecure direct object references, bypassing the authorization schema	Manual, with two accounts per role
4.6 Session management	Cookie attributes, session fixation, CSRF, logout, session timeout, token exposure	Mixed
4.7 Input validation	SQL, command, and template injection; cross-site scripting; SSRF; XXE; HTTP request smuggling	Automated discovery, manual confirmation and exploitation
4.8 Error handling	Stack traces and error messages that reveal internals	Mostly automated
4.9 Weak cryptography	TLS configuration, padding oracles, sensitive data sent unencrypted, weak algorithms	Mostly automated
4.10 Business logic	Workflow circumvention, data validation, request forgery, process timing, usage limits, file upload abuse	Manual only
4.11 Client-side	DOM-based XSS, clickjacking, CORS, WebSockets, browser storage, JavaScript execution	Mixed
4.12 API testing	GraphQL: introspection, authorization on queries and mutations, injection, nested-query abuse	Manual, supported by tools

Two notes on using it. First, the WSTG describes how to test; if you need a list of requirements to test against, pair it with the OWASP ASVS. Second, a checklist is a floor, not a ceiling. The business logic row is short in the table and long in practice, because every application’s logic is different. For the API row, our guide to GraphQL security testing works through introspection, batching and query-level authorization one test at a time.

Manual web application security testing

Manual web application security testing is a person working through the application with the same goals an attacker would have. Tools still do the repetitive work, but a human decides what to try, reads the responses, and chains what they find. A typical manual engagement runs in this order:

1. Map the application. Walk every feature with every role, recording each request through an intercepting proxy. The result is a map of functions, parameters, and the role that should be allowed to use each one.
2. Build the authorization matrix. For each function and object, write down who should have access. Then test it: replay each request as every other role, and as a second user of the same role. Two accounts per role is what makes cross-user and cross-tenant findings provable.
3. Attack authentication and sessions. Password reset, MFA enrollment and bypass, token lifetime, logout, and what happens to sessions when a password changes.
4. Probe input handling. Automated payloads find the obvious cases; the tester works the rest by hand, confirming exploitability and impact rather than reporting a reflected string.
5. Abuse the business logic. Skip steps, repeat steps, reorder steps, change prices and quantities, race two requests against each other, and upload what the application does not expect.
6. Chain and prove. Combine findings into the path an attacker would actually use, and capture the evidence and reproduction steps an engineer needs to fix each one.

A small application runs about a week of testing followed by reporting at Invadel; larger applications with more roles and workflows take longer. Testing runs against staging where one exists, and against production only under written rules of engagement. The output is a report with reproduction steps and a free retest, the structure shown in our penetration testing report template.

Tools for web application security testing

Tools make testing faster, and a good tester uses many of them. None of them replaces judgment.

• Intercepting proxies. Burp Suite and ZAP sit between the browser and the application, so every request can be read, replayed, and modified. Nearly all manual web testing happens here. Our Burp Suite comparison covers what the tool does and what it leaves to the tester.
• DAST scanners. Automated crawlers and scanners, including the scanning engines built into those proxies, that probe a running application for known vulnerability patterns. Acunetix is a common standalone example, now sold as Invicti Web + API according to acunetix.com (as of Sep 2026); our Invadel vs Acunetix comparison shows where a scanner like it stops.
• SAST tools. Static analyzers such as Semgrep, CodeQL, and SonarQube, which run in the pipeline and flag risky code before it merges.
• SCA tools. Dependency scanners such as Dependabot and OWASP Dependency-Check, which flag known vulnerable libraries.

	Automated tools	Manual testing
Speed	Minutes to hours, on every build	Days, on a schedule
Coverage	Broad and shallow	Narrow and deep
Finds	Known patterns, misconfigurations, vulnerable components	Access control, business logic, chained exploits
False positives	Common; need triage	Rare; every finding is proven
Output	A list to triage	Proven findings with evidence, impact, and fixes
Best use	Continuous coverage between tests	Depth on the applications that matter most

Building a layered AppSec testing strategy

There is a recurring hope in application security that one tool or one test will make an application secure. Buy the scanner, run the pentest, check the box. It never works, because every testing method has a blind spot, and attackers live in blind spots. The goal is not to pick the best method; it is to combine them so the gaps do not line up.

The matrix shows which method catches which kind of flaw. Every column has gaps, and the last three rows are flaws only a human finds reliably.

Flaw	SAST	SCA	DAST	Manual pentest	Code review
Known vulnerable library	No	Yes	Partly	Partly	Partly
Injection in your own code	Yes	No	Yes	Yes	Yes
Hardcoded secret in the repository	Yes	No	No	Partly	Yes
Missing security headers or exposed files	No	No	Yes	Yes	Partly
One user reading another user’s data (IDOR)	No	No	No	Yes	Partly
Business logic abuse, such as skipping a payment step	No	No	No	Yes	Partly
Low-severity issues chained into a critical	No	No	No	Yes	No

The layers map onto the development lifecycle:

• In development, SAST and SCA run continuously in the pipeline, catching known issues before code merges. Expert secure code review focuses on the riskiest changes. Our guide to shifting security left in the SDLC covers how to wire that in, and CI/CD pipeline security covers protecting the pipeline itself, whose runners and secrets attackers target directly.
• In testing and staging, DAST (and IAST, if you instrument) exercises the running application automatically as features stabilize.
• Before major releases and on a regular cadence, manual penetration testing provides the deep, adversarial, human assessment, finding the logic and chained flaws automation never will.

The automated layers give you breadth and continuous coverage cheaply. The human layers give you depth and judgment where the stakes are highest. Together they mean a flaw has to slip past several very different kinds of scrutiny to reach production.

Getting the balance right

Two failure modes are common. Some teams over-rely on automation, running scanners and calling it a program, then get breached through a business logic flaw no tool was ever going to find. Others treat an annual pentest as their entire strategy, leaving eleven months of continuous change uncovered.

The balanced program uses automation for what automation is good at (breadth, speed, continuous coverage) and reserves expert human testing for what only humans do well: understanding the application’s purpose and finding the ways it can be turned against itself. Point the human depth at your highest-risk applications and the code that would hurt most if it failed.

How often to test

Run the automated layers continuously. Run manual testing at least once a year, and again after changes that move risk: a new authentication system, a new role or tenant model, a payment flow, a major release, or a platform migration. Compliance often sets the floor. SOC 2 auditors expect recent testing evidence, and PCI DSS requires annual testing of the environment that handles card data. Our guide to how often you should run a penetration test lists the triggers by framework.

What manual web application testing costs

Automated tools are licensed per seat, per application, or per scan, and they run as often as you like. Manual testing is priced by scope. We publish ours: a web application penetration test starts at $5,200 for a small application, $7,800 for an established product with several roles, and $12,500 and up for large or multi-tenant platforms. Every price is fixed in writing before work begins, with no hourly billing, and the retest of remediated findings is included. The size bands and what fits each one are on our web application penetration testing pricing page.

If you are comparing providers, our list of web application penetration testing companies sets out what to check before you sign.

Frequently asked questions

What is web application security testing? It is the process of finding and fixing security weaknesses in a web application using automated tools (SAST, SCA, DAST, IAST) and manual testing. The automated methods give breadth; manual penetration testing gives the depth that finds access control and business logic flaws.

Is a DAST scan enough? No. A DAST scan finds known patterns on the pages it can reach. It cannot tell whether one user can read another user’s data, and it cannot abuse a workflow it does not understand. Use it between manual tests, not instead of them.

What is the difference between web application security testing and web application penetration testing? Web application security testing is the umbrella for every method, automated and manual. A web application penetration test is the manual part: a tester attacks the application, proves what is exploitable, and reports it with evidence and fixes.

How long does a manual web application test take? A small application runs about a week of testing followed by reporting. Larger applications with more roles and workflows take longer. Our guide to how long a penetration test takes breaks down the timeline by test type.

Should we test in production or staging? Staging, whenever it mirrors production closely enough. If production is the only option, agree written rules of engagement first: no denial-of-service techniques, no destructive payloads, and defined testing windows.

Does passing the OWASP Top 10 mean we are secure? No. The OWASP Top 10 2025 is an awareness list of risk categories, not a test plan. Use the WSTG categories above for coverage and the ASVS for requirements, and let manual testing cover the logic that no list can describe.

The takeaway

No single method secures a web application. Automated tools give you breadth and speed; manual penetration testing gives you the depth that finds real breaches. The teams that stay secure run both: continuously for the routine, periodically for the sophisticated.

If you want the deep, human layer that anchors real web application security testing, scope a web application penetration test. You get a fixed price, a fixed scope, and a free retest, and we will find what the scanners have been missing.