Understand the product first
A narrow scope does not mean there is little to test. Start by creating an account, proxying normal use through Burp Suite, and exercising every visible feature. This builds a useful site map while showing how roles, state changes, and workflows are supposed to behave.
Before testing deeply, read the product documentation, changelog, help articles, and engineering posts. Videos can also reveal workflows that are difficult to discover from the interface. I try to give a target enough focused time to understand its purpose before deciding that it has nothing left to explore.
Exercise every endpoint and method
Test one function at a time and map its create, read, update, and delete operations. A user endpoint might expose several methods:
POST /v1/user
GET /v1/user/12345
PUT /v1/user/12345
PATCH /v1/user/12345
DELETE /v1/user/12345
Do not assume two methods share the same authorization logic. A protected PUT handler does not prove the corresponding PATCH handler is safe. Preserve the expected content type and required fields as you test; a malformed request can hide valid behavior behind a generic error.
Test common bug classes in context
CSRF and XSS
Evaluate CSRF protection on each state-changing endpoint instead of treating one protected request as proof for the whole application. For XSS, trace where an input is rendered. A value that is safe on its edit screen may appear later in a different HTML or JavaScript context.
Mass assignment
Mass assignment appears when user-controlled fields are copied into model properties without an explicit allowlist. Start with a valid request, add one plausible property at a time, and verify the result manually.
POST /v1/user HTTP/1.1
Host: test.com
Content-Type: application/json
Authorization: Bearer <token>
{
"username": "newUser123",
"email": "newuser123@test.com",
"firstName": "New",
"lastName": "User",
"userId": 1337
}
Burp’s Param Miner or the open-source Arjun can help identify candidate parameters, but every result still needs contextual validation.
Excessive data exposure
Review complete API responses, not just the fields used by the interface. Ask whether the current role should receive each identifier, contact field, address, token, or internal property. A successful authorization check can still return far more data than the user needs.
Find hidden endpoints and inputs
JavaScript bundles, page source, API collections, and documentation can reveal endpoints or parameters that the visible interface no longer uses. Burp’s JS Link Finder and the open-source LinkFinder are useful starting points.
Treat documentation as a contract
If the documentation says only an owner can invite users, test the same action as every lower role. When behavior contradicts the documented rule, include the exact reference in the report. It gives triage a clear expected result and makes the authorization gap easier to reproduce.
Watch the target change
When moving on, keep lightweight signals for new surface area: API collection updates, changelogs, release notes, newsletters, program scope changes, and public product announcements. A small target can become interesting again as soon as a feature changes.
Keep the workflow repeatable
The goal is not to spray every technique at every request. Learn the product, form a specific hypothesis, test it with a valid request, and record what changed. That process scales better than a checklist used without context.