Treat Signed URLs as Bearer Capabilities

A signed URL can make private content easy to share. Instead of requiring the recipient to authenticate to the storage service, an application creates a URL containing enough authorization information for the service to accept a specific request.

That convenience changes the security model. Anyone who obtains a usable copy of the URL may be able to exercise the authority it carries. If the URL permits too much, remains valid too long, or is exposed through logs and messages, a small disclosure can become unintended access.

The useful mental model is simple: treat a signed URL as a temporary bearer capability, not as an ordinary link. A bearer capability grants authority to whoever possesses it, within the limits encoded or enforced by the system.

This article explains how to choose those limits, what signing actually protects, how to validate requests, and when signed URLs need complementary controls.

Start with the authority carried by the URL

Imagine an application that stores a private report. A user asks to download it, and the application returns a signed URL:

user -> application -> signed download URL
                         |
                         v
                    object service

The object service does not need the user’s application session when the URL is used. It decides whether to serve the report from the authorization information associated with the URL.

This creates a new trust boundary. Before the URL is issued, the application decides whether the user may receive access. After issuance, possession of the URL may be enough to perform the allowed request.

That means the security question is not only:

May this user download the report now?

It is also:

What authority am I creating, and how long should possession of it remain useful?

The second question is easy to miss because a signed URL looks like a string. Operationally, however, it behaves more like a temporary credential.

Understand what the signature does

A signature or message authentication code can let the receiving service detect unauthorized changes to protected URL fields. The exact construction depends on the platform, but the general idea is:

protected request data + secret signing material -> authenticator

The receiver reconstructs the protected data, verifies the authenticator, and accepts the request only when verification succeeds and the other authorization conditions are satisfied.

Suppose a simplified design protects these fields:

resource = reports/quarterly.pdf
action   = download
expires  = 2026-09-07T15:30:00Z

If those fields are covered by the authenticator, changing resource to another object or extending expires should make verification fail.

This gives an important guarantee under the cryptographic assumptions of the signing scheme: a party without the signing key cannot freely alter protected fields while keeping a valid authenticator.

It does not make the URL confidential. The resource name, expiry time, and other URL components may still be readable. More importantly, copying the complete valid URL may copy its authority as well.

Signing therefore addresses tampering. It does not by itself address disclosure or replay.

Give the URL the smallest useful authority

A signed URL should authorize the narrowest operation that satisfies the use case. Think in three dimensions:

resource x action x lifetime

For a download link, that might mean one object, a read operation, and a short validity period. For an upload link, it might mean one destination object and an upload operation rather than broad write access to a container.

This matters because each dimension limits the damage if the URL is copied.

Consider two designs:

A: may read any object under /reports for 24 hours
B: may read /reports/quarterly.pdf for 10 minutes

If the application needs only a single immediate download, design B exposes less authority. A copied URL still creates risk, but the recipient can use it for fewer things and for less time.

Do not widen the capability merely because the underlying storage API makes broad permissions convenient. The application should translate the user’s authorized action into a capability that is no broader than necessary.

Authorize before issuing the capability

A valid signature proves that a trusted signer created the URL. It does not prove that the signer made the correct authorization decision.

The application therefore needs to check access before creating the signed URL.

A simplified flow is:

request signed URL
      |
      v
identify current principal
      |
      v
authorize principal for resource and action
      |
      +-- denied --> do not issue URL
      |
      v
create narrowly scoped, short-lived URL

The authorization check should use trusted server-side facts. A client-provided object identifier can select the requested resource, but it must not decide whether the caller owns that resource or may access it.

This is especially important when signed URLs are generated by a privileged backend. The backend may have authority to sign access to many objects. If it signs whichever object name a caller supplies without checking ownership or policy, the signing service becomes an authorization bypass.

The signature would still be cryptographically valid. The security failure happened earlier, when excessive authority was issued.

Bind every security-relevant field that can change the request

The receiving service must know exactly which request properties are part of the authorization decision. If a property can change what resource is accessed or what operation occurs, leaving it outside the protected request can create ambiguity.

At minimum, designs commonly need to reason about the resource, permitted operation, and expiry. Depending on the protocol or storage service, other request properties may also be security-relevant.

The rule is not to invent a custom list and custom signing algorithm. Prefer the platform’s supported signed-URL mechanism and follow its documented canonicalization and verification rules. Small differences in path encoding, query parsing, header handling, or string normalization can make home-grown schemes inconsistent or unsafe.

The reusable principle is broader than any vendor API: the verifier and signer must agree on the exact request being authorized.

If the signer believes it authorized one object while the verifier interprets the request as another, a correct cryptographic primitive cannot repair the semantic mismatch.

Choose lifetime from the real workflow

Expiration limits how long a copied capability remains useful. It should be based on how long the legitimate operation reasonably needs, not on a generic value used for every link.

A user clicking an immediate download link may need only a short window. A large upload over an unreliable connection may need longer. An automated workflow may have its own queueing and retry delays.

