Skip to content
certyn logoCertyn
Start Free
RecipesDoc

Two Test Organizations, One Cannot See or Change the Other's Records

With two test organizations you own, Certyn checks in the UI and with direct API requests that a member of one cannot reach the other's data.

For teams with a multi-tenant app who want to check that each organization's data stays inside it.

Your setup

  • Each customer is an organization with its own records, for example projects and invoices.
  • Two test organizations your team owns, for example Acme Test and Beta Test, on a test environment.
  • One test account in each, and some records in each.

Say this to Certyn

We have two test orgs, Acme Test and Beta Test, each with its own account. Check that an Acme user cannot see or change Beta's projects and invoices, in the UI and with direct API requests.

What Certyn does

  1. Opens the sign-in form for the Acme account (LOGIN_USERNAME, LOGIN_PASSWORD), and a secret form per value for Beta, for example ORG_B_USERNAME and ORG_B_PASSWORD.
  2. Writes the account map to the wiki's testing rules, for example "Acme: LOGIN_*, Beta: ORG_B_*", and offers to restart the Machine.
  3. Starts an explore run with your goal (app.run.create type explore), for example 60 minutes.
  4. As the Beta user, it only reads: it notes record ids, page URLs and the app's /api calls in the network log.
  5. As the Acme user, it opens Beta's URLs directly, and checks lists, search and exports for Beta's data.
  6. In the shell, it signs in as Acme (curl or a short script reading the variables) and requests Beta's record ids. It expects 403 or 404, and no data.
  7. To check changes, it creates a record in Beta for this test, tries to edit it as Acme, then reads it as Beta to confirm nothing changed.
  8. Files each leak with the request and response (secrets shown as [REDACTED]), and lists every check in the report.

What you get

  • A run report with each check and its result.
  • A Certyn issue with evidence for each record one organization could reach.
  • On request, test cases that name the account to use.

Limits

  • Certyn uses only the accounts and organizations you give it. Give it organizations your team owns on a test environment, never real customers.
  • It edits only records it created, unless you ask otherwise, and asks before destructive changes or any change on production.
  • It checks the pages and API calls it finds and the ones you name. It is not a full security audit. Name the endpoints that matter most.
  • For roles inside one organization, see Several Roles.
PreviousAct Out a Customer's Whole Workflow, Find Awkward Steps and Missing FeaturesNextRehearse a Database Migration on a Throwaway Environment