Service / Web applications
Web application penetration testing
Your app may check permissions on the main page and miss an export, invitation, or recovery link. We test those paths with dedicated accounts after agreeing on the scope and safe limits.
Where we start
Sign-in is one path into a product. Password resets, invitations, shared files, organization switching, and admin actions deserve a look too. For example, can someone accept an old invitation after an admin removes them from the team?
Before testing, we agree on the app and environment, the roles we can use, and which actions are off limits. That may mean using synthetic records and avoiding live customer data altogether.
Paths worth checking
- Accounts: sign-in, recovery, invitations, sessions, and access after a role change.
- Permissions: whether one role or organization can read or change another's records.
- Sensitive actions: creating, approving, exporting, and deleting data.
- Requests behind the page: APIs that accept record IDs or return fields the interface does not show.
We choose the relevant paths during scoping. The OWASP Web Security Testing Guide describes the wider set of web testing areas.
Findings your team can reproduce
We use test accounts to check suspected issues and report what we can safely reproduce. A finding names the affected flow, shows the evidence and observed impact, and gives engineers a fix to evaluate. After your team makes the change, we retest the same path.
See the sample report for the format. It uses fictional assets.
Bring to the scoping call
- The URLs and environments you want tested, plus exclusions.
- Test accounts for the roles and organizations that matter.
- A short explanation of the workflows that handle sensitive data.
- Actions we should avoid and a contact for questions or urgent findings.
The preparation guide covers these inputs in more detail. If the main concern is an API, see API penetration testing.