Differences between PUT and POST S3 signed URLs

17 July 2019, Tamás Sallai
Both types of signed URLs fulfill the same goal: provide a serverless-friendly and controlled way for users to upload files directly to S3 buckets. The process is also the same for both as the backend needs to sign the request after validating that the user is authorized then the browser sends the file directly to S3. And finally, both can be used from Javascript equally well.

How to use S3 POST signed URLs

02 July 2019, Tamás Sallai
POST signed URLs enable the same use case as PUT URLs: when you want a scalable and controlled way of letting users upload files directly to S3. The main difference is the technical implementation of how these URLs work. While PUT URLs provide a destination to upload files without any other required parts, POST URLs are made for forms that can send multiple fields.

How to use S3 PUT signed URLs

25 June 2019, Tamás Sallai
For traditional applications when a client needs to upload a file it has to go through your backend. During the migration to the cloud, that usually means your backend uploads the same data to S3, doubling the bandwidth requirements. Signed upload URLs solve this problem. The clients upload data directly to S3 in a controlled and secure way, relieving your backend.

Limit permissions with roles for signed URLs

18 June 2019, Tamás Sallai
When you sign a URL with the global credentials (execution role for Lambda/ECS, instance profile for EC2, or IAM users) you get all the available permissions that come with it. If a user can trick your backend to sign a URL for a different bucket, for example, that could lead to security vulnerabilities. Using different sets of permissions for different purposes can help enforce the least privilege.

Editors' Favourites

Despite my ambivalent feeling about CloudFormation I use it a lot, but managing stacks through the Console is a pain. Fortunately, this service enjoys the same CLI support most other ones do, so it is just a matter of scripting to make it more developer-friendly.
One of the most catastrophic of the AWS account security breaches is not sophisticated hacking involving 0-day vulnerabilities traded on the deep web by high-profile hackers. It is when you post your access and secret keys in plain text to the public. After all, it’s so easy to test with some hard-coded keys and accidentally push it to the VCS.
S3 signed URLs provide fine control over who can access private resources. It is flexible regarding both the permission side and also on the ease of automation.
Why some projects are clean, easy-to-read, and performant, while others a convoluted mess? Why, when making a modification, in some codebases everything falls into place immediately, while in others it’s more like walking on a minefield?