What application security testing covers
We test the software your customers and staff use: web applications, mobile apps, and the APIs behind them. Testing looks at how the application handles identity, access, data, and input, and whether its business rules can be bypassed.
This service is for teams that ship software and need an independent assessment before a release, after a significant change, for a customer security review, or as evidence for an audit. Security leads, engineering leaders, and compliance owners usually scope it together.
What is in scope
We agree the exact targets with you during scoping. An engagement can include any of the following.
Web applications
Customer-facing applications and admin portals. Input handling, injection, cross-site scripting, file uploads, client-side controls, and server configuration.
Mobile apps
iOS and Android apps, including local data storage, transport security, platform permissions, and how the app talks to its backend.
APIs
REST and GraphQL APIs, including object-level and function-level authorization, mass assignment, rate limits, and data returned in responses.
Authentication and session handling
Login, single sign-on, multi-factor authentication, password reset, token handling, session expiry, and separation between roles and tenants.
Business logic
Workflows such as payments, approvals, orders, and account changes, tested for steps that can be skipped, repeated, or reordered.
Secure code review
Targeted review of security-relevant source code, run alongside testing or as a separate activity.
How an engagement runs
We agree the applications, environments, user roles, and API endpoints in scope, the testing approach, test windows, excluded actions, and contacts on both sides. These are recorded in the rules of engagement, along with how urgent findings are raised during testing. An NDA is signed before you share details.
We test the agreed targets with the accounts and access you provide. Testing is manual, supported by tooling, and covers authorization between roles and tenants as well as technical vulnerabilities.
You receive an executive report and a technical report. Each finding has a severity rating, the affected component, reproduction steps, and remediation guidance.
After your team fixes the findings, we retest them and confirm which issues are resolved and which remain open.
What you receive
Each engagement produces the same set of deliverables, sized to the scope you agree with us.
Agreed scope
- Written scope covering targets, environments, and accounts
- Rules of engagement with test windows, excluded actions, and contacts
- NDA signed before you share details
Findings
- Each finding rated by severity
- Affected component, request, and evidence for each finding
Reports
- Executive report for leadership and stakeholders
- Technical report with reproduction steps for each finding
- Remediation guidance your engineers can act on
Retest
- Retest of findings after your team applies fixes
- Updated status for each retested finding
Testing approaches
The approach sets what we can see and how far testing goes. Duration depends on scope.
| Approach | What you provide | When it fits |
|---|---|---|
| Black box | A URL or app build, with no accounts or documentation | You want to know what an outside party with no access can find. |
| Grey box | Test accounts for each role and API documentation | Most engagements. Testing covers authenticated features and access between roles and tenants. |
| White box | Accounts, documentation, and access to source code | You want testing and code review together, or the application handles sensitive data or high-value transactions. |
Standards and methods
Web testing follows the OWASP Web Security Testing Guide (WSTG). Where you need verification against a defined level, we map coverage to the OWASP Application Security Verification Standard (ASVS).
Mobile testing follows the OWASP Mobile Application Security Verification Standard (MASVS) and Mobile Application Security Testing Guide (MASTG). API testing covers the OWASP API Security Top 10. The overall process follows NIST SP 800-115.
Common questions
Will testing affect production?
Testing is planned to avoid disruption. The rules of engagement set test windows, list excluded actions such as denial-of-service or load testing, and name who to contact if something looks wrong. Actions that could change or delete data are agreed with you first.
Do you test staging or production?
Either. Staging is often preferred when it matches production closely and holds no customer data. Some configuration and integration issues only show in production. We agree the environment with you during scoping.
What access do you need?
For grey box testing, test accounts for each user role, API documentation such as an OpenAPI file or request collection, and app builds if mobile is in scope. For white box testing, read access to the relevant source code.
Can you test a single feature or release?
Yes. Scope can be a full application or a specific feature, set of endpoints, or release. Duration depends on scope.
How are findings shared securely?
We sign an NDA before you share details of your environment. How reports and other sensitive material are exchanged is agreed with your team during scoping.
Can you provide a letter for our customers?
We can discuss it during scoping.
How to prepare
List the applications, domains, API endpoints, and mobile builds you want tested, and the environment for each. Create test accounts for each user role. For multi-tenant applications, create accounts in at least two tenants so we can test separation between them.
Share API documentation, architecture notes, and previous test reports. Name a technical contact for the testing window, and tell us about third-party services or hosting providers whose terms may limit testing.
When teams book application testing
Before a major release
New products, major features, or a public launch.
After a significant change
A new identity provider, a new API, or a change in architecture.
Customer security reviews
Enterprise customers and procurement teams often ask for a recent independent test.
Audit evidence
Testing results as input to audits and certifications your organization holds.