The trade-off is direct:

longer lifetime -> more tolerance for delay and retries
                -> longer exposure after disclosure

A short lifetime is not automatically correct if it makes legitimate operations fail repeatedly. Repeated failures can lead teams to compensate with very long expirations or unsafe bypasses.

Measure the workflow, include reasonable clock and network behavior supported by the platform, and choose the shortest lifetime that reliably supports the intended operation.

Also understand what expiration means for the specific service. Some systems evaluate expiry when a request begins; behavior for transfers that continue past the expiry time is platform-specific. Do not assume a universal rule when designing long-running uploads or downloads.

Plan for replay and revocation

A bearer URL can often be used more than once while it remains valid. A signature does not inherently make a request one-time.

If repeated use is acceptable, a short lifetime and narrow scope may be sufficient. For example, allowing a user to retry a download for several minutes may be desirable.

If the business rule requires exactly one successful use, the system needs additional state. Conceptually:

capability identifier -> unused
first accepted use     -> consumed
later use              -> rejected

The transition must be enforced atomically so concurrent requests cannot both observe the capability as unused and succeed. This turns a stateless signed URL into a stateful one-time authorization design.

Revocation has a similar trade-off. Purely self-contained capabilities are attractive because the verifier may not need a database lookup. But if a URL must be revoked before expiry, the system needs some revocation mechanism: for example, server-side state, a version or generation check, or a platform feature that invalidates the credentials from which the URL derives.

The right choice depends on the threat model. For low-impact, very short-lived downloads, waiting for expiry may be acceptable. For highly sensitive data or long-lived capabilities, explicit revocation may justify the extra state and operational complexity.

Keep signed URLs out of unnecessary records

Because possession can grant access, avoid spreading complete signed URLs into systems that do not need them.

URLs can appear in application logs, proxy logs, analytics systems, support tickets, chat messages, browser history, monitoring traces, and copied command output. Which of these paths applies depends on the application and client, but the defensive principle is stable: do not treat the query string as harmless metadata when it contains authorization material.

Log a non-secret capability identifier, resource identifier, issuance event, expiry, and outcome when those fields help operations. Avoid logging the complete bearer URL or its authenticator.

For the same reason, do not place additional sensitive application data in the URL merely because the URL is signed. Signing protects integrity, not secrecy.

Transport the URL over authenticated TLS so network intermediaries outside the trusted TLS path cannot simply read it in transit. TLS still does not protect a URL after an authorized endpoint, browser, log collector, or recipient has obtained it.

Verify the control with failure cases

A signed-URL implementation is easier to trust when tests demonstrate its boundaries rather than only its success path.

Start with one valid request and confirm it performs exactly the intended operation. Then verify that the service rejects meaningful changes, such as selecting a different protected resource, using an operation that was not authorized, or presenting the URL after its allowed lifetime.

If the design claims one-time use, test concurrent attempts rather than only sequential reuse. If it claims revocation, revoke an issued capability and verify that the service rejects it before its original expiry.

Also inspect logs and traces from the test. A technically correct verifier can still create unnecessary exposure if observability systems record the complete URL.

These tests connect the security claim to observable behavior:

claim: one resource only
check: another resource is rejected

claim: expires promptly
check: use after expiry is rejected

claim: secret URL is not logged
check: logs contain metadata, not the bearer value

Know what signed URLs do not solve

A well-designed signed URL reduces the authority exposed by temporary delegated access. It does not solve every problem around the resource.

It does not protect against a legitimate recipient intentionally sharing the URL while it is valid. It does not protect a compromised client that can read the URL. It does not repair an authorization bug in the service that issues capabilities. It does not make public or guessable resource content confidential after download. It also does not replace authorization for operations that still pass through the main application.

For higher-risk resources, defense in depth may include shorter lifetimes, stronger authentication before issuance, fresh authentication for particularly sensitive actions, explicit revocation, download auditing, or controls that bind access more closely to an authenticated client when the platform supports them.

Use those controls because the threat model needs them, not because every signed URL requires maximum complexity.

Choose the simplest design that preserves the boundary

Signed URLs work well when a trusted application needs to delegate a narrow operation to another service without giving the recipient broader credentials. Common examples include temporary downloads and constrained uploads.

For a low-sensitivity object needed immediately, a narrowly scoped URL with a short lifetime may be enough. If the operation must be revocable, single-use, or strongly tied to a particular user session, a stateful application endpoint may be simpler to reason about than adding those properties to a bearer-link design.

The key design decision is whether possession alone is an acceptable temporary proof of authority for the operation.

If it is, make that authority explicit and small. Authorize before issuance, bind the security-relevant request properties, keep the lifetime appropriate to the workflow, avoid unnecessary disclosure, and test the failure cases.

A signed URL is useful precisely because it carries authority. Treating it as a temporary credential makes its risks and its correct boundaries much easier to see.