Web application security testing
Web Application Security Testing
Test your web application the way a real attacker would. We combine manual testing with tooling to examine your application, its APIs, and the logic that controls who can do what. All web application testing is performed by consultants who hold both GWAPT and OSWE.
Short answer
What a web application penetration test covers, and how it differs from a scan.
What is web application security testing?
Web application security testing checks a web application, its APIs, and the logic behind them for weaknesses an attacker could use. Testers sign in with the roles agreed in scope, work through authentication, access control, input handling, and business logic, and report each confirmed issue with steps to reproduce and a fix. It ranges from automated scanning to a manual penetration test, and the right depth depends on what you need to learn.
Web application penetration testing is the manual end of that range: an authorized, scoped test of your web applications and, often, the APIs behind them. Testers validate weaknesses by hand and confirm what an attacker could actually do within the agreed scope. Apps on phones are covered by mobile application penetration testing, and the servers and networks underneath by network penetration testing. For one common API issue you can check yourself, see the dangers of misconfigured CORS headers.
Automated vulnerability scan
- What it finds
- Known vulnerability patterns, outdated components, missing security headers, and common misconfigurations that a tool can recognize.
- What it misses
- Broken access control between roles and tenants, business logic flaws, and issues that only matter when several are chained. Results usually need manual review to remove false positives.
- When to choose it
- You want frequent, low-effort checks between deeper tests, for example after each release.
Web application security assessment
- What it finds
- Gaps in the application's security controls and configuration, reviewed with tooling and manual checks against an agreed baseline such as the OWASP Top 10 or ASVS.
- What it misses
- It usually does not try to exploit each issue or show a full attack path, so real-world impact can be less certain. What is included varies between providers, so it is agreed in scope.
- When to choose it
- You want broad coverage and a gap list against a standard, for example when setting a security baseline or before a major release.
Penetration test
- What it finds
- Issues testers confirm by hand, including access control failures, logic abuse, and chained issues, each with evidence of impact and steps to reproduce.
- What it misses
- It is a point-in-time test limited to the agreed scope and testing window, so anything out of scope or changed afterward is not covered.
- When to choose it
- You need to know what an attacker could actually do with your application, for a customer security review, or as independent evidence for a compliance program.
Not sure which one fits? Tell us about your application and we will help you choose.
Why it is manual first
Scanners find known patterns. They often miss flaws that matter in modern applications: broken access control, logic abuse, and chained issues.
Our testers work through the application by hand, using tooling to widen coverage and confirm findings rather than to replace judgment.
That approach surfaces the issues automated tools tend to skip, and it lets us explain the real path an attacker would take.
A scoped test also works differently from an open research program. Seepenetration testing vs bug bountyfor how the two compare.
What we test
- Authentication and session handling.
- Authorization and access control between roles and tenants.
- Input handling, including injection and unsafe rendering.
- Business logic that can be abused to reach unintended outcomes.
- APIs the application depends on, including undocumented endpoints.
- Sensitive data handling and exposure.
- Configuration and common framework weaknesses.
Testing methodology
We structure testing around public OWASP guidance so your team can see what was covered and where each finding fits. Testing combines manual work with tools such as Burp Suite: tools help map the application and repeat requests, and testers confirm each issue and judge its impact. Our consultants hold the GIAC Web Application Penetration Tester (GWAPT) certification and the OffSec Web Expert (OSWE) certification.
The engagement itself follows public reference frameworks such as the Penetration Testing Execution Standard (PTES) and NIST SP 800-115, the technical guide to information security testing. The phases below show how the work runs.
- Reconnaissance and mapping: we sign in with each agreed role, map pages, features, and API calls, and note where permissions and tenant boundaries should apply.
- Automated discovery: we use tooling to widen coverage and flag candidate issues, which testers then review by hand.
- Manual testing: we work through authentication, sessions, access control, input handling, and business logic, comparing what each role can reach.
- Controlled exploitation: where agreed in the rules of engagement, we carefully confirm impact within the agreed scope and test accounts, and we contact your named contact right away if we confirm a critical-severity issue.
- Reporting: we document each validated finding with steps to reproduce, severity, and remediation guidance.
Each phase is checked against the OWASP references below.
- OWASP Web Security Testing Guide (WSTG): test activities are planned against the guide's categories, from information gathering and configuration through authentication, authorization, session management, input validation, business logic, and client-side testing.
- OWASP Top 10: each finding is mapped to the Top 10 category it falls under where one applies, such as broken access control or injection, giving engineers and stakeholders a shared reference.
- OWASP Application Security Verification Standard (ASVS): when you want a requirements baseline, we can agree which ASVS requirements and verification level apply and report results against them.
Our process
- 1
Scope
We agree on the applications, roles, environments, and test windows before any testing begins.
- 2
Access and setup
You provide test accounts and any documentation. We confirm we can reach the systems in scope.
- 3
Testing
We test manually, supported by tooling, and confirm each issue before we report it.
- 4
Reporting
You receive findings with steps to reproduce, business impact, severity, and remediation guidance.
- 5
Readout and retest
We walk through the findings with your team and answer questions. Retest terms are set in the statement of work.
What a good report includes
A report is only useful if your team can act on it.
- Each finding with clear, repeatable steps to reproduce.
- Business impact in language your stakeholders understand.
- Severity rated with a documented, consistent method.
- Remediation guidance written for the engineers who will fix it.
- An executive summary that reflects the actual findings.
Scoping checklist
These questions help us define coverage so both sides know what is included. This is about clarity, not a checklist for choosing a vendor.
- Which applications and domains are in scope.
- Which user roles and permission levels to test.
- Which APIs the application uses (generally included when the web app depends on them). Mobile apps are scoped separately.
- What is explicitly out of scope.
- Test windows and any rate or availability constraints.
- Who to contact if we confirm a critical-severity issue mid-engagement.
A penetration test can support your broader compliance program by providing independent evidence of testing. It is one input among many; it does not by itself make an organization compliant or certified.
What a web application security test looks like: a worked example
This is an illustrative scenario, not a real client or case study. The application, findings, and details are hypothetical and are here to show how an engagement runs from scope to retest.
Imagine a business-to-business software product. Customers sign in to a web application, each customer organization is a separate tenant, and the front end talks to a JSON API. There are three kinds of users: a standard user, an organization admin, and an internal platform admin.
1. How scope is agreed
Before testing starts, we align with your team on the points below so both sides know what is covered.
- In-scope hosts: Example Corp's application at app.example.com and its API at api.example.com.
- Authorization: written approval from whoever controls each asset in scope, including the hosting or cloud provider where its terms require it.
- Roles: standard user, organization admin, and platform admin, so permissions can be compared role by role.
- Test accounts: two separate tenant organizations (Tenant A and Tenant B), each with a standard user and an organization admin, plus one platform admin account.
- Testing window and constraints: agreed dates and a request rate that suits the environment.
- Rules of engagement: which testing techniques are agreed, how test data is created and cleaned up, and when testing pauses.
- Contacts: a named person to reach if we confirm a critical-severity issue mid-engagement.
- Out of scope: the marketing site, the third-party identity provider, other customers' real data, social engineering, and denial-of-service testing.
2. What the testers do, step by step
- 1
Authentication and sessions
We review sign-in, password reset, and multi-factor enrollment, then check how sessions are issued, expired, and ended after logout or a password change.
- 2
Access control between tenants
Signed in as a Tenant A user, we request Tenant B objects by changing identifiers in pages and API calls, and we try admin-only actions as a standard user.
- 3
Input handling
We test forms, search, uploads, and any user content that is shown back to other users, looking for injection and unsafe rendering in the place the data ends up.
- 4
API authorization
We replay the application's API calls with other roles' tokens and test endpoints the interface never calls, to see whether each endpoint enforces permissions itself.
- 5
Business logic
We try the workflows out of order or in ways the designers did not intend, such as reusing single-use links or skipping an approval step.
3. Example findings
Illustrative only. A real report covers every confirmed finding. These four hypothetical rows show the level of detail each one carries.
| Example finding | Severity | How it is demonstrated | Business impact | Remediation guidance |
|---|---|---|---|---|
| Another tenant's invoices can be downloaded | High | Signed in as a Tenant A standard user, request the invoice export endpoint with an invoice ID that belongs to Tenant B. The file is returned. | One customer could read another customer's billing records. | Check tenant ownership on the server for every object lookup, and add an automated test that fails when a cross-tenant request succeeds. |
| Standard user can change roles through the API | High | The role-change button is hidden for standard users, but sending the same API request with a standard user's token succeeds and the account becomes an organization admin. | A standard user could give themselves admin rights inside their own organization. | Enforce role checks in the API for every endpoint, deny by default, and do not rely on the interface to hide actions. |
| Display name is rendered unsafely in the admin user list | Medium | Save a harmless test string containing markup as a display name, then open the admin user list as an organization admin. The markup is interpreted by the browser. | Content entered by one user could run in an admin's browser session. | Use context-aware output encoding, keep the framework's default escaping on, and add a content security policy as a second layer. |
| Sessions stay active after a password change | Low | Sign in from two browsers, change the password in one, and the session in the other keeps working. | A session that has been stolen could stay usable after the user responds by changing their password. | End all other sessions when a password changes, and offer a sign out of all devices option. |
4. The readout and the retest
After the report is delivered, we hold a readout with your engineers and stakeholders. We walk through each finding, show how it was reproduced, talk through the fix, and help your team decide what to address first based on severity and effort. Your developers can ask how a fix should work before they build it.
Retest terms set in the statement of work.
A penetration test is not a compliance certification. It gives you independent evidence of testing that can be one input to a broader compliance program.
What is included
Beyond the testing itself, you get the deliverables your team needs to prioritize and fix what we find.
- Scoped manual testing of the applications, roles, and related APIs we agree are in scope, with tooling used to widen coverage.
- A written report with steps to reproduce, business impact, severity, and remediation guidance.
- A readout after delivery to walk through findings and answer questions.
- Retest terms set in the statement of work.
Frequently asked questions
Short answers to common questions about scoping a web application test.
How long does a web application test take?
It depends on scope, such as the number of user roles, API endpoints, and features in the application. We agree the timeline with you during scoping, before any testing begins.
Can you test production, or do we need a staging environment?
Both are possible. We agree the environment in scope, along with testing windows, request rates, and any actions to avoid. A staging environment that closely matches production keeps testing away from live users, while testing production shows the real configuration. If we confirm a critical-severity issue during testing, we contact your named contact right away rather than waiting for the report.
What do you need from us before testing starts?
Test accounts for each role in scope, API documentation if you have it, the list of in-scope applications and hosts, written authorization, and a named contact we can reach during testing. Authorization has to come from whoever controls each asset, including any hosting provider or third-party service the application relies on.
Is a vulnerability scan enough?
A scan is useful for finding known issues quickly and often, but it cannot judge whether one user can reach another user's data or whether a workflow can be abused. A penetration test adds manual testing that confirms what an attacker could actually do and how to fix it. Many teams use both: scans between releases and a penetration test for a deeper look.
Is a web application security assessment the same as a penetration test?
They are related, not the same. An assessment reviews controls and configuration against an agreed baseline and usually does not try to exploit each issue. A penetration test confirms issues by hand, including access control failures, logic abuse, and chained issues, and reports what an attacker could actually do within the agreed scope. We agree which one you need during scoping.
Do you test APIs and single-page applications?
Yes. APIs the web application depends on are generally included when they are in scope. Single-page applications are tested through both the interface and the API calls behind it, because the API is where permissions need to be enforced. Mobile apps are scoped separately.
Will a web application penetration test make us compliant?
No. A web application penetration test is not a compliance certification. It shows what was found in the applications and APIs agreed in scope, and it can be one input to a broader compliance program by providing independent evidence of testing.
Scope a web application test
Tell us about your application and we will follow up with next steps.