Exposure of Shareable AWS S3 Pre-Signed Download URLs for Paid Digital Products

Overview

While testing Linktree's digital-product functionality, I identified an issue where GraphQL responses exposed AWS S3 pre-signed download URLs associated with digital products.

The URLs were returned as part of the product/listing data and contained AWS S3 signing parameters.

Discovery

During testing of the digital-product functionality, I inspected the GraphQL responses returned when retrieving product information.

A field similar to:

listing.url

contained an AWS S3 pre-signed URL.

The URL included AWS signing parameters such as:

• X-Amz-Algorithm
• X-Amz-Credential
• X-Amz-Date
• X-Amz-Expires
• X-Amz-Signature

The observed expiration value was:

X-Amz-Expires=86400

which corresponds to a validity period of approximately 24 hours.

Why This Was Interesting

A pre-signed S3 URL is effectively a temporary bearer capability.

Anyone who possesses a valid URL can generally access the associated S3 object until the signature expires, subject to the permissions encoded into that signed URL.

Therefore, exposing such a URL through an API response deserves careful authorization analysis, particularly when the underlying object represents paid digital content.

Proof of Concept

I obtained the product information through the application's GraphQL functionality and inspected the returned listing.url value.

The response contained a signed AWS S3 URL.

I then tested the URL independently of the application's normal authenticated download flow.

The URL could be requested directly without supplying the Linktree session that originally exposed the URL.

The important security property was therefore that possession of the signed URL was sufficient to access the underlying object during its validity period.

Impact

If the signed URL corresponds to content that should only be available to a paying customer, exposing the URL to an unauthorized party could allow the content to be downloaded directly from S3.

Potential consequences include:

• Unauthorized access to digital products
• Sharing of temporary download URLs
• Circumvention of application-level access controls
• Loss of control over paid digital content
• Potential redistribution of purchased content

The exact impact depends on whether the URL is intentionally exposed to the requesting user and whether the corresponding object is supposed to be restricted to purchasers.

Root Cause

The application exposed a bearer-style S3 download capability through the GraphQL response.

Application-level authorization and object-level S3 access therefore need to be carefully aligned.

A signed URL should only be generated and returned when the requesting user is authorized to access the corresponding object.

Remediation

Possible mitigations include:

• Generate pre-signed URLs only after verifying the user's entitlement.
• Keep sensitive product objects private in S3.
• Use short expiration periods where practical.
• Avoid exposing download URLs earlier than necessary.
• Bind access to the application's authorization/entitlement logic.
• Consider a controlled download endpoint that verifies authorization before issuing a short-lived signed URL.
• Monitor and revoke/rotate exposed URLs where possible.

Conclusion

AWS S3 pre-signed URLs are useful for controlled downloads, but they should be treated as temporary bearer credentials.

When such URLs are exposed through an API, the application must ensure that only users who are authorized to access the underlying object can obtain a valid URL.