A multi-tenant application serves more than one customer organization through some shared technology. The commercial attraction is clear: common capabilities can be maintained together. The security obligation is equally important: sharing an application must not give one organization unintended access to another’s information or actions.
The boundary is broader than a customer identifier on a database row. It extends through authentication, authorization, background processing, search, files, caches, exports, support tools and recovery procedures. A correct screen can sit in front of an unsafe export job.
For a product owner and technical lead, the design question is whether tenant boundaries remain enforceable across every path the service uses. This article offers architecture and review questions; it is not a security certification or a substitute for a threat model and qualified security testing.
A tenant is an isolation and administration boundary chosen for the service. It is not necessarily identical to a legal entity, an email domain, a billing account or a physical location. Those relationships need to be modeled explicitly.
For example, one customer group may operate several independent subsidiaries. A consultant may legitimately work with multiple customer organizations. A supplier may participate in different customers’ quality programs without being entitled to see their other suppliers or internal findings.
Define who can create membership, which relationships allow access and which require a separate grant. Avoid automatically treating a shared email suffix or corporate parent as proof of authorization. Business relationships explain why access might be requested; they do not grant it by themselves.
Document the difference between platform administration, tenant administration and ordinary business roles. A customer administrator may manage users within an agreed boundary without being able to change another tenant’s settings or grant unrestricted platform privileges.
The application must determine both who is acting and which tenant context is authorized for the requested action. A user choosing an organization in a menu can express intent, but that selection must be checked against trusted membership and permission information.
Do not rely on a tenant identifier supplied in a form, URL or API body as evidence that the caller may use it. The server should establish the permitted context and evaluate the requested resource and action within it. A hidden field is still client-controlled input.
OWASP’s 2021 Broken Access Control guidance emphasizes enforcement in trusted server-side code, default denial for nonpublic resources, record ownership checks and access-control testing. The multi-tenant implications below apply those principles to shared business services. OWASP Top 10:2021, Broken Access Control.
A tenant check alone is insufficient. Two users in the same tenant may have different rights. The decision may depend on role, record relationship, workflow state and the specific action. Reading a finding, editing it and releasing it to a supplier should not become interchangeable permissions.
Consider a hypothetical supplier-quality application used by several manufacturers. Manufacturer Alder records a quality finding and attaches photographs. Manufacturer Birch uses the same application but has no right to Alder’s records. A supplier representative has separately authorized access to selected findings from each manufacturer.
The tenant boundary must hold when the finding is opened directly, appears in search, contributes to a dashboard, is included in an export or is processed by a notification job. Protecting only the main record page leaves other disclosure paths available.
The attachment needs the same business authorization as its parent finding, unless an explicit policy says otherwise. Knowing the file identifier or possessing an old application link should not bypass the intended access decision. Any temporary download mechanism needs an appropriate scope, lifetime and treatment of changed access.
A supplier representative switching from Alder to Birch should see the authorized Birch context, not a cached result from the previous organization. Likewise, a background export must carry an authenticated and authorized execution context rather than inherit whichever tenant a worker happened to process most recently.
This exercise turns an abstract isolation requirement into a set of concrete engineering and test obligations.
Tenant data can be stored using different degrees of physical and logical separation. Options include shared structures with tenant-aware controls, separate schemas or separate databases and infrastructure. The appropriate choice depends on the service’s risks, contractual requirements, scale and operating capability.
Greater separation can limit some failure paths and make certain customer-specific operations easier. It can also increase deployment, monitoring, backup and maintenance work. A large number of separate environments still requires consistent patching and correctly scoped administration.
Shared storage can support efficient common operations, but a missing tenant restriction can have a broad consequence. Where supported and appropriate, database-level controls can provide additional enforcement. They need correct configuration, privileged-path review and testing; they do not eliminate application authorization responsibilities.
Evaluate restore procedures before choosing a model. Can one tenant’s information be restored without exposing or overwriting another’s? Can the team verify the restored tenant boundary? A backup that is easy to create may be difficult to use safely for a narrowly scoped recovery.
Do not describe one topology as secure by definition. Compare the threats it addresses, the remaining paths and the team’s ability to operate the controls reliably.
Background jobs often outlive the interactive request that created them. The job needs an explicit tenant identity, resource scope and accountable initiator or service authority. Those values should be established and protected by trusted application logic.
Decide whether permissions are checked when work is queued, when it executes and when a result is retrieved. The answer depends on the action and policy, but it should be deliberate. A user whose access was removed should not receive a newly generated export merely because the request entered a queue earlier, unless a specific authorized policy permits that behavior.
Retries and scheduled work need the same boundary controls as first attempts. Include tenant context in the design of deduplication, temporary storage and cache keys where it affects isolation. Otherwise, two unrelated tenants with similar local identifiers can collide in a shared mechanism.
Service accounts should have only the scope their job requires. An all-powerful worker can turn a small context-handling error into a broad disclosure. If elevated privileges are unavoidable for a particular operation, constrain the operation and make its use observable.
Support teams sometimes need to diagnose a customer problem. That need should produce a controlled support capability rather than routine unrestricted access to all customer records.
Define the approved purpose, scope, duration and authorization for elevated access. Record the operator and the tenant affected. Separate diagnostic visibility from permission to alter business data where possible. A support session should not silently impersonate a customer in ways that obscure accountability.
Tenant administrators also need safe boundaries. Test whether they can invite a user to another tenant, change an integration’s destination or grant a role above their delegated authority. Administrative convenience does not justify allowing the customer to expand the platform’s trust boundary.
Keep logs useful without making them another leakage channel. They may need tenant and actor identifiers to investigate an incident, but should not indiscriminately copy sensitive payloads or credentials. Access to diagnostic records and monitoring tools belongs in the security design.
Positive tests show that an authorized user can complete a task. Isolation testing also needs negative cases that show an unauthorized actor cannot obtain the same result through another route.
Build test fixtures with at least two distinct tenants and deliberately overlapping local identifiers where the design allows them. Exercise direct reads, updates, search, exports, files, notifications and background jobs. Check both information disclosure and unauthorized modification.
Include a user with membership in multiple tenants, a user removed from one tenant and an administrator whose authority is restricted. Test switching context, stale sessions and access changes while work is queued. These cases reveal assumptions that a simple one-user-per-customer test misses.
Inspect metadata and aggregates as well as full records. A count, filename, search suggestion or error response can reveal information even when the underlying record cannot be opened. Define the intended response and verify it consistently.
Run these tests in authorized environments with controlled data. Independent security assessment should examine the actual implementation, deployment and integrations. Passing a checklist of examples does not prove the absence of other vulnerabilities.
Customers join, reorganize, merge and leave. Each event can change the relationship among tenant identity, membership, billing and retained records. Treat these as designed workflows rather than exceptional database edits.
A customer merger does not automatically authorize combining all historical access. A tenant export needs an agreed scope and secure delivery method. Offboarding needs to address sessions, service credentials, scheduled jobs, retained information and obligations that may continue after interactive access ends.
Test deletion and retention behavior against the applicable policies and agreements with the responsible specialists. Do not infer a universal retention period from the architecture. Verify how the chosen policy is applied to replicas, backups, search indexes and derived outputs.
A product team should be able to explain who owns each lifecycle decision and what evidence shows that the intended boundary was maintained.
Before release, require a documented tenant model, trusted authorization paths, coverage of indirect data access, operating procedures and test evidence for both permitted and prohibited actions. Review changes that introduce a new export, cache, integration or background job as changes to the isolation surface.
Multi-tenancy is an ongoing engineering responsibility. The application is ready to grow when its shared capabilities have clear boundaries, those boundaries are enforced beyond the interface, and the team can demonstrate how they survive ordinary change and exceptional operations.
