How are my Amazon S3 credentials protected?

Save AWS secrets as Template Credentials and reference their name in your Template. This keeps the secret values out of the Assembly Instructions sent by your browser. Do not put AWS secrets or your Transloadit Auth Secret in browser code, hidden form fields or public repositories.

Saving credentials does not authorize an upload. Authenticate users and authorize each upload on your trusted backend before creating an Assembly or issuing its params. Make Signature Authentication mandatory for signed browser flows, and issue only instructions the user is allowed to run. When using saved Templates, set allow_steps_override: false to constrain their steps; this setting alone does not authorize use of the Template. Do not use client-controlled fields to select credential names or authorization-sensitive storage destinations. Ordinary field interpolation remains useful for non-authoritative metadata. See verifying an upload’s user.

The Template Credentials API encrypts credential content before storing new credentials or content updates in the database. Transloadit decrypts credentials when needed for processing, and authorized credential-management API requests can retrieve their values. Encryption at rest does not prevent every form of account or running-service compromise.

Use a dedicated AWS identity limited to the bucket and object prefix you need, following the canonical /s3/store permission policy. Grant read, tagging, ACL or KMS permissions only when your configuration needs them. Write permission can overwrite existing object keys; it does not provide add-only access.

Restrict who can manage your Workspace and credentials. Rotate AWS access keys and update the saved Template Credential as part of your key-management process; revoke suspected compromised credentials promptly. Consider unique object paths and S3 versioning to help recover from unwanted overwrites.