Web and API VAPT
Login, sessions, roles, business logic and every API route behind your web app.
A web and API assessment tests the application the way a motivated user with a browser and a proxy would: signed out, signed in as each role, and talking to the API directly without the frontend in the way. Most serious bugs we look for are not in the framework. They are in the rules your team wrote: who may read which record, which step can be skipped, which field the server trusts.
What we test
- Authentication: password reset, OTP and magic links, session lifetime, logout that actually ends the session
- Access control: one user reading or changing another user's records (IDOR), role checks done only in the UI
- Injection: SQL, command, template and header injection, stored and reflected XSS
- Business logic: skipped steps, replayed requests, negative quantities, race conditions on balances and counters
- API surface: undocumented routes, mass assignment, verbose errors, missing rate limits, token handling
- File handling: uploads, downloads and path traversal, server-side request forgery from URL inputs
- Transport and headers: TLS configuration, cookies, CORS and the browser security headers
What do you get at the end?
- A written report: summary for management, then each finding with severity, affected URL or endpoint, the request and response as evidence, impact and a concrete fix
- Findings mapped to OWASP Top 10 and OWASP API Security Top 10 categories where they apply
- A retest of the findings you fix, with the report updated to show what was closed
How does the engagement run?
Scope and written authorization first, then testing inside the agreed window, the report, and a retest of what you fix. The steps are the same for every service and are set out on the approach page.
Frequently asked questions
Do you need our source code?
No. A black-box test works from the running app and test accounts. Read access to the code (grey-box) lets us trace a suspicious behaviour to the exact line and usually finds more in the same time, so we ask for it when you can share it.
Will testing affect our users?
We test a staging copy when one exists. If only production is in scope, we agree a window, use dedicated test accounts, and do not run denial-of-service or destructive tests.
Is an automated vulnerability scan the same thing?
No. A scanner finds known patterns such as outdated libraries, missing headers and some injection points. It cannot tell that user A can open user B's invoice, or that a checkout step can be skipped. We use scanners for coverage, then confirm and extend every result by hand.
What do you need from us to start?
A signed scope and authorization, the URLs and API base paths in scope, test accounts for each role, and a contact who can pause testing if something looks wrong. API documentation or a Postman collection helps us reach routes the frontend never calls.
Tell us what you want tested.
A short call, then a signed scope. No testing before that.