You let browsers upload directly to S3. With a presigned PUT URL, what stops a client from writing a key you did not intend or pushing a 5 GB file, and what does a presigned POST policy give you that the PUT does not?

## Two different signing schemes S3 offers two ways to let a browser upload without credentials, and they are not variations of the same thing. **Presigned PUT.** You sign a canonical request — method `PUT`, bucket, key, signed headers — and hand back a URL. The browser does `fetch(url, { method: 'PUT', body: file })`. Simple, one round trip, and the body streams straight up. **Presigned POST.** You sign a *policy document*, and hand back a URL plus a set of form fields. The browser builds a `multipart/form-data` POST whose last field is the file. S3 checks every submitted field against the policy's conditions before accepting the body. ## What the PUT signature actually pins The canonical request includes the HTTP method, the bucket host, the object key and the list of signed headers. Any change breaks the HMAC, so: - The client **cannot change the key**. A URL signed for `uploads/tenant-42/abc123.png` writes only there. This is the answer to "how do you stop them overwriting someone else's object" — but only if your API generates the key itself. If your endpoint takes a `key` parameter from the client and signs it, you have handed out a write primitive over everything the signing role can touch. Derive the key from the authenticated user: tenant prefix plus a server-generated identifier. - If you include `Content-Type` in the signed headers, the client must send exactly that value or the request fails. Useful for pinning `image/png`, though it constrains the declared type, not the actual bytes. - The client **cannot be bounded on size**. `Content-Length` is a header, so signing it would require the exact byte count up front — you would have to ask the browser for the size and then trust it, which defeats the purpose. In practice, a presigned PUT accepts anything the single-PUT path allows. ## What the POST policy adds The policy is base64-encoded JSON with an `expiration` timestamp and a `conditions` array, signed with SigV4. Conditions come in three shapes: exact match (`{"bucket": "my-bucket"}`), `starts-with` (`["starts-with", "$key", "uploads/"]`), and the special `content-length-range` with a minimum and maximum in bytes. Every field the form submits must be covered by a condition, or S3 rejects the upload — a strict allowlist, which is the right default for untrusted input. The SDK helper returns the URL and the exact fields to render: ```python post = s3.generate_presigned_post( Bucket="my-bucket", Key="uploads/tenant-42/${filename}", Fields={"Content-Type": "image/png"}, Conditions=[ {"Content-Type": "image/png"}, ["starts-with", "$key", "uploads/tenant-42/"], ["content-length-range", 1, 10485760], ], ExpiresIn=300, ) ``` The returned `fields` include `key`, `policy`, `x-amz-algorithm`, `x-amz-credential`, `x-amz-date` and `x-amz-signature` — plus `x-amz-security-token` when signing with temporary credentials. Render them as hidden inputs, put the file input last (S3 ignores anything after it), and the form posts straight to the bucket. `success_action_redirect` or `success_action_status` controls what the browser sees afterwards, which matters for a plain HTML form with no JavaScript. The critical property is that `content-length-range` is enforced **by S3**, not by your page. A malicious client that skips your JavaScript still gets its oversized upload rejected — S3 refuses it rather than storing it and billing you. ## Choosing between them Reach for the **PUT** when the client is your own application code, the key is fully determined server-side, and a size cap is either unnecessary or enforced elsewhere. It is one signature, one request, and trivially resumable by re-signing. Reach for the **POST policy** when a browser you do not control uploads user-chosen files and you must bound size, or when you want the key to be partly client-influenced but constrained by a prefix — `starts-with` is what makes "the user picks the filename, we pick the folder" safe. ## Defence in depth Neither scheme validates content. A `content-length-range` cap and a pinned `Content-Type` do not stop someone uploading a renamed executable inside the size limit. Real systems land uploads in a quarantine prefix or a separate bucket, verify the object server-side after the fact, and only then move it into the serving location. Keep the presigned expiry to minutes, scope the signing role to the upload prefix and the single action it needs, and remember that a size cap you enforce only in front-end JavaScript is not a cap at all.