Prepare staging data without copying customers
Build synthetic tenants, records, and integrations for a security review. Preserve the access relationships without exposing production customer data.
Use synthetic staging data that preserves the relationships you need to test. You usually need to know which tenant owns an invoice, not what a real customer's invoice says. A useful fixture lets the reviewer tell permitted access from forbidden access without receiving private production records.
Synthetic does not mean random. If every test record belongs to one administrator, the fixture cannot show whether ordinary members can cross a tenant boundary. Start from the access rules and create data to challenge those rules.
Which records should you create?
| Fixture | Purpose | Safe contents |
|---|---|---|
| Two separate tenants | Distinguish local from cross-tenant access | Clearly labeled fictional organizations |
| Owner and member accounts | Exercise different permissions | Dedicated test identities |
| A shared item | Check intentional collaboration | A document with an explicit sharing rule |
| An archived item | Check lifecycle restrictions | A record with a known archived state |
| An export file | Check access after background processing | Generated sample rows |
| A revoked membership | Check stale access | A test identity with removed membership |
Keep a private fixture manifest with expected ownership and access. The OWASP authorization guidance is useful for defining the permission checks. The table above is an example fixture design, not an OWASP certification checklist.
How do you prevent real side effects?
Point email, SMS, payments, and booking integrations at approved test destinations or documented sandbox modes. Confirm that a staging job cannot use production credentials through a shared environment variable. Review worker and queue configuration as well as the web application's settings.
Do not assume that a banner saying “staging” establishes isolation. A staging frontend can still call a production API. Check the destination used by each relevant workflow before running a submission, export, or notification test.
Use reserved example domains in text and dedicated controlled accounts where an actual delivery is necessary. Do not invent deliverable addresses that may belong to someone else. Remove real access tokens, session cookies, and storage links from fixtures.
What makes the fixture reusable?
Give every record a stable test label and a reset procedure. Record the expected state before and after each test. If one test removes a membership, restore the baseline before a separate test that assumes membership exists.
Store a versioned fixture definition with the review build. Recreate the fixture for a retest instead of guessing which mutations remain from the first run. State any meaningful production differences in the report. Synthetic staging evidence supports the behavior tested; it does not prove that production configuration is identical.
For a scoped review, send Sourced a description of the test environment. Share private data only through a separately agreed channel.
Know what you will get from a review
Explore an illustrative finding with evidence, a proposed fix and retest criteria. Discuss your systems, review questions and deadline when you are ready.