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.

Request a quote See packages

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.

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.

Request a scoping call

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 miss the flaws that matter most 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.

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 exactly 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: the application at app.example.com and its API at api.example.com. The marketing site and the third-party identity provider are out of scope.
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, a request rate that suits the environment, and no denial-of-service testing.
Contacts: a named person to reach if we confirm a critical-severity issue mid-engagement.

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

A real report covers every confirmed finding. These four hypothetical rows show the level of detail each one carries.

Four hypothetical example findings from an illustrative web application security test
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.

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, and a named contact we can reach during testing.

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.

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 penetration test is not a compliance certification. 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.

Request a quote Email us