TL;DR

S3 pre-signed URLs grant temporary access to objects in AWS S3 buckets without the need to grant explicit permissions.

• Supports only GET and PUT requests.
• Request headers must exactly match both when creating and using the URLs.

Motivation

It’s a best practice to keep S3 buckets private and only grant public access when absolutely required. Then how can you grant your client access to an object without changing the bucket ACL, creating roles, or providing a user on your account? That’s where S3 pre-signed URLs come in.

Pre-Signed URLs

S3 pre-signed URLs are a form of an S3 URL that temporarily grants restricted access to a single S3 object to perform a single operation — either PUT or GET — for a predefined time limit.

To break it down:

• It is secure — the URL is signed using an AWS access key
• It grants restricted access — only one of GET or PUT is allowed for a single URL
• Only to a single object — each pre-signed URL corresponds to one object
• With a time-constrained — the URL expires after a set timeout

In the next section, we’ll use these properties to generate an S3 pre-signed URL.

So let’s jump over to some code samples.

Key Points

Building a solution with S3 pre-signed URLs is not without its pitfalls. Here are some pointers to save you valuable time:

1. You must send the same HTTP headers — when accessing a pre-signed URL — as you used when you generated it. For example, if you generate a pre-signed URL with the Content-Type header, then you must also provide this header when you access the pre-signed URL. Beware that some libraries - for example, Axios - attach default headers, such as Content-Type, if you don’t provide your own.

#aws-s3 #serverless #aws #presigned-url #aws-s3-bucket