Skip to content

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 call

Free 30-minute scoping 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 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.

See what a report looks like

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?

Request a scoping call

Include your country code. We only use it to follow up on your enquiry.

Please leave out passwords and customer data.

We only use your details to reply to your enquiry. How we handle enquiry information.

Or email contact@unmesha.io directly.

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