4 ms·
This article makes it sound like upload requests are restricted to your domain via CORS, but that is one of the pitfalls of thinking about everything through a
by mnutt 10y ago
This article makes it sound like upload requests are restricted to your domain via CORS, but that is one of the pitfalls of thinking about everything through a serverless lens: while another site could not use javascript to directly upload files to your s3 bucket, a malicious user could absolutely make a backend request to receive signed tokens for uploading to your s3 bucket. Additionally, it doesn't look like the policy is locked down so they could overwrite your existing files with malicious ones.
- foota 10y agoA practical implementation of this would probably want to do a couple things: 1. As you mention, make sure they can't overwrite files 2. Have a content type whitelist on the requestUploadURL function 3. Maybe authentication to keep track of who is submitting these requests? Assuming that you're okay allowing someone to upload files with a given content-type to your bucket is there anything I'm missing?
- mnutt 10y agoFor #1, I would probably disallow writing to arbitrary paths and instead generate a path prefix using a UUID and return that to the client to ensure that every upload is unique.
- tjholowaychuk 10y agoYou can easily abuse non-serverless solutions as well... when signing the S3 request you could have internal logic and prevent this kind of behaviour, by just not signing the request.
- mnutt 10y agoSure, though I think this is somewhat specific to serverless because in traditional applications, authentication usually covers all interactions with the user whereas with serverless you sometimes have to figure it out on a case-by-case basis. The article makes it sound like it accounts for it with CORS headers, which may mislead novices.