Web application penetration 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. It costs more than a network test because no tool 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. Broken authorization is the most commonly exploited class of application flaw and the one automation reliably misses. It is the best reason to pay a person.

What a proper web application test covers

Most of that table is human-only work. 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. Each role sees a different application, so each has to be tested. And 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.

Comparing firms for this? Tell us what you need and it goes to the ones in the directory that do this work. No charge, and no phone number required.

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. That is not a security control.

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. Mention undocumented endpoints in scoping. Internal or legacy endpoints that no longer appear in the interface are often still live and loosely authorized.

Where the API is the product rather than a layer under a browser interface, price it as its own engagement. API penetration testing covers how that is scoped and what coverage reporting should look like.

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 methodology adapts to several delivery shapes. The label matters 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. A good one will have formed an opinion, and it is often the most valuable sentence in the readout.

If an enterprise customer's security schedule is the reason you are testing rather than an auditor, the clause wording decides what you buy and the tenant count in your scope decides whether the report answers their question. That is on SaaS penetration testing in Canada.

Who runs this site

TrazTech operates GetPentest and tests web applications: authenticated testing across multiple roles, authorization and tenant isolation, and the APIs behind the interface. More than 20 penetration tests delivered, and 5 CVEs credited to the practice principal. Quotes are tester days at the rates on the cost page.

Do not buy a manual engagement from anyone, TrazTech included, if your application has one role and nobody has asked you for a test. An authenticated scan every release is the right purchase in that case, for the reasons in the note above. Mobile, thick client and hardware targets are separate specializations, and a firm that does not test them regularly should say so when you ask. Mobile and thick client testing are covered on their own pages.