🔎 PHASE 1 — ARCHITECTURE INVENTORY Tenant request flow: User → JWT Authentication → workspaceId from URL → Membership Middleware → Controller → Service → Repository → PostgreSQL → Response Additional paths: User → API → Redis User → API → BullMQ → Worker → PostgreSQL User → API → Elasticsearch User → API → Object Storage User → WebSocket → Notification Service ⚠️ Tenant Context Loss Points 1. workspaceId originates from the request URL. 2. Repository filtering is partly manual. 3. Background jobs may rely on serialized workspaceId. 4. Elasticsearch filtering must be explicitly enforced. 5. Redis keys require consistent workspace namespacing. 6. Object-storage authorization cannot rely solely on application checks. 7. Admin/support tooling creates a privileged cross-tenant access path. --- 🏢 PHASE 2 — TENANT ISOLATION MODEL Layer| Assessment| Reason Application| 🟡 Moderate| Membership middleware exists Database| 🟠 Weak| Shared schema + no RLS API| 🟡 Moderate| Workspace authorization exists but depends on middleware Storage| 🟡 Moderate| Requires explicit object authorization Cache| 🟡 Moderate| Tenant-aware key discipline required Workers| 🟡 Moderate| Depends on propagated workspaceId Search| 🟠 Weak| Elasticsearch filters can be accidentally omitted Admin| 🟠 Weak| Broad support privileges Overall Isolation: 🟠 WEAK The architecture has tenant controls, but too many depend on application-level conventions. The biggest systemic concern is that a single missed workspace filter could expose another tenant's data. --- 🗄️ PHASE 3 — DATABASE AUDIT Finding: Manual tenant filtering Some repositories automatically apply: workspace_id = currentWorkspace But legacy raw SQL does not consistently enforce this. Risk A developer could write: SELECT * FROM projects WHERE id = ? without validating workspace ownership. An attacker who obtains another project's ID could potentially trigger an IDOR/BOLA vulnerability. Severity: 🔴 P0 Recommended Control Move toward defense-in-depth: Application authorization + Repository-level tenant enforcement + PostgreSQL Row-Level Security Example conceptual policy: User can access row IF row.workspace_id = authorized_workspace This prevents a missing application filter from automatically becoming a cross-tenant database disclosure. --- 🛡️ PHASE 4 — AUTHENTICATION & AUTHORIZATION Current Model JWT: user_id Request: workspaceId Authorization: user membership → workspace Main Concern The workspace identifier is client-controlled. This is acceptable only if the server independently verifies: user ∈ workspace for every security-sensitive operation. Required Rule Never treat: /workspaces/ABC as proof that the user belongs to workspace ABC. The server must derive or validate the authorized tenant context. Additional Risk Support admins have broad tenant access. This creates a high-impact internal compromise scenario. Recommended: - Separate support identity - Just-in-time access - Tenant-scoped permissions - Explicit reason for access - Audit trail - Automatic access expiration --- 🔍 PHASE 5 — DATA ACCESS AUDIT Current State Tenant filtering is: 🟡 Convention-based because individual repositories are responsible for adding workspace_id. High-Risk Paths - Raw SQL - Export endpoints - Reporting queries - Bulk task operations - Background workers - Elasticsearch queries - Admin tools Required Architecture Request → Authenticate User → Resolve Authorized Workspace → Create Immutable Tenant Context → Authorization Policy → Tenant-Aware Repository → Database RLS The developer should not be able to accidentally omit tenant isolation with a normal query. --- 🚨 PHASE 6 — CROSS-TENANT LEAKAGE ANALYSIS Path| Failure Scenario| Impact| Severity REST API| Change project ID| Another tenant's project returned| 🔴 P0 Elasticsearch| Missing workspace filter| Cross-tenant search results| 🔴 P0 Redis| Generic cache key| Cached data returned to wrong tenant| 🟠 P1 S3| Predictable object key| Unauthorized file access| 🔴 P0 Worker| Missing workspaceId| Wrong tenant processed| 🔴 P0 Export| Unscoped SQL query| Bulk data disclosure| 🔴 P0 WebSocket| Wrong channel subscription| Tenant notification leakage| 🟠 P1 Analytics| Shared dataset without tenant filter| Aggregated/customer data exposure| 🟡 P2 --- ⚡ PHASE 7 — API & SERVICE AUDIT Required API pattern Every request should establish: User Identity + Authorized Tenant Context + Resource Ownership before accessing tenant data. High-Risk Endpoints - GET /projects/{id} - PATCH /projects/{id} - DELETE /projects/{id} - POST /tasks/bulk - GET /reports - GET /exports - Search endpoints - Admin/support APIs Key Test Change a legitimate project ID from Tenant A to a project ID belonging to Tenant B. Expected: HTTP 403 or 404 Never: HTTP 200 with Tenant B data. --- 🧠 PHASE 8 — CACHE, QUEUE & WORKERS Redis Unsafe: project:{projectId} Safer: workspace:{workspaceId}:project:{projectId} Tenant identity should be part of the cache namespace. BullMQ Every job should contain: - workspace_id - initiating_user_id - resource_id - operation - authorization context/version The worker should validate the resource's workspace before processing. Retry Risk A retry must not reuse stale or incorrect tenant context. --- 📦 PHASE 9 — FILE & SEARCH AUDIT Object Storage Do not depend on: /workspaceA/file123 being secret. Authorization must occur before generating download access. Signed URLs should: - Be short-lived - Be generated only after authorization - Reference tenant-scoped objects - Be auditable Elasticsearch Every tenant query must enforce workspace filtering. Search security should be tested independently from PostgreSQL security. A secure database does not protect against an incorrectly scoped search index. --- 🧩 PHASE 10 — ADMIN & SUPPORT Current Risk Support users have broad access. Recommended Model Support Agent → Request Tenant Access → Business Justification → Approval/Policy Check → Temporary Tenant Scope → Audited Session → Automatic Expiration Avoid permanent unrestricted super-admin access. All sensitive actions should record: - Who - Tenant - Resource - Action - Reason - Timestamp - Result --- 📈 PHASE 11 — SCALABILITY The shared PostgreSQL model can work at 10,000 tenants, but large tenants may create noisy-neighbor problems. Potential pressure points: - Connection pools - Large workspace queries - Elasticsearch shards - Redis memory - Worker queues - Analytics ETL Recommended controls: - Per-tenant rate limits - Query timeouts - Pagination - Workload isolation - Queue prioritization - Large-tenant monitoring - Database indexing on workspace_id - Read replicas where appropriate Do not introduce database-per-tenant architecture prematurely. --- 🌍 PHASE 12 — BACKUP & RECOVERY The system should support: Tenant A restore without accidentally restoring or overwriting: Tenant B data. Required capability: - Tenant-aware backup metadata - Point-in-time recovery strategy - Isolated restore environment - Validation before production replacement - Tenant-level deletion verification --- 🧪 PHASE 13 — SECURITY TEST PLAN Test 1: Resource IDOR Input: - Authenticate as Tenant A user - Request Tenant B project ID Expected: - 403/404 - No Tenant B metadata returned Failure Signal: - HTTP 200 or any B-owned information Severity: - 🔴 P0 Test 2: Search Isolation Input: - Search for a unique Tenant B project name using Tenant A credentials Expected: - Zero Tenant B results Failure Signal: - Search result appears Severity: - 🔴 P0 Test 3: Cache Isolation Input: - Populate Tenant A cache - Request identical resource key as Tenant B Expected: - Tenant B receives only B data Failure Signal: - A's cached object returned Severity: - 🟠 P1 Test 4: Worker Isolation Input: - Submit a job for Tenant A - Manipulate serialized workspace_id Expected: - Worker rejects unauthorized resource Failure Signal: - Worker processes Tenant B resource Severity: - 🔴 P0 Test 5: Storage Isolation Input: - Tenant A attempts to download Tenant B object Expected: - Access denied Failure Signal: - File contents or valid download URL returned Severity: - 🔴 P0 --- 📊 PHASE 14 — RISK REGISTER Risk| Component| Impact| Likelihood| Severity| Evidence| Priority| Fix Missing tenant filter| Database| Data disclosure| High| Critical| Raw SQL exists| P0| RLS + centralized access IDOR/BOLA| API| Unauthorized resource access| High| Critical| Resource IDs exposed| P0| Ownership policy Search leakage| Elasticsearch| Cross-tenant search results| Medium/High| Critical| Explicit filters required| P0| Mandatory tenant filter Worker context loss| BullMQ| Wrong-tenant processing| Medium| Critical| Async context serialized| P0| Worker authorization Object leakage| Storage| File disclosure| Medium| Critical| App-level authorization| P0| Tenant-scoped access policy Cache collision| Redis| Data contamination| Medium| High| Shared cache| P1| Tenant-prefixed keys Broad support access| Admin| Internal data exposure| Medium| High| Broad permissions| P1| JIT least privilege Noisy neighbor| Infrastructure| Availability degradation| Medium| Medium| Large tenants| P2| Resource controls --- 🛠️ PHASE 15 — PRODUCTION HARDENING Immediate 1. Eliminate unscoped resource queries Current weakness: - Manual workspace filters Fix: - Centralized tenant-aware repositories - Automated query checks - PostgreSQL RLS Validation: - Cross-tenant integration test suite Rollback: - Enable RLS gradually by table after policy validation. 2. Secure search Current weakness: - Tenant filter can potentially be omitted. Fix: - Central search client that requires workspace context. Validation: - Automated Tenant A/B search tests. 3. Secure workers Current weakness: - Serialized tenant context may be trusted. Fix: - Worker independently validates workspace ownership. Validation: - Tampered-job tests. --- 📅 PRODUCTION HARDENING ROADMAP Immediate: 0-2 Weeks - Identify every tenant-owned table - Audit raw SQL - Audit resource-ID endpoints - Lock down search filters - Verify object authorization - Add cross-tenant security tests - Audit support permissions Short Term: 2-4 Weeks - Centralize tenant context - Standardize tenant-aware repositories - Namespace Redis keys - Harden workers - Implement tenant-aware audit logging Medium Term: 1-3 Months - Introduce PostgreSQL RLS - Improve large-tenant isolation - Add workload controls - Improve tenant-aware disaster recovery Long Term - Evaluate hybrid tenancy - Isolate exceptionally large tenants - Introduce stronger regional/data-residency controls - Automate continuous tenant-isolation testing --- 🏆 TARGET ARCHITECTURE Request → JWT Authentication → Authorized Tenant Resolution → Immutable Tenant Context → Central Authorization Policy → Tenant-Aware Service → Tenant-Aware Repository → PostgreSQL RLS → Tenant-Scoped Cache → Tenant-Scoped Queue → Tenant-Scoped Search → Tenant-Scoped Storage → Audited Response Every downstream component should either: 1. Receive trusted tenant context, or 2. Independently verify tenant authorization. The security model should never depend solely on developers remembering to add workspace_id. --- 🎯 FINAL VERDICT 🟠 HIGH-RISK The architecture has a reasonable foundation, but it is not yet production-ready for strong multi-tenant isolation. The primary issue is systemic: Tenant isolation is currently enforced mainly by application conventions rather than multiple independent security boundaries. The highest-priority improvements are: 1. PostgreSQL RLS 2. Centralized tenant authorization 3. IDOR/BOLA protection 4. Mandatory search filtering 5. Worker-level tenant validation 6. Tenant-scoped object storage authorization 7. Tenant-aware cache keys 8. Least-privilege support access 9. Automated cross-tenant isolation tests Target principle: TENANT A DATA ≠ TENANT B DATA must remain true even when an individual developer forgets a filter, a worker receives manipulated input, a cache key collides, or a service is incorrectly called.