In this blog, we will discuss, what is tenant isolation in a SaaS platform, why does tenant isolation matter during a cert-in security audit, how can weak tenant isolation create security risks, how should tenant isolation be tested during a cert-in audit, how can SaaS architecture change the audit scope, what tenant isolation risks should be checked in SaaS APIs.
We will also focus on explaining how should tenant-level authentication and authorization be assessed, how can shared SaaS components affect tenant isolation, what evidence should be collected for tenant isolation testing, how can new SaaS features affect tenant isolation, how should tenant isolation findings be prioritized and finally how can SaaS providers address tenant isolation findings.
What Is Tenant Isolation in a SaaS Platform?
Tenant isolation means keeping each customer’s data, users, and permissions separate within a SaaS platform. Even when customers share the same application or infrastructure, one tenant should not access another tenant’s information without authorization. OWASP identifies tenant separation as an important part of multi-tenant application security.
1. Tenant Separation in Shared Applications
A shared SaaS application may serve many customers through the same codebase. Access controls must ensure that each tenant can use only its own data and permitted features.
2. Tenant-Specific User Accounts
Each tenant has its own users and account details. The application must verify that users can access only the tenant accounts they are authorized to use.
3. Tenant-Level Data Storage
Tenant data may be stored in shared databases or separate databases. In either design, access rules must prevent one tenant from reading or changing another tenant’s records.
4. Tenant-Specific Roles and Permissions
Tenants may have different roles, such as owner, administrator, and standard user. The application must apply permissions within the correct tenant and prevent users from gaining unauthorized access.
5. Shared Infrastructure Across Tenants
SaaS platforms may share servers, storage, caches, and background services across customers. These components must handle tenant data separately to prevent accidental exposure between tenants.
Why Does Tenant Isolation Matter During a CERT-In Security Audit?
Tenant isolation affects which application functions, data stores, APIs, and shared services need to be examined. CERT-In’s comprehensive audit guidance covers audit scope and assessment of applications and supporting infrastructure, making it important to define the systems included in an audit.
1. Preventing Cross-Tenant Data Access
The audit should check whether a user from one tenant can view or change another tenant’s data. Such access may indicate a failure in authorization or tenant separation.
2. Separating Tenant Permissions
Auditors should verify that permissions apply to the correct tenant. A user with access to one customer’s account should not automatically receive access to other customers’ accounts.
3. Protecting Shared Application Resources
Shared databases, storage, and caches can create risks if tenant boundaries are not correctly applied. The assessment should check how these resources separate customer information.
4. Checking Tenant-Level Access Controls
Tenant restrictions must be enforced by the server, not just by the user interface. Testing should confirm that direct requests cannot bypass tenant-level permissions.
5. Identifying Risks in Shared Services
Common authentication systems, reporting tools, and background services may process data for multiple tenants. These services should be included in the assessment when they fall within the agreed audit scope.
How Can Weak Tenant Isolation Create Security Risks?
Weak tenant isolation can allow one customer to access information or functions belonging to another. The cause may be a missing authorization check, an incorrect tenant reference, or a flaw in a shared service.
1. Unauthorized Access to Another Tenant’s Data
An authorization flaw may allow a user to retrieve records owned by another tenant. This can expose customer details, business documents, or account information.
2. Cross-Tenant Privilege Escalation
A user may gain access to another tenant’s administrative functions if role checks do not consider tenant boundaries. This can allow unauthorized changes to users, settings, or permissions.
3. Exposure of Tenant Records
Incorrect database queries or access rules may return records from several tenants in one response. The application must filter results according to the user’s authorized tenant.
4. Access to Another Tenant’s Files
File storage systems may expose documents if access checks rely only on file names or identifiers. Each file request should verify the user’s permission to access that tenant’s file.
5. Misuse of Shared Application Functions
Shared functions, such as exports or account settings, may process requests for multiple customers. Missing tenant checks can allow users to affect data or settings outside their own account.
6. Cross-Tenant API Access
An API may accept a tenant identifier supplied by the user without verifying access rights. This can allow unauthorized requests for another tenant’s data or functions.
7. Exposure Through Shared Resources
Caches, reporting services, and background jobs may handle information from several tenants. Incorrect data separation can cause one tenant’s information to appear in another tenant’s results.
How Should Tenant Isolation Be Tested During a CERT-In Audit?
Testing should use authorized test accounts from different tenants and check whether access remains limited to the correct customer. The results should document the tested functions, observed behavior, and any confirmed access control failures.
1. Testing Access Between Tenant Accounts
Create test accounts for separate tenants and check whether one account can access another tenant’s protected resources. Testing should remain within the approved scope.
2. Checking Tenant ID Validation
Change tenant identifiers in approved test requests to check whether the server verifies the user’s access. The application should reject requests for tenants the user is not permitted to access.
3. Testing Object-Level Authorization
Check whether the application verifies access to each requested record, file, or other object. Knowing or guessing an object’s identifier should not grant permission to view or modify it.
4. Reviewing Tenant-Specific Roles
Test the permissions assigned to different roles within each tenant. A standard user should not be able to perform administrative actions unless explicitly authorized.
5. Testing API Access Between Tenants
Send approved test requests using accounts from different tenants. Verify that API responses and actions remain limited to the requesting user’s authorized tenant.
6. Checking File and Document Access
Test whether files can be accessed through direct links or requests using another tenant’s file identifier. The server should verify access permissions before returning the file.
7. Testing Tenant Data Separation
Review whether database queries, exports, search results, and reports include only authorized tenant data. Confirm that data separation is applied consistently across application functions.
How Can SaaS Architecture Change the Audit Scope?
The SaaS design determines where tenant boundaries are enforced and which components require testing. The audit scope should account for the application’s architecture and supporting services included in the engagement, rather than examining only the customer-facing pages.
1. Shared Application Environments
When tenants use the same application environment, the assessment should examine how requests are linked to the correct tenant. Shared code must enforce tenant restrictions consistently.
2. Shared Databases
A shared database may store records for many tenants. The audit should check queries, database permissions, and row-level restrictions that prevent cross-tenant access.
3. Separate Databases for Each Tenant
Separate databases can reduce some forms of data exposure, but they do not remove every risk. Database selection, connection settings, and application permissions should be checked to ensure requests reach the correct tenant’s data.
4. Shared API Services
Common APIs may handle requests for multiple tenants. Testing should verify tenant authorization on each relevant endpoint and ensure that responses do not contain another customer’s data.
5. Common Authentication Services
A shared login service may authenticate users from many tenants. The assessment should check how tenant identity is established and whether users can switch accounts only when authorized.
6. Shared Cloud Infrastructure
SaaS platforms may use common cloud resources for computing, storage, and networking. Where these resources are included in scope, the audit should review access permissions and separation between tenant workloads.
7. Tenant-Specific Components
Some platforms use separate services or configurations for individual tenants. The assessment should verify that these components have the correct access rules and cannot be reached through another tenant’s account.
What Tenant Isolation Risks Should Be Checked in SaaS APIs?
SaaS APIs often provide access to customer records, account settings, files, and administrative functions. OWASP highlights broken object-level authorization and related access control failures as important API security risks.
1. Missing Tenant Authorization Checks
An API may authenticate a user but fail to verify which tenant’s resources they can access. Each request must enforce the required tenant permissions.
2. Tenant ID Manipulation
A user may change a tenant identifier in a request. The API must confirm that the authenticated user is authorized to access the specified tenant.
3. Broken Object-Level Authorization
An API may return a record based only on its identifier. The server must also check whether the requested object belongs to a tenant the user can access.
4. Cross-Tenant Data Returned by APIs
Search, reporting, and listing endpoints may return records from multiple tenants if filters are missing or incorrectly applied. Test responses to confirm that only permitted data is returned.
5. Tenant Access Through Background Jobs
Background jobs may process exports, reports, notifications, or scheduled tasks for several tenants. The audit should check whether each job retains and applies the correct tenant context.
6. Excessive API Permissions
An API account may have more access than its assigned task requires. Review permissions to ensure that services and users cannot perform unauthorized actions across tenants.
7. Missing Tenant Context Validation
An API may process a request without confirming which tenant it belongs to. The service should establish tenant context from trusted authentication and authorization controls before accessing data.
How Should Tenant-Level Authentication and Authorization Be Assessed?
Authentication confirms a user’s identity, while authorization determines which tenant resources and functions that user may access. The assessment should check both controls because a valid login alone does not prove that access is limited to the correct tenant.
1. Tenant User Login
Check whether the login process correctly associates users with their authorized tenant accounts. Users should not gain access to another tenant simply by changing account details in a request.
2. Tenant Switching Permissions
Some SaaS platforms allow users to belong to multiple tenants. Verify that switching between accounts is permitted only for tenants linked to that user.
3. Role-Based Access Within Each Tenant
Check whether roles are applied separately within each tenant. Permissions granted in one tenant should not automatically apply to another.
4. Administrator Access Across Tenants
Some platform administrators may require access across several tenants. Verify that this access is explicitly authorized, limited to assigned duties, and appropriately monitored.
5. Session Handling Between Tenants
Check whether sessions maintain the correct tenant context when users switch accounts or sign in again. Session handling should not expose one tenant’s resources after a change of account.
6. Tenant-Specific API Permissions
Verify that API tokens and service accounts have access only to the tenants and functions they require. A token for one tenant should not grant unintended access to another.
7. Privileged Account Access
Review privileged accounts that can manage tenant settings, users, or data. Confirm that their permissions are appropriate and that sensitive administrative actions are restricted.
How Can Shared SaaS Components Affect Tenant Isolation?
Shared components can process requests and data for many customers, so a single access control error may affect more than one tenant. OWASP recommends considering tenant boundaries across application logic, databases, caches, storage, and other shared layers.
1. Shared Authentication Services
A common authentication service manages login for several tenants. Incorrect tenant mapping or account handling may allow users to enter the wrong tenant context.
2. Common Application Libraries
Shared libraries may handle tenant identification, permissions, or data access. The assessment should check whether these functions apply tenant restrictions consistently wherever they are used.
3. Shared File Storage
Shared storage may contain documents belonging to different tenants. File access should be checked against tenant permissions rather than relying only on file paths or identifiers.
4. Background Processing Services
Background services may process scheduled tasks for many customers. Each task should retain the correct tenant identity and avoid using another tenant’s data.
5. Shared Caching Systems
A cache may store data from multiple tenants to improve response times. Cache keys and access checks must prevent one tenant from receiving another tenant’s cached information.
6. Common Reporting Functions
Reporting services may combine information from several application modules. Reports and exports should include only the data the requesting tenant is authorized to view.
7. Shared Administrative Tools
Administrative tools may provide access to several tenant accounts or platform settings. Access should be limited to approved staff, with permissions and administrative activity reviewed as part of the assessment.
What Evidence Should Be Collected for Tenant Isolation Testing?
During a CERT-In security audit, evidence should show how tenant boundaries are designed, tested, and maintained. Clear records help auditors understand the controls in place and verify whether identified issues have been addressed.
1. SaaS Architecture Diagrams
Architecture diagrams should show how the application, databases, APIs, and shared services connect. They help auditors identify where tenant separation is applied and which components need testing.
2. Tenant Data Flow Diagrams
Data flow diagrams should show how tenant information moves between application components and external services. They help identify points where data could cross tenant boundaries without proper authorization.
3. Tenant Role and Permission Details
Role and permission records should explain what each tenant user can access and manage. These details help auditors check whether permissions are limited to the correct tenant.
4. API Access Control Rules
API access control records should describe how tenant identity and permissions are checked for requests. Auditors can compare these rules with test results to identify missing authorization checks.
5. Database Separation Details
Database documentation should explain whether tenants use shared tables, separate schemas, or separate databases. It should also show how queries and database permissions prevent unauthorized access between tenants.
6. Tenant Isolation Test Results
Test results should record the scenarios tested, expected behavior, observed results, and any failures. Evidence should demonstrate whether users from one tenant can access another tenant’s protected resources.
7. Findings and Remediation Records
Audit records should describe identified weaknesses, their severity, and the actions taken to fix them. Retest results should confirm whether the changes have corrected the reported tenant isolation issues.
How Can New SaaS Features Affect Tenant Isolation?
New SaaS features can change how tenant data is stored, accessed, and processed. Each significant change should be reviewed to determine whether existing tenant isolation controls still work as intended.
1. Adding New Tenant Roles
New roles may introduce permissions that were not covered by earlier tests. Access checks should confirm that each role remains limited to its assigned tenant and functions.
2. Introducing New APIs
New APIs may create additional ways to access tenant data or perform actions. They should be tested for tenant authorization and object-level access control.
3. Changing Database Structures
Changes to tables, schemas, or database queries may affect how tenant records are separated. Testing should confirm that updated data access logic does not expose records across tenants.
4. Adding File-Sharing Features
File-sharing features may allow users to upload, download, or share documents. Access checks should prevent files from being shared with users who are not authorized to view them.
5. Updating Shared Services
Changes to authentication, caching, or background services may affect multiple tenants. The updated components should be tested to ensure they preserve tenant separation.
6. Changing Tenant Permissions
Changes to roles or permissions may grant users access to additional functions or records. These changes should be reviewed to prevent unintended access across tenant boundaries.
7. Introducing New Integrations
New third-party integrations may receive or process tenant information. The assessment should check what data is shared, how access is controlled, and whether tenant boundaries remain intact.
How Should Tenant Isolation Findings Be Prioritized?
Tenant isolation findings should be prioritized according to the data exposed, the access gained, the number of tenants affected, and the ease of exploiting the weakness. Issues that allow access to another tenant’s sensitive information or administrative functions generally require urgent attention.
1. Cross-Tenant Data Exposure
Findings that allow one tenant to access another tenant’s sensitive data should receive high priority. The impact depends on the type and amount of information exposed and the number of customers affected.
2. Unauthorized Administrative Access
Unauthorized access to another tenant’s administrative functions can allow changes to users, settings, or permissions. Such findings need prompt review because they may affect a tenant’s account and data.
3. Cross-Tenant API Access
API flaws that expose another tenant’s records or functions should be assessed based on the access they permit. Endpoints that provide access to sensitive information or privileged actions may require urgent fixes.
4. Tenant Permission Bypass
A permission bypass may allow users to perform actions outside their assigned role or tenant. Priority should reflect the functions available and the level of access gained.
5. Shared Resource Exposure
Exposure through shared storage, caches, or background services may affect multiple tenants. Auditors should consider the scope of the exposure and whether sensitive data can be accessed without authorization.
6. Tenant Session Separation Issues
Session handling flaws may allow users to access the wrong tenant’s account or resources. Priority depends on whether the issue permits unauthorized account access or exposes protected information.
7. Repeated Isolation Failures
Similar failures across multiple endpoints may indicate a wider problem with tenant authorization. These findings should be reviewed across the application rather than treated only as separate issues.
How Can SaaS Providers Address Tenant Isolation Findings?
SaaS providers should correct identified weaknesses, verify the changes through testing, and maintain evidence of the results. Fixes should cover the affected functions and any shared components that may have the same issue.
1. Enforcing Server-Side Tenant Checks
The server should verify tenant access on every relevant request. It should not rely only on tenant identifiers or restrictions applied in the user interface.
2. Applying Tenant-Level Authorization
Authorization rules should confirm that users can access only the records and functions permitted for their tenant. These checks should apply to web requests, APIs, and background operations.
3. Restricting Cross-Tenant Data Access
Database queries, file requests, reports, and exports should return only authorized tenant data. Providers should review common data access functions to identify similar weaknesses.
4. Reviewing Shared Resource Permissions
Access to shared storage, caches, and services should be checked and limited to approved operations. Tenant-specific data should remain separated throughout processing and storage.
5. Securing Administrative Functions
Administrative actions should require suitable authentication and authorization. Access to functions that manage tenant users, settings, or data should be limited to approved accounts.
6. Retesting Fixed Tenant Isolation Issues
After a fix, the affected scenarios should be tested again using authorized test accounts. Retesting should confirm that the original issue is resolved and that the change has not introduced another access problem.
7. Updating Audit Evidence
Providers should update architecture diagrams, permission records, test results, and remediation details when controls change. Keeping these records current helps auditors understand the tested environment and verify the status of findings.
Conclusion
Tenant isolation is a key security consideration for SaaS platforms because multiple customers may share application components and infrastructure. A weakness in tenant access controls can expose customer data or allow unauthorized actions across accounts.
During a CERT-In security audit, the assessment scope should account for tenant-specific permissions, APIs, databases, shared services, and administrative functions included in the engagement. Testing these areas, recording evidence, prioritizing findings, and retesting fixes helps providers demonstrate whether tenant boundaries are working as intended.
Peneto Labs has been empanelled by CERT-In to perform information security services. For more cybersecurity insights, security audit guides, and practical tips, visit Peneto Labs to explore our latest blogs and stay informed about application security and emerging threats.