SysTools
VAPT Service

API VAPT

Security testing of the APIs behind your website, mobile app and partner connections — checking logins, permissions, data handling and business rules. Please answer what you can; anything you are unsure of can be settled on the scope call.

Progress 0% 0 of 0 answered 0 mandatory pending

Before you start

  • Please do not type real passwords, API keys or tokens into this form. Those are shared separately through a secure channel.
  • We only test the APIs you list here. Fields marked * are needed before testing can begin.
  • If you are not sure about something, pick "Not sure" or leave a note — we will go through it with you on the scope call.

1 Assessment Details

Mandatory

2 Scope and Testing Approach

Mandatory

Grey Box — you give us login details and basic documents. White Box — you also share the design and technical details. Black Box — we start with nothing, so more of the time goes into finding things rather than testing them.

Please note: this is not included in the timeline estimate in section 7. The estimate covers one round of testing only. How often it repeats is agreed when the scope is finalised.

3 API Details

Decides the timeline

Rough numbers are fine. Leave anything blank if it does not apply.

The API

APIs or services in scope
API endpoints, approximate
User roles or permission levels

Features

Admin-only endpoints
File upload or download endpoints
Payment or money-movement endpoints

Connections

Third-party or partner integrations
Webhooks or callbacks
Login / SSO integrations

An endpoint is one action the API can perform — for example "get user details" or "create order".

We only test the addresses listed here.

If yes, we check that one customer cannot see another customer's data.

A Swagger or OpenAPI file, a Postman collection, or just a list of the endpoints. Without one, a large part of the time goes into working out what the API does before we can test it.

4 Data and Standards

Affects how serious a finding is

This decides how serious a finding is, so an approximate answer is fine. Anything unusual can go in the notes below.

5 How We Test

Nothing here needs an answer — it is what you are buying.

How the assessment runs

We work through every endpoint in scope, using your documentation where it exists and mapping the API ourselves where it does not. Automated checks cover the obvious ground and every result is verified by hand. The bulk of the time is manual testing, which is where the serious findings come from — APIs fail on permissions far more often than on anything a scanner detects. Each finding is reproduced with the exact request that triggers it, then retested once fixed.

What we look for

Whether one user can read or change another user's data by altering an identifier in a request — the single most common serious API finding. Whether endpoints meant for administrators can be reached by ordinary users. Whether responses return more data than the screen shows. How authentication and tokens are handled, whether rate limits exist, and whether data sent in can be used to attack the system behind it. And the business logic: skipped steps, altered amounts, repeated transactions.

What we will not do

This is a controlled assessment, not a red-team exercise. No phishing, no social engineering, no denial-of-service, and nothing destructive. We do only the minimum needed to prove a finding is real.

6 How We Rate Findings

SeverityWhat it means
CriticalCould give an attacker full control of the API, the database or the server, or expose sensitive data at scale. Fix immediately.
HighCould let an attacker take over accounts, reach data they should not see, or gain higher privileges.
MediumA real problem, but it needs certain conditions, a valid login or some user action to work.
LowLimited impact on its own. Worth fixing as part of normal improvement work.
InformationalAn observation or good-practice suggestion. Not directly exploitable.

After a retest each finding is marked Closed, Open, Partially Fixed, Risk Accepted or Not Retested.

7 Timeline Estimate

The API and endpoint counts are carried over from section 3 automatically.

Timeline inputs

Number of APIs
API endpoints
Parallel testing teams
Number of retests

One retest is included as standard. Increase this only if additional retest cycles are required.

Estimated duration 0 working days
Testing0
Retest0

Subject to final scope review, access availability and resource confirmation. The final timeline is confirmed after the complete scope has been reviewed and understood.

Save and Export Response

Your answers stay in this browser until you export or clear them.