Security: Remove NEXT_PUBLIC_ prefix from Cloudflare R2 credentials

[coderabbitai]

Problem

Cloudflare R2 credentials (ACCOUNT_ID, ACCESS_KEY_ID, SECRET_ACCESS_KEY) are currently using the NEXT_PUBLIC_ prefix in environment variables, which exposes these sensitive secrets to the browser bundle.

While r2Client.ts is intended for server-side use only, it gets included in the client bundle because:

1. Frontend code (src/async/mutationHooks/files/useFileUploadOptimisticMutation.ts) imports storageClient.ts
2. storageClient.ts imports r2Helpers from r2Client.ts
3. Module-level code in r2Client.ts reads NEXT_PUBLIC_ prefixed environment variables

This means the credentials are exposed in the browser, which is a critical security vulnerability.

Proposed Solution

1. Move signed URL generation to API routes: Frontend should not generate signed URLs directly. Instead, it should call API routes that handle this server-side.
2. Rename environment variables to remove NEXT_PUBLIC_ prefix:
   • NEXT_PUBLIC_CLOUDFLARE_ACCOUNT_ID → CLOUDFLARE_ACCOUNT_ID
   • NEXT_PUBLIC_CLOUDFLARE_ACCESS_KEY_ID → CLOUDFLARE_ACCESS_KEY_ID
   • NEXT_PUBLIC_CLOUDFLARE_SECRET_ACCESS_KEY → CLOUDFLARE_SECRET_ACCESS_KEY
   • Keep NEXT_PUBLIC_CLOUDFLARE_PUBLIC_BUCKET_URL as is (safe to expose)
3. Refactor storage abstraction: Ensure storageClient.ts frontend exports don't import r2Client.ts directly
4. Update all API routes to handle R2 operations server-side only

Files to Update

• src/utils/r2Client.ts - Remove NEXT_PUBLIC_ prefix from credential env vars
• src/utils/storageClient.ts - Ensure frontend-safe exports that don't bundle R2 credentials
• src/async/mutationHooks/files/useFileUploadOptimisticMutation.ts - Call API route instead of direct storage operations
• Environment variable configuration files
• Server-side type definitions

Related

• PR: feat(storage): ✨ add local Supabase storage support for development #695 (introduced storage abstraction layer)
• Comment: feat(storage): ✨ add local Supabase storage support for development #695 (comment)

Reported by: @navin-moorthy
Assignee: @navin-moorthy

[linear]

REC-84