Web application security testing

Web application testing is the one category where the gap between a tool and a person is widest, because the flaws that matter most are flaws in logic your application was designed to have.

Last reviewed 2026-08-16Written by Jacob Masse, TrazTech Inc.

Web application security testing is manual testing of a running application by someone logged in as your users, looking for ways to do things those users should not be able to do. It costs $10,000 to $30,000 CAD for a typical authenticated test of a single product, and the reason it costs more than a network test is that there is no tool that can do the important half of it.

A scanner knows what a SQL injection looks like. It does not know that a project manager should not be able to read the payroll export, because only you know that. Broken authorization is the most commonly exploited class of application flaw and the one automation reliably misses, and it is the single best reason to pay a person.

What a proper web application test covers

Notice how much of the table is human-only work. That distribution is the whole argument. If a firm's report is dominated by the bottom rows, you paid application testing rates for infrastructure hygiene.

Authenticated testing, and why it doubles the price

An unauthenticated test looks at the application the way an anonymous stranger sees it. That is a small surface: a marketing site, a login page, a password reset flow, maybe a public API. It is worth testing and it is not where your risk lives.

An authenticated test requires credentials for each role, and the work multiplies in two directions. First, each role sees a different application, so each has to be tested. Second, and more importantly, the interesting testing happens between roles: taking a request that a high-privilege user is allowed to make, replaying it as a low-privilege user, and seeing what comes back.

In a multi-tenant product the same exercise runs across tenants. Two accounts in two different customer organizations, and then a methodical attempt to make one read, modify or delete the other's data by changing identifiers, manipulating tokens, or calling an endpoint the interface never exposes. If you buy one thing from a web application test, buy this. Cross-tenant data access is the finding that turns into a breach notification under PIPEDA and into a mandatory report to the Quebec regulator under Law 25.

APIs are a separate surface

Most modern applications are a client talking to an API, and the API is where authorization is either enforced or not. Testing only through the browser interface tests the front end's opinion about what you are allowed to do, which is not a security control at all.

Give the tester the API specification. An OpenAPI document, a GraphQL schema or a Postman collection turns days of endpoint discovery into hours, and those hours go back into testing. Undocumented endpoints deserve a specific mention in scoping, because internal or legacy endpoints that no longer appear in the interface are frequently still live and frequently still authorized loosely.

GraphQL deserves its own attention. Introspection left enabled in production, query depth with no limit, and per-field authorization applied inconsistently are common and are not things a generic web scanner evaluates.

Variants of a web application test

The same core methodology adapts to several delivery shapes, and the label matters mostly for scoping and price.

Full breakdown of what moves a quote within these bands is on penetration testing cost in Canada, and the black box, grey box and white box distinction is covered on penetration testing types.

Scoping a SaaS product without paying for the wrong thing

Start from the data, not the codebase. List what a breach would expose: customer records, payment details, health information, credentials. Then trace which parts of the application can reach each of those, and scope those parts first. A product with forty screens usually has six that matter, and a test scoped to the six will be deeper than a test scoped to the forty for the same money.

Exclude what you do not control and say so in writing. Your identity provider, your payment processor and your hosted analytics are their vendors' responsibility, and testing them may breach their terms. What is in scope is your integration with them: how tokens are stored, whether webhooks are verified, whether a redirect can be manipulated.

Include the administrative interface. It is the highest-value target in most products, it is often the least reviewed code, and support consoles that can impersonate a customer account are a recurring source of serious findings.

After the report

Triage by exploitability in your environment rather than by generic score. Fix the authorization findings first, always, because they are already exploitable by anyone with a free trial account. Configuration findings and dependency updates can go into normal maintenance.

Then look for the pattern rather than the instance. One broken object reference is a bug. Four broken object references across four endpoints is an architectural finding: authorization is being applied per handler instead of centrally. Fixing the four leaves the fifth to be written next sprint. Ask the tester whether they saw a pattern, because a good one will have formed an opinion and it is often the most valuable sentence in the readout.

Common questions