Signed URL Leakage: Detection and Response

Treat a signed URL as a delegated capability, not a public object

Signed URL leakage detection starts with a precise model: the object can remain private while a cryptographically signed request grants a holder time-bounded access. The storage service validates the signature and constraints in the request, but it normally cannot distinguish the intended recipient from someone who copied the URL.

Amazon S3 presigned URL documentation states that a presigned URL can be used by anyone who possesses it while it remains valid. Azure Storage SAS security guidance similarly warns that anyone with a valid shared access signature can access the authorized data. Google Cloud signed URL documentation describes access through a URL whose query string carries authentication information.

Leakage therefore differs from changing an object ACL to public. It is exposure of a capability whose authority is encoded in the URL. Determine the object, HTTP method, validity window, signed headers, signing principal or key, delivery channel, intended recipient, and whether repeated use is permitted before assigning severity.

Decode the URL without exposing the signature again

Preserve the original URL in a restricted evidence store, then work from a redacted copy. Query strings routinely enter browser history, reverse-proxy logs, analytics, support tickets, chat transcripts, referrer data, and screenshots. Do not paste the live artifact into a shared case note or detection query.

This is an authored, redacted S3-style example—not a usable credential and not a universal format:

https://storage.example/reports/payroll.csv?
  X-Amz-Algorithm=AWS4-HMAC-SHA256&
  X-Amz-Credential=<redacted>&
  X-Amz-Date=20261110T132500Z&
  X-Amz-Expires=900&
  X-Amz-SignedHeaders=host&
  X-Amz-Signature=<redacted>

Record a one-way hash of the full URL for correlation, the normalized object identifier, provider, algorithm, issue time, expiry, method, signed headers, and credential identifier. Never treat query parameters as trustworthy merely because they parse: verify the effective policy and credential state with the provider control plane.

Correlate URL issuance, delivery, storage access, and data impact

Start at issuance. Application logs should record request ID, authenticated subject, authorization decision, object ID, method, TTL, signer identity, destination class, and a non-reversible URL fingerprint. Many storage platforms do not maintain an inventory of every signed URL generated, so application-side issuance evidence is often the missing link.

Join that record to delivery telemetry and object-access logs using object, time, method, request ID where available, network origin, user agent, response status, and bytes transferred. Look for access before the expected handoff, after the business event ended, from multiple autonomous systems or geographies, by automation inconsistent with the recipient, or repeated near expiry. Account for proxies, mobile networks, corporate egress, download managers, and provider log latency before calling the pattern malicious.

A successful request proves use of the capability, not the human identity behind it. Raise confidence by connecting access to a leak path or consequence: URL appearance in a public repository, referrer or proxy log exposure, an unexpected client fingerprint, bulk downstream processing, or subsequent use of data from the object.

Contain the capability according to its signing mechanism

First stop further distribution and preserve evidence. If the object contains sensitive data, isolate or move it only after recording the original identifier and access state. Then identify the provider-specific invalidation boundary. A short remaining TTL may make monitored expiry safer than a key rotation that interrupts unrelated workloads.

For S3, validity can end with the underlying temporary credentials, expiry, or a policy control; AWS presigned URL guardrail guidance describes controls such as network restrictions and signature-age limits. Azure response depends on whether the SAS uses a user delegation key, service SAS with a stored access policy, or an account key. Google Cloud notes that a signed URL remains usable until expiry or until its signing key is rotated. Validate current provider behavior before containment because revocation semantics and propagation are not interchangeable.

Scope the blast radius before revoking shared credentials or keys. Identify other URLs, services, jobs, and customers that depend on the same signer. After containment, rotate exposed downstream credentials, notify the data owner and privacy function when appropriate, and retain access logs through the full validity window plus provider logging delay.

Design short-lived, narrow URLs and keep them out of telemetry

Authorize before signing. Bind each URL to the minimum object, HTTP method, content constraints, and validity period required for the business action. Use temporary signing credentials where supported, HTTPS-only delivery, provider policy conditions, and separate signers by workload and environment. A “one-time download” usually requires an application broker or stateful redemption service because native signed URLs are commonly reusable during their validity window.

Prevent secondary disclosure: redact query strings at proxies and analytics collectors, exclude them from traces and error reports, set an appropriate referrer policy in web applications, prohibit URLs in tickets and chat, and avoid exposing them to third-party page resources. Store only a keyed fingerprint when correlation is required. Test that caches, redirects, content-delivery layers, and browser behavior do not extend access beyond the intended boundary.

Simulate with a non-sensitive object and an authorized test principal. Generate a short-lived URL, send it through the approved channel, access it from the expected client, and then reproduce one controlled anomaly. Confirm that issuance and access correlate without recording the live signature. Never publish the URL or use production personal data for the exercise.

Turn signed URL usage into an observable data-access control

Next step: inventory every service that creates signed URLs. Record provider, signer, object classes, allowed methods, maximum TTL, delivery channel, issuance-log location, storage-log coverage, revocation method, blast radius, and accountable owner. Use the inventory to build data access baselines around sensitive objects rather than alerting on every signed request.

Exercise one leak scenario end to end and measure time to find the issuing subject, access events, and invalidation boundary. Connect the result to PII attack paths and response and the organization’s rules for personal data privacy and sharing. The durable control is a narrow capability with traceable issuance, protected delivery, observable use, and a rehearsed way to end access.