Safeguard
Security Guides•

How presigned URLs work and how to use them without leaking data

A presigned URL grants access to anyone holding it until it expires. Set short lifetimes, scope them narrowly and keep them out of logs. Rules inside.

Safeguard Security Team
3 min read

A presigned URL is a normal link with a signature in the query string that lets whoever holds it perform one specific action until it expires. It is a bearer token: no login happens, so treat it like a short-lived secret. Keep lifetimes short, scope to one object and method, and never log it.

How they work

Using Amazon S3 as the documented example: you supply credentials, a bucket, an object key, an HTTP method and an expiry. The service signs those values. Anyone with the link can then perform that method on that object without their own credentials. The link can be used repeatedly until it expires.

The permissions of the URL are those of the identity that created it. AWS documentation says the capabilities of a presigned URL are limited by the permissions of the creator, and describes URLs as bearer tokens that grant access to anyone who possesses them.

Expiry has layers

A URL stops working at its configured time or when the credentials that signed it end, whichever comes first. For temporary role credentials the link expires when the session does, even if you asked for longer. AWS also notes that expiry is checked at request time, so a download already in progress can finish while a restart after expiry fails.

Rules for safe use

  1. Make the lifetime as short as the user flow allows, minutes rather than days.
  2. Sign with a role that can do only the needed action on only the needed prefix.
  3. Do not put presigned URLs in logs, analytics events, error reports or referrer-leaking pages. Our post on what never to log applies.
  4. Generate them per request, after your own authorization check, rather than storing and reusing them.
  5. For uploads, remember an existing object with the same key can be replaced; choose unpredictable keys and validate the file afterwards.
  6. Use bucket policy conditions where the provider supports them, such as limiting signature age or network location.

Debugging mismatches

Common causes of signature errors, per the AWS FAQ: clock drift, proxies that change headers or query strings, and parameters that differ between creation and use. Fix those at the source and never respond by weakening the policy.

Quick check

Can I revoke one presigned URL?

Generally not individually. You can end the credentials that signed it, or change the permissions or policy, which affects all links from that source.

Is a presigned URL safe to email?

Anyone who gets the email can use it until expiry. Keep the lifetime short and consider whether an authenticated download page fits better.

Sources

Last reviewed: 19 October 2026.

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.