Mapping
Functions, roles, entry points and data flows. We identify your most sensitive areas.
Web application test focus
Indicative view, not a measurement: 3 primary focus, 2 usual component, 1 context or scope-dependent, 0 outside normal scope.
| Area | Level |
|---|---|
| Authentication and sessions | primary focus |
| Authorisation and permissions | primary focus |
| Inputs and injection | primary focus |
| Business logic | primary focus |
| Configuration and exposure | part of the test |
| Data and secrets | part of the test |
Testing where applications make access decisions
We focus on who may access data and execute functions. We test manually using actual application roles. Tools help map the application; we assess severity and exploitability in its context.
- Authentication, password recovery, MFA and session management.
- Separation of roles, users and tenants in each relevant operation.
- Input handling: injection, cross-site scripting, file uploads and redirects.
- Business process ordering, limits and concurrent requests.
- Application and server configuration, security headers, error messages and exposed components.
Agreed in advance and stoppable at any time
Before testing, we confirm written authorisation and Rules of Engagement: addresses and environments, test accounts, time windows, prohibited techniques and escalation contacts. We recommend a staging environment that accurately reflects production. Production testing requires explicit agreement.
Our approach follows OWASP WSTG. Where control mapping is needed, we can agree coverage against OWASP ASVS. These provide a methodological framework, not certification or a guarantee of complete coverage.
Manual testing
Verification of weaknesses and possible chains with minimal impact on data and operations.
Ongoing escalation
Critical findings are reported through the agreed procedure without waiting for the final report.
Typical finding categories
Categories reflect established vulnerability classes, such as OWASP Top 10. They indicate where we look, not what we will find in your application.
Access control
Access to other users' records through identifier changes, missing server-side role checks and privilege escalation.
Authentication and sessions
Weak password recovery, bypassable MFA and sessions remaining valid after logout.
Injection and inputs
SQL and other injection, cross-site scripting, unsafe file uploads and server-side request forgery.
Business logic
Skipped process steps, repeated benefits, race conditions and bypassed limits.
Configuration
Verbose errors, missing security headers, exposed administration or outdated components.
A report your team can act on
We can review results with developers after handover. Retesting is included only when specified in the proposal.
- Management summary: key risks, impact and remediation priorities.
- Technical findings with reproduction steps and evidence without unnecessary sensitive data.
- Severity explained in your application's context, beyond an automated score.
- Recommended fixes and relevant vulnerability references, such as CWE.
- Scope, assumptions and limitations, making untested areas clear.
What we need and the test's limits
For scoping, we need an application description, roles, main processes, technologies and deadline. Testing requires access to the agreed environment, accounts for each role and a technical contact.
Testing is limited by time, scope and supplied information. It reduces uncertainty and helps prioritise fixes, but cannot prove the absence of other defects.
