Summary
Shaiwz data-platform contains an insecure direct object reference that allows authenticated workspace members to access datasource records belonging to other workspaces. By supplying datasource identifiers outside their authorized workspace, an attacker may retrieve JDBC credentials, enumerate schemas, or modify and delete datasources.
Shaiwz data-platform contains an insecure direct object reference that allows authenticated workspace members to access datasource records belonging to other workspaces. By supplying datasource identifiers outside their authorized workspace, an attacker may retrieve JDBC credentials, enumerate schemas, or modify and delete datasources.
Affected context
The issue occurs in datasource management endpoints that authorize requests based on a numeric datasource identifier without consistently verifying that the referenced datasource belongs to the authenticated user's workspace. Affected operations include datasource detail retrieval, schema and table enumeration, updating, and deletion. Risk depends on the caller having an authenticated workspace account and access to these management functions.
The issue occurs in datasource management endpoints that authorize requests based on a numeric datasource identifier without consistently verifying that the referenced datasource belongs to the authenticated user's workspace. Affected operations include datasource detail retrieval, schema and table enumeration, updating, and deletion. Risk depends on the caller having an authenticated workspace account and access to these management functions.
Exploit preconditions
- Attack surface: Authenticated datasource management API endpoints
- Required access: Membership in at least one workspace with permission to use datasource functions
- Trigger point: Requests that accept a datasource identifier for detail, schema, table, update, or delete operations
- Why exploitation is possible: Object-level authorization does not reliably bind the requested datasource to the caller's authorized workspace
- Attack surface: Authenticated datasource management API endpoints
- Required access: Membership in at least one workspace with permission to use datasource functions
- Trigger point: Requests that accept a datasource identifier for detail, schema, table, update, or delete operations
- Why exploitation is possible: Object-level authorization does not reliably bind the requested datasource to the caller's authorized workspace
Why this happens
The vulnerability results from trusting a client-controlled numeric object identifier without enforcing ownership or tenant authorization at the object-access layer. This is an insecure direct object reference pattern mapped to CWE-639: Authorization Bypass Through User-Controlled Key. The application appears to resolve datasource records by identifier, but does not consistently verify that the resolved record belongs to the requesting user's workspace before returning or changing it.
The vulnerability results from trusting a client-controlled numeric object identifier without enforcing ownership or tenant authorization at the object-access layer. This is an insecure direct object reference pattern mapped to CWE-639: Authorization Bypass Through User-Controlled Key. The application appears to resolve datasource records by identifier, but does not consistently verify that the resolved record belongs to the requesting user's workspace before returning or changing it.
Potential impact
- Attackers may access datasource metadata belonging to other workspaces
- JDBC credentials or connection details could be disclosed
- Database schemas and table information may be enumerated
- Unauthorized users could modify datasource configuration
- Datasources could be deleted, causing service disruption or data-access failures
- Cross-workspace compromise could support follow-on attacks against connected databases
- Attackers may access datasource metadata belonging to other workspaces
- JDBC credentials or connection details could be disclosed
- Database schemas and table information may be enumerated
- Unauthorized users could modify datasource configuration
- Datasources could be deleted, causing service disruption or data-access failures
- Cross-workspace compromise could support follow-on attacks against connected databases
General mitigation guidance
Mitigation generally focuses on enforcing object-level authorization at every datasource operation and reducing reliance on client-supplied identifiers.
Common defensive patterns include:
- Verify workspace ownership or authorization in the same server-side transaction that loads each datasource
- Apply consistent tenant-scoped queries for reads, updates, and deletes
- Derive workspace context from the authenticated session rather than trusting request parameters
- Use deny-by-default authorization policies and least-privilege workspace roles
- Avoid exposing sensitive connection credentials unless strictly required, and protect them with secrets-management controls
- Return uniform authorization failures that do not reveal whether foreign identifiers exist
- Add authorization checks to shared service and repository layers so endpoint-specific omissions are less likely
Mitigation generally focuses on enforcing object-level authorization at every datasource operation and reducing reliance on client-supplied identifiers.
Common defensive patterns include:
- Verify workspace ownership or authorization in the same server-side transaction that loads each datasource
- Apply consistent tenant-scoped queries for reads, updates, and deletes
- Derive workspace context from the authenticated session rather than trusting request parameters
- Use deny-by-default authorization policies and least-privilege workspace roles
- Avoid exposing sensitive connection credentials unless strictly required, and protect them with secrets-management controls
- Return uniform authorization failures that do not reveal whether foreign identifiers exist
- Add authorization checks to shared service and repository layers so endpoint-specific omissions are less likely
How teams detect issues like this
Organizations can detect this class of issue through:
- Static analysis and code review for database queries that use client-provided IDs without tenant or ownership predicates
- Review of every detail, update, and delete handler for consistent object-level authorization
- Tests that use identities from separate workspaces and verify cross-tenant access is denied
- API gateway or policy enforcement requiring workspace scope for datasource operations
- Audit logging for denied cross-workspace object access and unusual sequential identifier access patterns
- Automated security review tools that flag missing authorization checks around resource identifiers
Organizations can detect this class of issue through:
- Static analysis and code review for database queries that use client-provided IDs without tenant or ownership predicates
- Review of every detail, update, and delete handler for consistent object-level authorization
- Tests that use identities from separate workspaces and verify cross-tenant access is denied
- API gateway or policy enforcement requiring workspace scope for datasource operations
- Audit logging for denied cross-workspace object access and unusual sequential identifier access patterns
- Automated security review tools that flag missing authorization checks around resource identifiers
