Skip to content

fix(s3-presigned-post): use starts-with condition for fields containing ${filename}#7771

Open
TrevorBurnham wants to merge 1 commit intoaws:mainfrom
TrevorBurnham:fix/presigned-post-filename-substitution
Open

fix(s3-presigned-post): use starts-with condition for fields containing ${filename}#7771
TrevorBurnham wants to merge 1 commit intoaws:mainfrom
TrevorBurnham:fix/presigned-post-filename-substitution

Conversation

@TrevorBurnham
Copy link
Contributor

Fixes #7191

Problem

When using createPresignedPost() with ${filename} in a field value (e.g. success_action_redirect), S3 rejects the upload with AccessDenied.

S3 supports ${filename} variable substitution in POST uploads — at upload time, S3 replaces ${filename} with the actual uploaded filename. However, the SDK generates an exact-match policy condition for all fields:

{"success_action_redirect": "https://example.com/success?file=${filename}"}

When S3 substitutes ${filename} with the real filename (e.g. test.txt), the field value becomes https://example.com/success?file=test.txt, which no longer matches the exact condition, causing a policy violation.

The SDK already handles this correctly for the Key field (line 82), but not for other fields.

Solution

Extend the existing ${filename} detection to all user-provided Fields. When a field value contains ${filename}, generate a starts-with condition instead of an exact match:

["starts-with", "$success_action_redirect", "https://example.com/success?file="]

This allows S3 to substitute ${filename} freely while still enforcing that the field value starts with the expected prefix.

Changes

  • packages/s3-presigned-post/src/createPresignedPost.ts — check field values for ${filename} and emit starts-with conditions
  • packages/s3-presigned-post/src/createPresignedPost.spec.ts — add test for ${filename} in field values

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

…ng ${filename}

When a field value (e.g. success_action_redirect) contains the
${filename} variable, S3 substitutes it with the actual uploaded
filename at upload time. The SDK was generating an exact-match
policy condition for these fields, which caused a policy mismatch
and AccessDenied error because the substituted value no longer
matched the literal ${filename} string.

This extends the existing ${filename} handling (which already
worked for the Key field) to all user-provided Fields. Any field
value containing ${filename} now gets a starts-with condition
instead of an exact match, allowing S3's variable substitution
to work correctly.

Fixes aws#7191
@TrevorBurnham TrevorBurnham requested a review from a team as a code owner February 23, 2026 01:04
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Presigned POST URL ${filename} substitution potential bug

1 participant