Could one of your customers see another customer’s data?
We sign in as each of your user roles and try to do what that role shouldn’t, like opening another customer’s records.
Request a scoping callFree 30-minute scoping call.
One customer opening another customer’s invoice
A fictional example of what can go wrong here. The same problem appears as APP-01 in our sample report.
Alder Studio signs in
A member opens their own invoice, number 104. Everything works as it should.
They change one number
In the address bar, 104 becomes 208. Nothing else changes.
The app answers
It sends back invoice 208, billed to Birch Dental, with its amount and line items.
Birch Dental’s invoice is open
The app checked they were signed in, but not that the invoice was theirs.
So we ask: Does every request check that the record belongs to the customer asking?
For your engineer
Request from our Alder Studio test account
GET /api/invoices/208
Cookie: session=… (Alder Studio, Member)
HTTP/1.1 200 OK
{ "id": 208, "billedTo": "Birch Dental", "total": 860.00 }
What we check
The questions we start from. We agree the final list with you on the scoping call.
- Can someone get in without the right password or code, or stay signed in when they shouldn’t?
- Does every action check what the user’s role allows?
- Can one customer reach another’s records, files or exports?
- Can a step in a workflow be skipped, repeated or done out of order?
Best done before a big release or an API launch, or when you add roles or plans.
What you get, and what it costs
Fixed fee for the agreed scope, quoted before work starts.
We quote it after the scoping call, once we know what’s in. If the scope grows later, we price the extra before we start it.
Included
- The assessment of the systems we agree
- A findings report with the evidence for each issue
- What to fix first, and how to check each fix
- A walkthrough call with your engineers
- One round of retesting after your fixes
- Steps your developers can repeat for every finding
Not included: Making the fixes (your engineers do that), a compliance certificate and anything outside the agreed scope. Quoted separately: Further retests after the first and extra scope added once work has started.
Before you enquire
What people ask us most. Wondering whether a pentest would do? Is a VAPT enough?
What do you need from us?
A test environment, an account for each role we’ll test, your API docs and some test data. Source code helps but isn’t required.
Where do you stop?
We test the workflows you pick, by hand. That’s narrower than a full pentest, and the report says exactly what we covered.
Is this a penetration test?
Partly. We test the workflows you pick, by hand, so it’s narrower than a full pentest.
Is retesting included?
Yes, one round. Once your team has made the fixes, we retest them. Each finding also comes with a check your team can run themselves.
How do you handle confidential material?
Send an outline first and leave out passwords and customer data. We only ask for anything sensitive once we’ve agreed the scope and a safe way to share it.
Tell us which release you’re least sure about
Which release or workflow worries you, and when does it ship?
What happens next
Sending an enquiry doesn’t commit you to anything. About the team
