How to Build a Web App Security Testing Program That Actually Holds

Most of the breaches I get called in after were not missed because nobody tested the application. They were missed because one kind of test was doing all the work, and the flaw lived in the one place that test was never going to look.

That is the trap with web application security testing. It sounds like a single thing you either do or do not do. It is really a set of methods that each catch different problems, and a program is secure only when the methods overlap enough that a flaw has to slip past several of them to reach production.

Here is how I think about the pieces, and how to put them together.

The methods, and what each one is blind to

There are six approaches that cover almost everything a team actually runs. None of them is complete on its own.

• SAST reads your source code without running it and flags insecure patterns: injection sinks, hardcoded secrets, unsafe functions. It runs on every commit. It has no view of runtime behavior and it generates false positives you have to triage.
• SCA scans your third-party dependencies for known vulnerable components. Given how much of any application is open-source code, you need it. It says nothing about the code you wrote.
• DAST attacks the running application from the outside, like an automated intruder, and finds issues that only show up at runtime. It cannot see the code, it misses business logic, and it only tests the paths it can reach.
• IAST instruments the running app to combine the static and dynamic views, which makes it more accurate than either alone. It needs that instrumentation, and it still misses design and logic flaws.
• Manual penetration testing is a skilled person attacking the application with intent. This is where the flaws that cause real breaches surface. It is a point-in-time exercise, and its value scales with the tester.
• API testing works from the specification, with an account for every role, because most modern applications are an API with a UI bolted on, and testing only what the browser calls leaves the rest untested.

Run the automated layers continuously. Reserve the human layers for depth where the stakes are highest.

What no scanner will ever find

The most damaging vulnerabilities require understanding what the application is supposed to do and then abusing that intent. A scanner has no concept of intent, so it reliably misses four things:

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

This is the whole reason manual testing stays irreplaceable. Everything in that list is invisible to a tool and obvious to a human who understands the application.

Use the OWASP WSTG as your backbone

When I build a checklist, I start from the OWASP Web Security Testing Guide (stable version 4.2), which organizes web testing into twelve categories, from information gathering and configuration through authentication, authorization, session management, input validation, business logic, client-side and API testing.

Two things matter about using it. First, roughly half of it is automatable and half is not. Information gathering, configuration, error handling and weak cryptography lean automated. Authorization, identity management and business logic are human work. Authorization in particular needs two accounts per role to prove a cross-user finding.

Second, a checklist is a floor, not a ceiling. The business logic row is one line in a table and endless in practice, because every application's logic is different. If you need requirements to test against rather than a method, pair the WSTG with the OWASP ASVS.

What a manual engagement actually looks like

When one of our testers works a web application, it runs in roughly this order:

1. Map the application. Walk every feature as every role, recording each request through an intercepting proxy.
2. Build the authorization matrix. Write down who should have access to each function and object, then replay each request as every other role and as a second user of the same role.
3. Attack authentication and sessions. Password reset, MFA enrollment and bypass, token lifetime, logout, and what happens to a session when the password changes.
4. Probe input handling. Automated payloads find the obvious cases; the tester confirms exploitability and impact by hand instead of reporting a reflected string.
5. Abuse the business logic. Skip steps, repeat them, reorder them, change prices and quantities, race two requests, and upload what the app does not expect.
6. Chain and prove. Combine findings into the path an attacker would really use, and capture the reproduction steps an engineer needs to fix each one.

A small application is about a week of testing followed by reporting; larger applications with more roles and workflows take longer. We test against staging where it exists, and against production only under written rules of engagement.

The tools do the repetitive work

A good tester uses a lot of tools and trusts none of them to think. Intercepting proxies like Burp Suite and ZAP sit between the browser and the application so every request can be read, replayed and modified, and that is where most manual web testing happens. DAST scanners, including the engines built into those proxies, crawl for known patterns; Acunetix is a common standalone one, now sold as Invicti Web + API according to acunetix.com as of September 2026. In the pipeline, SAST tools such as Semgrep, CodeQL and SonarQube flag risky code, and SCA tools such as Dependabot and OWASP Dependency-Check flag vulnerable libraries. The tools give breadth and speed, not judgment.

Layer it, don't pick a winner

There is a recurring hope in this field that one tool or one test makes an application secure. Buy the scanner, run the pentest, check the box. It never works, because every method has a blind spot and attackers live in blind spots.

So map the layers onto the lifecycle instead of choosing between them. In development, SAST and SCA run continuously and secure code review focuses on the riskiest changes. In testing and staging, DAST exercises the running app as features stabilize. Before major releases and on a regular cadence, manual penetration testing provides the deep, adversarial pass that finds the logic and chained flaws automation never will.

The two failure modes I see most: teams that run scanners and call it a program, then get breached through a logic flaw no tool was going to find; and teams that treat one annual pentest as their whole strategy, leaving eleven months of change uncovered. The balanced answer uses automation for breadth and continuous coverage, and points expert human testing at the applications and code that would hurt most if they failed.

As for cadence: automated layers run continuously, manual testing at least once a year and again after anything that moves risk — a new authentication system, a new role or tenant model, a payment flow, a major release. Compliance sets the floor, with SOC 2 auditors expecting recent evidence and PCI DSS requiring annual testing of the cardholder environment.

What the human layer costs

Automated tools are licensed per seat, application or scan. Manual testing is priced by scope, and 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, there is no hourly billing, and the retest of remediated findings is included.

What to remember

• No single method secures a web application; each one has a blind spot.
• Automated tools (SAST, SCA, DAST, IAST) give breadth and speed — run them continuously.
• Manual testing finds broken access control, business logic abuse and chained exploits — the issues behind most real breaches.
• The OWASP WSTG is your coverage backbone; the ASVS gives you requirements.
• Passing the OWASP Top 10 2025 is not a test plan; it is an awareness list of risk categories.
• Layer the methods onto your lifecycle so the gaps never line up.

This article is based on Invadel's guide "Web Application Security Testing: The Complete Guide": https://invadel.com/blog/web-application-security-testing/ — read it for the full detail. Mark Kiss is the founder of Invadel, a penetration-testing firm — https://invadel.com/ has the services and fixed prices.