Uploading files

Most of the book discussed how to use signed URLs to download files, but the ability to upload them is required for the same reasons. And the solution is also similar: the backend checks if the user should be allowed to upload a file, signs the URL, then the user contacts S3 directly to handle the transfer. This retains the ability to define the access control in arbitrary ways while being serverless-friendly by only trasferring a small amount of data through the backend.

But uploading files brings its own set of problems as the user has a lot more wriggle room to influence how the solution works. For example, they can upload big files deliberately wasting bandwidth and storage or specify a malicious content type and pull off a stored XSS attack.

Because of this increased freedom, the crucial part of uploading files with signed URLs is how to limit what the user can do and how to close the gaps that might affect security.

Permissions

Just like downloading, uploading also relies on the permissions of the signer entity. In this case, the s3:PutObject is required for objects in a bucket.

data "aws_iam_policy_document" "putobject-policy" {
  statement {
    actions = [
      "s3:PutObject",
    ]
    resources = [
      "${aws_s3_bucket.bucket.arn}/*",
    ]
  }
}

Instead of the /* you can define a more limited path. For example, if you want to allow uploads only to the users directory inside the bucket, use "${aws_s3_bucket.bucket.arn}/users/*".

CORS config for uploads

Except for the cases where the upload goes to the same origin as the webapp, you'll need to configure CORS for the bucket for uploading. There are three important part in this regard.

First, the allowed method needs to be PUT or POST, depending on which upload mechanism you use, or you can add both.

Second and third, the allowed origins and the allowed headers need to be set to *.