DEV Community

How to use AWS S3 pre-signed URLs to upload and download files

Sohail SJ | chakraframer.com on March 18, 2024

So, this month we landed a new client for whom we must keep track of distributor's and doctor's orders and sales. The client had a requirement to k...

Read full post

Mike Stemle • Mar 18

There are a number of security problems here.

Never user plaintext AWS credentials

You shouldn't have plaintext AWS credentials in memory for your running web server. If you do, and someone is able to successfully inject code into your running server process, or otherwise dump heap, they could exfiltrate your credentials
Using plaintext credentials like this is often a recipe for never changing the credentials, which increases the harm an attacker could cause if those credentials are ever leaked.
If you're running your server in AWS, an execution role or instance profile should attach to an IAM policy document which gives you access. It is significantly safer to use IAM roles and STS than it is to use IAM users.
AWS IAM best practices discourage the use of IAM users: docs.aws.amazon.com/IAM/latest/Use...

Don't have public buckets

AWS is usually pretty clear about the risks of not having buckets configured to block all public access. It is far more secure to have your users upload the file to a server which then performs an s3:PutObject call.

If someone is able to get your service to give them signed URLs for uploading contents, you may very quickly find harmful files uploaded to your bucket.

Your CORS settings invite SSRF and CSRF

owasp.org/www-community/attacks/csrf

Your `axios` error handling is insecure

The axios module includes all authorization headers in the error object it returns, so your console.error() will log sensitive information.

Finally, you're using the old version of the AWS SDK

AWS-SDK v2 is being deprecated soon: aws.amazon.com/blogs/developer/ann...

The V3 of the SDK is pretty easy to use, and the nice thing about the change is that it's going to be similarly functional across all of the various libraries (e.g. Rust, Java, JavaScript), using similar patterns. Gone will be the days of language-specific AWS SDK patterns.

Sohail SJ | chakraframer.com • Mar 18

Damn, thank you, I really mean it. Thats a lot to take but I will study one by one on the points you mentioned and try to improve my practice in existing and upcoming projects 🤝🙌😬

Sohail SJ | chakraframer.com • Mar 18

During the production setup mostly the API routes stay under the auth middleware but I guess I can move the entire logic on the server which will take a single/multiple files and return the uploaded paths to keep it modular this I don't compose my bucket in any way

Mike Stemle • Mar 18

I very much appreciate you receiving that well. Security is hard, and security in the cloud is harder. There are a lot of tools but it's really hard to keep up with all of them.

If it helps, I never use IAM users. For humans, we should use federated authentication using something like Okta, or Auth0, and for infrastructure running code in AWS we should use execution roles or instance profiles.

Nobody can steal credentials which do not exist, or (in the case of AWS STS) are ephemeral and expire quickly.

Sohail SJ | chakraframer.com • Mar 24

Okay understood, I will try to practice using okta or Auth0 for future projects

Lee • Apr 3

Wholesome exchange right here.... Love this community 🙌

Marek Krzyżowski • Nov 6 • Edited

@manchicken
1) So how should I store them? How do you store them?

Mike Stemle • Nov 6

Fetch them at runtime and discard them when you no longer need them. Also, use instance profiles and STS when possible, avoiding having long-lived secrets in the first place.

In 2024, there is no good reason to rely on access tokens and user passwords in AWS.