How should R2 credentials be restricted and stored securely?

How should R2 credentials be restricted and stored securely?

R2 credentials should grant only the storage access the application needs and remain available only to trusted server-side components. A wedding gallery does not need unrestricted account administration merely to upload, read, and delete its own photos.

Scope access to the application's storage

Create credentials for the appropriate bucket and required object permissions. Keep development and production credentials separate. R2's authentication guide describes available permission scopes.

If the application uses one bucket for many weddings, those credentials do not independently enforce each family's access rules. The backend must authorize the requested wedding and object before signing or performing an operation. Never let a browser-supplied bucket or key bypass that check.

Store secrets outside source and browser code

Use the hosting platform's protected environment settings or a suitable secret store. Local development values belong in ignored environment files, with safe placeholder names documented separately.

Keep secret keys out of frontend bundles, screenshots, error responses, and AI prompts. A presigned URL can grant a limited operation without exposing the signing secret, but that URL is still sensitive while valid. Configure logging to avoid recording its full signed query string.

Plan for replacement and verification

Document which service owns each credential, its purpose, and how to rotate it. When rotating, deploy or reload the relevant server configuration, verify required operations, and revoke the replaced credential through the provider's supported process.

If a secret was committed, removing it from the latest file does not undo exposure in repository history. Revoke and replace the credential, then address the repository incident appropriately. Finally, verify that normal gallery actions still work and that development credentials cannot access production photos. Restriction should be demonstrated by actual permissions, not inferred from a descriptive token name.