Object storage
S3 presigned URLs explained: temporary access without sharing keys
An S3 presigned URL is a time-limited signed request that lets another client perform a specific storage operation without receiving the application’s permanent access key. Treat the URL itself as temporary sensitive data: possession can be enough to use the delegated request while it remains valid.
The application signs, the recipient executes
A trusted application uses its S3 credential to calculate a signature for a particular HTTP method, bucket, object key and expiry. The recipient then sends that signed request directly to the object endpoint.
The recipient does not learn the permanent secret key. The storage service validates the signature and time window when the URL is used.
Presigned access inherits the signer scope
The signing identity must already be allowed to perform the requested action. A presigned URL cannot legitimately grant more authority than the credential that produced it.
Keep the signing user scoped to the application’s bucket. Otherwise a bug in key selection can create signed access to data the application should never have reached.
Expiry is a security control, not a one-time-use switch
Do not assume a presigned URL becomes invalid after its first successful request. Amazon S3 documents that the same presigned URL can be used multiple times until it expires; other S3-compatible services should be tested rather than assumed to have identical reuse behavior. Choose an expiry that matches the transfer window and treat a leaked URL as usable for that window.
The advertised expiry is also not always the only validity limit. On Amazon S3, temporary signing credentials can expire before the URL’s requested expiry, and policy controls can impose a shorter allowed signature age. Immediate revocation can require changing the underlying permission or credential. Test the exact provider and credential type before promising cancellation behavior.
Uploads need validation around the URL
A presigned PUT can allow a browser or client to upload without proxying the entire file through the application server. The application should still control object naming, size expectations, content handling and later processing. If the signed request includes headers such as Content-Type or a checksum, the uploader must send the matching signed values.
Do not trust a client-supplied filename as a safe storage key or executable content type. Object storage authorization and application input validation solve different problems. When integrity matters, test the checksum mechanism supported by the exact S3-compatible service and SDK instead of assuming every AWS checksum option exists.
Test clock, method and endpoint behavior
Presigned requests depend on time and on the exact endpoint/signing inputs. Test expiry, wrong method, altered key and an intentionally expired URL as negative cases.
Compatibility testing should use the SDK that will generate production URLs because subtle differences in endpoint or addressing style can invalidate otherwise correct signatures.