As a security engineer, I want JWT short-lived token support for CloudFront S3 passthrough to mitigate directory crawling risk

[jordanpadams]

Checked for duplicates

Yes

🧑‍🔬 User Persona(s)

Security Engineer, System Administrator

💪 Motivation

The current CloudFront S3 passthrough exposes directory listings to anyone who can reach the CloudFront URL. Short-lived JSON Web Tokens (JWTs) would mitigate the risk of unauthorized or automated crawling of exposed S3 directories by requiring a valid, time-limited token for access.

...so that the risk of bulk data harvesting or unauthorized enumeration of S3 contents is reduced without requiring a full authentication overhaul.

📖 Additional Details

• JWTs should be short-lived (configurable TTL)
• The token mechanism should integrate with the CloudFront distribution (e.g., Lambda@Edge or CloudFront Functions for validation)
• The S3 browser client should obtain and attach a valid JWT when making requests to the CloudFront passthrough
• This is a new security requirement for the CloudFront integration layer

Acceptance Criteria

Given a CloudFront distribution configured to require JWT validation
When a request is made to the S3 browser CloudFront passthrough without a valid JWT
Then the request should be denied

Given a valid, non-expired JWT
When the S3 browser makes a request using that token
Then directory contents should be returned normally

⚙️ Engineering Details

To be filled by engineering team

🎉 I&T

To be filled by engineering team

[jordanpadams]

Note: Key complication the issue doesn't fully address: file download links (item.href = BUCKET_URL + '/' + item.Key) are direct anchor tags. You can't attach a JWT header to a browser navigation. This likely means CloudFront Signed URLs or Signed Cookies rather than pure JWT Bearer tokens — which would change the architecture somewhat.

This is probably going to take 3-6 weeks to implement, so we have bigger fish to fry right now. We will rely on egress monitoring for help us mitigate some of these risks.