A key in the app binary is a bucket handover; presigned uploads also drop the proxy data bill

The presign endpoint is where the risk went, and the sample code makes that legible. The handler builds the object key from `Date.now()` plus `req.body.fileName` and passes `req.body.contentType` straight into the `PutObjectCommand` ^[9], so the signature covers three attributes: bucket, key, content type ^[10]. Two of the three arrive from the caller ^[21]. The long-lived credential is off the device ^[4], and what replaces it is a service that will sign a write for whatever path and MIME type a client asks for. Smaller grant, still a grant, and validating it is now your job rather than IAM's.

What the backend keeps doing per upload is one small JSON exchange: the client posts a filename and content type, gets a URL back, then PUTs the raw bytes to S3 ^[12]. The bytes must not be wrapped in JSON, since the signature was cut against the binary body and the declared content type ^[13]. Success comes back as a 200 with the object ETag ^[14]. There is a small inconsistency in the write-up worth resolving before you copy it: the prose says the backend already knows the key from the presign step and so the app need not return much ^[14], while the code comment on the 200 branch tells the app to report the key so the backend can process the file ^[15]. Those are two different bookkeeping designs wearing the same snippet.

The expiry is the other operational detail. The Node sample signs for 900 seconds, and the author's argument for it is that a leaked URL is inert after the deadline ^[8]. That cuts the other way for a driver on a bad connection: an upload that has not landed inside the window needs a fresh signature, which puts the presign call on the retry path and not just the happy path ^[20]. Pinning `ContentType` at signing time has a similar double edge. It stops the object being served later as `application/octet-stream` ^[11], and it means the type the client declared is the type the object carries.

On the client the same function serves both targets, with the web build passing `Uint8List` bytes from a `file_picker` result instead of a `File` with a path ^[16]. The whole dependency list is `http` ^[18], which is the honest tell about where the difficulty sits.

Weight this as what it is: one practitioner's account of one implementation, on a client delivery app where drivers photograph parcels for backend processing ^[5]. The tooling claim is thin because the tooling is thin. The credential claim does not need corroboration, because a secret in a shipped build is readable by anyone who decompiles it or opens dev tools on the web target ^[3].