Checklist · CRM Account Operations
Multi-Brand Data Isolation: Access Tests for a CRM
Test tenant and brand boundaries across search, exports, support tools and APIs using a role-resource matrix and explicit negative access cases.
Published Updated
Published by FxTrusts, a supplier of brokerage and prop firm technology. Prepared with AI-assisted research and drafting; reviewed against the cited public sources. Examples are illustrative. Product links describe our services.
Quick answer
Multi-brand isolation requires each request to be authorized for the specific actor, action and resource, including its tenant or brand relationship. A role label or hidden menu is not enough. Test data access through direct URLs, APIs, exports and background workflows as well as the visible interface.
Define the boundary the system promises
A brand can be a presentation label, a separate tenant, a legal entity or another operating scope. Those are different arrangements. Document which records are shared, which are isolated and which staff roles can cross the boundary. Client profiles, wallets, trading accounts, documents and reports may require different treatment. Do not infer isolation merely because each brand has a separate logo or login page.
Test the resource relationship on every route
OWASP authorization guidance recommends least privilege and checks on every request. A user allowed to view one client must not gain another tenant’s client simply by changing an object identifier. Test direct record endpoints, search filters, bulk actions and related objects. A parent record may be protected while an attachment or export endpoint leaks the same information. Include revoked and expired permissions rather than testing only newly created users.
Include privileged support and asynchronous work
Support impersonation, scheduled reports, notification jobs and data exports can bypass assumptions made in the normal interface. Define who can initiate them, the scope they inherit and how results are delivered. A background job should not lose its tenant context when it runs later. Record privileged actions with sufficient actor and target information to investigate misuse, while excluding unnecessary sensitive data from the log itself.
Make evidence specific and repeatable
Use synthetic records with distinctive markers for each tenant. Record the request, expected authorization result, observed response and any side effect. A forbidden response that still sends an email or creates an export is not a successful negative test. Retest after role, integration or tenant-model changes. Passing a small test matrix is evidence for those cases, not a security certification or proof that every possible isolation failure has been excluded.
A fictional role-resource matrix
Create synthetic tenant A and tenant B clients. An A-only support user may view A’s approved support fields, but cannot view B’s record or export B’s documents. A separately authorized cross-tenant auditor may have read access with an audit trail. These roles are illustrative; the actual operator must approve the scope and verify server-side enforcement.
| Actor | Action/resource | Expected result |
|---|---|---|
| A-only support | View tenant A support fields | Allow within granted scope |
| A-only support | Direct API request for tenant B client | Deny; no data or side effect |
| A-only support | Bulk export including tenant B | Exclude or reject under explicit policy |
| Revoked user | Reuse previous session for tenant A | Deny under revocation policy |
| Authorized auditor | Read both tenants | Allow only granted read scope; log access |
Implementation checklist
- Define whether a brand is an actual isolation boundary.
- Test object-level access through UI, API, attachments and exports.
- Preserve tenant context for support tools and background jobs.
- Check side effects on denied requests and retest after permission changes.
Sources
These documents support the reference. Check the original publication for current requirements and the limits of its scope.
- OWASP authorization guidancecheatsheetseries.owasp.org
- OWASP logging guidancecheatsheetseries.owasp.org
- B2CORE trader-room documentation and featuresb2broker.com
Continue with the broader guides
Connect this reference to platform selection and the wider operating workflow.