Web application penetration testing
Web application penetration testing
We test your web application and APIs as one connected attack surface. Our penetration testers work alongside A.R.T. to uncover more, validate how weaknesses combine and show what an adversary could actually reach.
A penetration tester replies within one working hour to ask the questions needed to scope your test.
Overview
What is web application penetration testing?
We assess your web application through its public and authenticated functionality, then investigate the APIs, identities and connected services behind it. Manual testing and A.R.T. uncover weaknesses, connect related issues into attack paths and show what your data, users and business processes are exposed to.
This is for you if…
Roles or tenants must stay separate
The application has several user types, tenants or privileged functions that must remain within the right boundary.
You have been asked for proof
A client's security questionnaire, an insurer or an auditor asks for proof of an independent test.
A launch is close
A new application or a major rebuild is due to launch, and you want it tested before your users arrive.
New to the term? What penetration testing means, in our glossary
Why you need it
Why does your web application need a penetration test?
The scoping call maps how the application works, the roles and tenants it supports, the data and workflows it handles, and the interfaces behind it. We then agree which environments, APIs, identity services and connected components form the assessment boundary rather than assuming every related system is included.
Public exposure
Internet-facing routes, application endpoints and relevant supporting services explicitly included in scope.
Identity and session
Registration, authentication, recovery, multi-factor authentication and the session lifecycle from sign-in to sign-out.
Roles and business logic
What each user, administrator and tenant can see or do across the workflows that matter to the organisation.
APIs and connected services
What the front end calls, what those services enforce independently and which authorised integrations extend the trust boundary.
Motive
Which application functions and boundaries matter most?
The application enforces who can approve an action, change a record, invite another user or administer a tenant. Those workflows often matter more than a technical weakness in isolation because they decide what a valid account can do and which trust boundaries it can cross.
We agree the high-value data, functions and business outcomes during scoping. Testing follows the paths most relevant to them, and findings are prioritised by what they enable and how reliably the path can be repeated.
High-value workflows
Invitations, approvals, payments or document access used outside their intended sequence.
User and tenant boundaries
Records and actions that must remain isolated between users, roles and tenants.
Administrative functions
Privileged actions whose impact depends on strong authorisation and accountable use.
Connected services
In-scope APIs, identity services and integrations that decide what a request may do.
Reach
How can separate weaknesses become an attack path?
A low-visibility weakness can become serious when it crosses a trust boundary. We investigate whether individual issues can be combined to move between users, roles or tenants, reach sensitive functions or call a back-end service in a way the intended interface never allows. Material paths are validated safely within the agreed rules of engagement.
Entry
Identify an interface
Client-side behaviour reveals an endpoint used by a sensitive workflow.
Yields a request to investigate
Step
Replay a valid request
The request is recreated outside the intended interface with an authorised test session.
Yields the server's independent response
Step
Cross a trust boundary
A role or tenant identifier is changed to test whether server-side authorisation refuses it.
Yields evidence of missing enforcement
Impact
Validate the impact
The tester confirms the data or action exposed within the agreed rules of engagement.
Yields a verified finding
In practice
Manual testing examines authentication, recovery, sessions, authorisation, input and file handling, and the business rules behind important workflows. Requests are replayed and altered across the roles and tenancy boundaries agreed in scope, including direct calls to supporting APIs.
OWASP WSTG and the OWASP API Security Top 10 inform coverage, but the application and agreed objectives shape the assessment. Priority reflects the practical impact and exploitability of each validated path rather than a scanner score alone.
Methodology
How Adversify tests your web application
We define the app and desired outcomes, map its boundary, test it and report what matters. Manual and A.R.T.-assisted work share one scope. The tester controls sensitive activity and validates every finding before it enters the single final Adversify report.
- Roles
- Sign-in
- Sessions
- APIs
- Uploads
- Data
- Servers
Engagement design
We start with the application, its users, data and high-value workflows, and the questions you need the engagement to answer. We agree environments, roles, accounts, APIs, connected components, exclusions, testing windows and escalation contacts.
- Scope
- User roles
- Rules of engagement
Analyse the attack surface
We map public and authenticated functionality, roles, tenancy boundaries, interfaces, APIs and relevant integrations. This defines where trust changes, what the client assumes the server will enforce and which paths deserve deeper investigation.
- Mapping
- API discovery
- Risk-based
Investigate and validate
Manual testing and A.R.T. investigate relevant functions, roles, inputs and behaviours in parallel. The penetration tester follows material leads, approves sensitive actions and validates whether weaknesses can be combined into a practical attack path.
- Manual testing
- A.R.T.-assisted
- Safe validation
Reporting and evaluation
You receive one accountable Adversify report with a plain-language summary, validated technical evidence, affected roles or workflows, reproduction steps and prioritised remediation. The testers then debrief the people responsible for decisions and implementation.
- Report
- Debrief
- Recommendations
AI integration
Where does AI take part in this test?
A.R.T. works alongside the penetration tester throughout the assessment. Specialised agents investigate different functions, roles, inputs and behaviours in parallel, share useful context and return potential weaknesses for deeper investigation. The tester oversees the scope, approves sensitive actions and validates every result before it enters one Adversify report.
How the A.R.T. agents are organised, in three tiers:
- Tier 1: the lead tester, which coordinates the domain testers.
- Tier 2: three security domain testers, for application testing, authorisation review and input handling.
- Tier 3: a group of testers under each domain tester.
Work passes down the tiers and findings pass back up. An Adversify pentester oversees all three tiers and the work, approving sensitive actions and verifying findings.
Lead tester
A.R.T. does The lead agent plans focused investigations from how your application works, within the agreed scope.
Adversify pentester does The pentester agrees the scope, access and exclusions with you and stays involved throughout.
Domain testers
A.R.T. does Each domain tester takes one security concern, such as authorisation or input handling.
Adversify pentester does The pentester approves or denies any sensitive action before it is carried out.
Testers
A.R.T. does Testers examine the relevant functions within the agreed scope and connect related weaknesses into attack paths.
Adversify pentester does The pentester verifies each finding and its impact before it goes into your Adversify report.
Coverage
What does a web application penetration test cover?
Depending on the application and agreed scope, testing may cover public exposure, identity and sessions, roles, tenant boundaries, business logic, APIs, input handling and relevant integrations. The scoping call confirms environments, accounts, functions, interfaces and exclusions. The report records what was assessed.
Mapping the attack surface
Public and authenticated routes, endpoints, roles, tenants, identity services and connected components explicitly included in scope.
Sign-in and session handling
Passwords, reset, multi-factor, session tokens and sign-out, each tried for a way past it.
Access control
Relevant functions exercised across agreed users, roles and tenancy boundaries, including privileged actions.
Business logic
Workflows, invitations, approvals, pricing, payments, documents and administrative actions where relevant.
Input and file handling
Injection, parsing, uploads, downloads and storage paths reached through application-controlled input.
The APIs behind the application
In-scope endpoints called by the pages, and additional endpoints identified during testing, tried with valid, other-user and no session.
OWASP WSTG and the OWASP API Security Top 10 inform coverage. The application and agreed objectives determine where testing goes deeper.
What you get
What you get from a web application penetration test
You receive one Adversify report that explains the affected roles, tenants, workflows, APIs and data for each validated finding. It combines a plain-language assessment with reproducible technical evidence and practical remediation. Priorities reflect what the weakness enables, and the testers explain the result.
You receive
The penetration test report
One document, with a plain summary up front and each finding written up in full behind it.
Evidence for every finding
The requests, responses and screenshots that prove it, and the steps to reproduce it.
Remediation guidance
Each change set out in order of harm, in terms the developers making it can follow.
A debrief with the testers
A call that walks your developers and leadership through the findings with the people who found them.
What changes
- Scope is drawn from the whole surface: what surrounds the application, its public pages and sign-in, what users can do and the back end
- Findings are validated by exploitation, not by score
- Each finding sets out what to change, not only what is wrong
Questions
Web application penetration testing questions
We explain how scope is set, which roles, APIs and services may be included, how live work is controlled and where A.R.T. contributes. Scoping confirms all sites, workflows, accounts, safeguards, test windows and exclusions with you before any work begins.
Not answered here? Ask it on the scoping call
How do you scope a web application assessment?
We agree the application environments, domains, APIs, user roles, tenant types, important functions, identity services and relevant integrations. The scope also records exclusions, test accounts, safety constraints and the business or security questions the engagement must answer.
Does this include hosting or identity infrastructure?
Only where relevant and explicitly authorised. We identify hosting, identity providers and connected services during attack-surface analysis, then agree which components are included. Testing the wider internet-facing estate is a separate external penetration testing scope.
Are APIs and different user roles included?
Where agreed, we test APIs directly and exercise relevant functions as each supplied user role and tenant type. The quote identifies the interfaces, roles, accounts and environments included, along with any desktop or other clients that require a separate assessment.
Will you test against our live application?
Either live or a copy, agreed at scoping. A staging copy with realistic data is safest for anything that writes or deletes; where only live will do, we agree the testing window, limits and a named contact. Potentially disruptive actions are identified in advance and carried out only with your approval and agreed safeguards.
How is A.R.T. used during the assessment?
A.R.T. works alongside the penetration tester. Specialised agents investigate different functions, roles, inputs and behaviours and share useful context. The tester oversees the work, approves sensitive actions and validates every result before it can appear in the Adversify report.
Is a retest included?
No, a retest is not part of the engagement. If your developers would like their changes checked against the application afterwards, a retest can be scoped and quoted separately.
What happens next?
Ask for a quote scoped to your web application
Tell us which application and environments need testing, the known APIs, user roles or tenant types, release date and any data, workflow or objective that matters most. A penetration tester will reply within one working hour to confirm scope and prepare a quote against agreed deliverables.
- Scoped to your application, agreed up front
- CREST-accredited for penetration testing
- Based in York, working across the UK
A tester goes through the scope with you, and the quote is written from it.