File storage is segregated by tenant

Flat storage namespaces are a common AI-generated blind spot: code stores files as uploads/{uuid} with no tenant prefix, so any authenticated user who discovers a file key — via URL scraping, shared links, or support screenshots — can download another tenant's files. CWE-732 (Incorrect Permission Assignment for Critical Resource) and OWASP A01 both apply. Beyond privacy, tenant-to-tenant file exposure violates SOC 2 CC6.1 data classification requirements and, when files contain PII, triggers GDPR Art. 33 breach notifications.

Prefix every storage key with the tenant identifier at upload time, and validate ownership before generating a signed retrieval URL:

// S3 key generation — always include tenant prefix
const key = `tenants/${session.user.organizationId}/uploads/${crypto.randomUUID()}-${filename}`

// Retrieval — verify ownership before signing
const fileRecord = await db.files.findFirst({
  where: { id: fileId, organizationId: session.user.organizationId }
})
if (!fileRecord) return new Response('Not found', { status: 404 })
const signedUrl = await s3.getSignedUrl('getObject', { Bucket, Key: fileRecord.s3Key, Expires: 300 })

For Supabase Storage, write a bucket RLS policy that checks auth.jwt()->>'org_id' = storage.foldername(name)[1] so the storage engine itself enforces isolation without relying on application code.