What we test · Web applications
Web application penetration testing
In one paragraph
A web application penetration test is an authorized attack on your application by a skilled tester who signs in, uses it the way a real user would, and then tries to make it do things it should not. It proves which weaknesses can actually be exploited (for example, reading another customer's data or skipping a payment step) rather than listing everything that looks suspicious. The output is a short list of proven findings, each with evidence and fix steps, followed by a retest once the fix ships.
What the test covers
Authentication and session handling
Login, password reset, multi-factor prompts, remember-me tokens and logout. We check whether any of these can be bypassed, replayed or outlived, which is where an authentication bypass usually hides.
Authorization between users and roles
Whether one tenant can see another tenant's records, or a regular user can reach admin actions. Broken access control is the top category in the current OWASP Top 10 (2025) because automated tools rarely catch it.
Injection and unsafe input handling
Places where user input reaches a database, template, shell or browser without being handled safely, including SQL injection and cross-site scripting.
Business logic
Flows that work exactly as coded but not as intended: applying a discount twice, approving your own request, or changing a price between the cart and checkout.
Server-side requests and file handling
Features that fetch URLs, render documents or accept uploads. These can lead to server-side request forgery or stored malicious files when not constrained.
Configuration and exposed secrets
Debug pages, verbose errors, permissive cross-origin rules, missing security headers and keys shipped in front-end code. These are often small on their own and serious when chained.
Third-party components
Outdated libraries and frameworks with known issues, checked for whether the vulnerable code path is actually reachable in your app rather than flagged by version number alone.
What does a web application penetration test find that a scanner misses?
A vulnerability scanner is good at known patterns: an outdated library, a missing header, a reflected input that matches a signature. It is weak at anything that depends on meaning. A scanner does not know that invoice 1042 belongs to a different company than invoice 1043, or that a user on the free plan should never reach the export endpoint. A human tester does.
That is why the findings that matter most in a web test tend to be authorization and logic flaws. The OWASP Top 10, the most widely used awareness list for web risks, places Broken Access Control first in its 2025 edition, ahead of Security Misconfiguration and Software Supply Chain Failures. These are the issues a buyer should expect a pentest to dig into, not just report from a tool's output.
| Weakness type | Automated scanner | Manual penetration test |
|---|---|---|
| Known vulnerable library versions | Strong, fast and broad | Confirms whether it is reachable and exploitable |
| Missing headers, TLS issues | Strong | Rarely needed beyond confirming impact |
| Reflected injection with clear signatures | Good | Good, plus filter bypasses and chaining |
| Cross-tenant data access (IDOR) | Weak: needs two real accounts and context | Strong: core of the test |
| Business logic abuse | Very weak | Strong |
| Chaining small issues into a real attack path | Not designed for it | Strong |
Scanners still earn their place. Running one continuously between tests is cheap and catches regressions. The two are complements, covered in more depth in penetration testing vs vulnerability scanning.
How is a web application test scoped?
Scope is the written list of what may be attacked and how. For a web app, the useful questions are concrete:
- Which hostnames and environments. Production, staging, or both. Staging is safer to break; production is what attackers see. Many teams test staging with production-like data shapes.
- Which roles. Every distinct role (anonymous, user, manager, admin, and each tenant boundary) multiplies the authorization checks worth running.
- Which flows are critical. Payments, data export, account recovery, invites and anything that touches personal data deserve the most time.
- What is off limits. Typically denial-of-service, third-party payment processors, and email to real customers.
Gray-box testing (the tester gets accounts and some documentation) is usually the best value for web apps because it spends hours on the application, not on guessing how to log in. The trade-offs are explained in black box, gray box and white box testing. All of this is fixed in a signed scope and rules of engagement before any traffic is sent.
What do you need to provide?
- Test accounts for each role, ideally two per role in two separate tenants, so cross-tenant access can be tested honestly.
- A short walkthrough or notes on the flows that matter most to the business.
- API documentation or an OpenAPI file if the front end talks to a backend API.
- A named contact who can pause testing, reset data or answer questions quickly.
- Any known issues you already plan to fix, so time is not spent rediscovering them.
The preparation guide has a fuller checklist.
How long does a web application test take?
Duration depends on the size of the attack surface rather than the number of pages. The main drivers are the number of roles and tenants, the number of distinct workflows and API endpoints behind the UI, how much custom logic exists (a checkout or approval engine takes longer than a marketing site), and whether the test runs in production with care or in a staging environment that can be reset.
How are findings proven and fixed?
In Brexa's method, a finding is only reported after the Prove stage: a human operator reproduces the attack path end to end and records the evidence (the request, the response and the data reached). If it cannot be reproduced, it is not reported. That keeps false positives out of your backlog.
Each finding then goes to whoever owns the fix with exact steps, and the Verify stage re-runs the same attack after the fix ships. The finding closes only when the attack fails. This matters for web apps in particular because authorization fixes are often applied to one endpoint and missed on a sibling. See retesting and fix verification.
Two ways to engage
Test this surface once with a one-time vulnerability assessment, or keep it under continuous testing with autonomous agents. Either way every finding is reproduced by a person before it reaches you, and closes only after a retest shows the original attack fails.
Frequently asked questions
Should we test the web app and its API separately?
If the front end is a thin layer over an API, test them together so the tester can follow requests from the browser into the backend. If the API is also used by mobile apps or partners, it usually deserves its own scope as well.
Is it safe to run a web application penetration test against production?
It can be, with agreed limits: no denial-of-service, care around destructive actions, and a contact who can pause testing. Many teams test staging for depth and production for configuration and exposure.
Does a web application pentest cover the OWASP Top 10?
A competent web test will look for the risk categories in the OWASP Top 10, but the list is an awareness document, not a test plan. The OWASP Web Security Testing Guide is the more detailed reference for what to test.
How often should a web application be tested?
At least after major releases or architecture changes, and on a regular cadence in between. Fast-moving products often add continuous testing so new code is exercised as it ships.
References
Guides for this surface
Other surfaces we test
Book a web applications assessment.
Book a short scoping call. Nothing is tested until scope and rules of engagement are signed, and every finding comes with proof.