Skip to content
Unmesha Technologies, security assessments

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 free callWhat you get

Free 30-minute call.

A typical SaaS product. Your customers sign in to the web app and its API.

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.

  1. Alder Studio signs in

    A member opens their own invoice, number 104. Everything works as it should.

  2. They change one number

    In the address bar, 104 becomes 208. Nothing else changes.

  3. The app answers

    It sends back invoice 208, billed to Birch Dental, with its amount and line items.

  4. 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 call.

Best done before a big release or an API launch, or when you add roles or plans.

  • 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?

What you get, and what it costs

A report with the evidence for each issue, what to fix first, and one round of retesting. See what a report looks like.

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

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

  1. We reply within one working day. We set up the call, and you meet the people who’d do the work.
  2. We send a proposal with the scope, the timing and a fixed fee.
  3. Work starts when you say go.

Sending an enquiry doesn’t commit you to anything. About the team

Request a free call

Send a short outline of what you want checked and any deadline.

Email Unmesha

Please leave out passwords and customer data. How we handle enquiry information.