DEV Community: Aditi Dange

Testing S3 Drop Zone Upload Limits: What Happens When You Pause a Request?

Aditi Dange — Mon, 12 Oct 2026 03:59:12 +0000

A paused upload request looks like a stopped upload channel. But does changing the request's state also invalidate the authorization already embedded in a saved page?

I tested this with Buckets by Serverless Creed, comparing browser behavior with decoded POST conditions, controlled requests sent directly to S3, and independently verified objects. The results separated three boundaries: page validation, S3 authorization, and application request state.

The upload path and tested configuration

Buckets generates an HTML recipient page containing signed POST fields. The browser submits a multipart request directly to S3, which evaluates the signature, policy conditions and applicable AWS permissions. A saved page carries issued authorization; uploading through it does not require the recipient to sign into AWS.

The experiment used Buckets 2.7.54 on Windows, a local HTML page, and a disposable private bucket in us-east-1 on October 11–12, 2026.

Setting	Tested value
Request	Vendor Upload Test
Bucket	`buckets-intern-aditi-dropzone-20261011`
Object prefix	`incoming/vendor/`
File-size display	1 MB
File-count limit	1
Allowed type	`text/plain`
Expiry selection	1 day

Bucket creation settings selected Block All Public Access and SSE-S3. Exact OS/browser versions and the signing credentials' lifetime were not recorded.

For reproduction, use the Buckets downloads page, an approved private sandbox, Python 3 and authorized AWS Console/CLI access. The sandbox budget alarm was confirmed before testing; direct POST replay was conducted under reported owner approval.

CORS allowed POST, GET and HEAD, with wildcard origins and headers. Successful browser uploads showed HTTP 200 preflight and HTTP 204 upload responses. CORS controls browser cross-origin access; it does not grant S3 write permission. A non-browser replay client is not subject to browser CORS enforcement. AWS CORS documentation

Establishing a valid baseline

Deterministic files made the size boundary reproducible:

from pathlib import Path

folder = Path("blog03-fixtures")
folder.mkdir(exist_ok=True)
files = {
    "valid.txt": b"Aditi upload fixture\n",       # 21 bytes
    "second.txt": b"Second file\n",               # 12 bytes
    "wrong.html": b"<p>Harmless test</p>",         # 20 bytes
    "too-large.txt": b"x" * 1_048_577,            # one byte over 1 MiB
}
for name, data in files.items():
    (folder / name).write_bytes(data)

The page accepted valid.txt with HTTP 204. AWS Console independently showed the 21-byte object at incoming/vendor/abb7e962f9cc45c9-valid.txt.

The generated token changed the final key, so verification used the actual stored key rather than assuming it matched the filename. Downloading the object and comparing SHA-256 with PowerShell's Get-FileHash produced the same digest as the source:

860DB5A8887A82E09C1C812D0CBBAE23CADDD7D2A39575100A2998387647A758

That established byte integrity as well as upload completion.

Figure 1. Valid 21-byte upload: HTTP 204 with a successful preflight response.

What the browser rejected

Selecting wrong.html produced:

File type 'text/html' not allowed

The cleared, recording Network panel captured no request. This was a page-side rejection, not an S3 policy response. The page already contained a successful upload, so this was not an isolated fresh-session MIME test.

Figure 2. Browser rejection of text/html without a captured upload request.

The 1,048,577-byte fixture produced:

File exceeds 1 MB limit (1 MB)

Both values were rounded to “1 MB,” obscuring a one-byte difference. The screenshot established the displayed rejection, but did not retain Network evidence for that attempt.

A subsequent 21-byte recovery.txt uploaded from the same page without a refresh. HTTP 204 and an independently listed S3 object confirmed recovery after rejected input.

Figure 3. After rejecting the oversized file, the same page accepted a valid 21-byte retry without a refresh.

What the signed policy actually constrained

Decoding the saved policy exposed these conditions. This is a sanitized excerpt, not the complete signed policy:

{
  "expiration": "2026-10-12T17:32:08.054Z",
  "conditions": [
    ["starts-with", "$key", "incoming/vendor/"],
    ["content-length-range", 0, 1048576],
    ["starts-with", "$Content-Type", "text/plain"]
  ]
}

The displayed “1 MB” corresponded to 1 MiB: 1,048,576 bytes. The key condition restricted the submitted object key to incoming/vendor/.

The MIME condition was a prefix comparison on the submitted Content-Type field, not strict equality or file-content inspection. Rejecting text/html does not prove that S3 recognizes the bytes as plain text. AWS POST policy documentation

To test S3 independently of the page, a local Python client submitted the saved signed fields as multipart POST requests. A valid baseline succeeded first; each negative then changed one tested boundary while retaining the policy and signature.

Direct POST test	Changed input	HTTP	S3 result
Baseline	Valid prefix, 21 bytes, `text/plain`	204	Object created
Prefix	Key under `outside-vendor/`	403	`AccessDenied`; failed key-prefix condition
Size	1,048,577-byte file	400	`EntityTooLarge`
Submitted MIME	Form field `Content-Type=text/html`	403	`AccessDenied`; failed MIME-prefix condition

The size response stated: “Your proposed upload exceeds the maximum allowed size.” The MIME replay preserved the plain-text bytes and file part's text/plain header, isolating the changed form field.

Correct multipart construction matters: preserve signed fields, avoid duplicate key or Content-Type fields, generate a matching boundary header, and place the file part last. AWS POST Object documentation

A whole-bucket AWS CLI listing showed five successful objects: four browser uploads and the replay baseline. None of the failed replay keys appeared. Checking only the allowed prefix would have missed an incorrectly accepted outside-prefix object.

Figure 4. S3 rejected prefix, size and submitted MIME violations; independent listing showed only the five successful uploads.

Why one file was not a global quota

After the first upload, selecting second.txt in the same page returned “File limit reached,” with no captured Network request.

Reopening the saved HTML in a new tab allowed that same file to upload with HTTP 204. AWS showed both objects, although the page still displayed a one-file limit.

Figure 5. The existing page rejected a second valid file.

Figure 6. Reopening the saved HTML reset the page counter and allowed the second file.

For this saved-page flow, the counter operated within the page instance. It did not enforce a shared quota across uses of the issued authorization. A global limit requires an authoritative shared admission mechanism; a browser counter alone cannot provide it.

What Pause stopped—and what remained usable

Pausing the request changed its card to “Paused” and disabled the save and host controls. That established the UI behavior; no backend refusal response was captured from those disabled controls.

The previously saved HTML still uploaded after-pause.txt successfully. HTTP 204 and the independently verified 23-byte object incoming/vendor/63ce607d042713f2-after-pause.txt established that issued authorization remained usable during pause.

Figure 7. Pausing disabled the request’s save and host controls.

Figure 8. Previously saved HTML successfully uploaded a file while the request was paused.

After the Drop Zone record was deleted, the controlled POST baseline also succeeded with the saved fields. In this run, pausing or deleting the application record did not invalidate the already-issued S3 authorization.

This distinction matters operationally: stopping new page generation and revoking existing upload authority are separate controls. Hosted-page removal was not tested, so these results apply to saved HTML and direct replay.

Expiry, verification and cleanup

The policy expiration was October 12, 2026, 23:02:08.054 IST. It was inspected, not tested with a fresh POST after that time. Credential validity and AWS permissions can end signed access earlier; the policy timestamp alone does not guarantee a full day of usability. AWS credential-expiration guidance

Boundary	Evidence	Supported conclusion
Prefix	Direct 403; failed key absent	S3 enforced the signed prefix
Size	Page error; direct 400	One byte above the bound rejected
MIME	Page rejection; direct 403	Submitted MIME prefix enforced
File count	Same-page rejection; reopened-page success	Page-instance scope observed
Pause	Disabled controls; saved-page upload succeeded	Existing authorization remained usable
Expiry	Decoded timestamp only	Elapsed expiry untested

Exact-bound acceptance and file-content validation were not tested.

Cleanup removed the request and all five uploaded objects, then deleted the disposable bucket. An independent AWS CLI bucket-list query filtered for its exact name returned [], corroborating deletion.

Figure 9. Independent AWS verification returned an empty list for the deleted test bucket.

Saved HTML and extracted signed fields are authorization material. Keep them private and remove local signed copies after evidence collection; publish only sanitized conditions and responses.

Conclusion

The useful question is not whether an upload page displays a limit, but where that limit is enforced.

In this run, S3 enforced the signed key prefix, file-size range and submitted MIME prefix. The page's file counter reset on reopening. Pausing disabled new generation controls, yet previously saved authorization still worked.

For engineers, the practical lesson is to verify each boundary at its own layer: inspect exact policy conditions, observe browser requests, test approved direct submissions and check actual S3 state. Treat request management, issued authorization and object cleanup as separate operations.

Deploy a Private-Origin Site with Buckets and Verify an Incremental Update

Aditi Dange — Thu, 08 Oct 2026 16:23:25 +0000

A static site can be publicly available through CloudFront while its S3 origin remains private. This gives visitors an HTTPS endpoint without making the underlying S3 objects anonymously readable.

In this tutorial, I use Buckets by Serverless Creed to review and deploy a small static site, verify its access boundary in AWS, and inspect an incremental update. The update changes one file, adds another and leaves two files unchanged.

The walkthrough draws on my Windows deployment tests and a supplementary run on 8 October 2026. Historical examples are labelled with their original application versions and fixtures.

Understand the delivery setup

Visitors access the site through CloudFront over HTTPS. CloudFront requests the files from an S3 REST origin using an Origin Access Control (OAC). The bucket policy grants object-read access to the intended CloudFront distribution.

This setup makes the site available through CloudFront while restricting anonymous access to the underlying S3 objects.

An S3 REST origin differs from an S3 static website endpoint. This walkthrough uses the REST origin because OAC does not apply to S3 website endpoints. See AWS’s guidance on restricting access to an S3 origin.

Prepare the environment and test files

Install Buckets from the official download page. Before deploying, confirm your approval for the AWS resources, public site delivery and associated costs. Check the active AWS account, profile, budget alerts and cleanup plan.

My supplementary run on 8 October 2026 used Buckets by Serverless Creed v2.7.49 on Windows, with the aws-admin profile in the us-east-1 AWS region.

Earlier supporting tests used v2.7.17 for the initial deployment (TC-SITE-001) and v2.7.20 for incremental deployment (TC-SITE-002), using the default AWS profile.

Create a local folder named site containing these three files:

File	Purpose
`index.html`	The page we will modify during the update
`style.css`	A stylesheet we will leave unchanged
`large-test.bin`	A binary file we will also leave unchanged

Save index.html as UTF-8:

`html
<!doctype html>
<meta charset="utf-8">
<title>Aditi sandbox site</title>
<link rel="stylesheet" href="style.css">
<h1>Deployment revision 1</h1>
`

Save style.css as UTF-8:

body { font: 18px sans-serif; margin: 3rem; }

Create a 1 MiB binary test file by running this Python code from inside the site folder:

from pathlib import Path

Path("large-test.bin").write_bytes(b"x" * 1048576)

The binary file provides an unchanged object to track during the incremental update.

Before editing any files, record their names, sizes and SHA-256 hashes. Open PowerShell inside the site folder and run:

Get-ChildItem -File |
    Select-Object Name, Length, @{
        Name = 'SHA256'
        Expression = {
            (Get-FileHash -LiteralPath $_.FullName -Algorithm SHA256).Hash
        }
    } |
    Export-Csv ..\manifest-before.csv -NoTypeInformation

This saves manifest-before.csv in the parent directory. Keep manifests and screenshots outside the site folder so they are not uploaded as website content.

Review and Deploy the Site

In Buckets, open Build → Publish → Folder → Live Site
and select the local site folder.
Choose the disposable destination bucket and verify the AWS profile and region. For the initial deployment, use a new CloudFront distribution. Leave Delete remote-only objects unchecked.
Select Preview diff. My initial preview showed:

3 uploads: index.html, style.css and large-test.bin
0 unchanged files
0 remote-only files

Initial deployment preview: three uploads, no unchanged files and no remote-only objects.
Select Confirm deploy, then review the affected resources, required permissions and estimated costs in the Cost & permission review before submitting.
The deployment connects the S3 bucket to an OAC-backed CloudFront distribution. Buckets reported Deployment submitted and three paths invalidated.

Buckets reported deployment submission and three invalidated paths.

Verify delivery and the private S3 origin

Open the CloudFront HTTPS URL in an Incognito or signed-out browser. In my supplementary run, the page displayed Deployment revision 1.

CloudFront served Deployment revision 1 in Incognito.
Next, copy the S3 Object URL for index.html from AWS Console and open it in Incognito. Use the plain object URL, without presigned credentials. My direct S3 request returned AccessDenied.

An unsigned request for the S3 index object returned AccessDenied.
Verify the configuration independently in AWS Console:

Under CloudFront → Distribution → Origins, confirm that the S3 origin has the intended OAC attached.
Under S3 → Bucket → Permissions → Bucket policy, inspect the CloudFront access permission. In my test, the bucket policy allowed s3:GetObject to the cloudfront.amazonaws.com service principal, with an AWS:SourceArn condition matching the intended distribution. The CloudFront S3 origin had an OAC attached. The bucket policy scoped CloudFront object-read access to the intended distribution. These results demonstrate the intended access boundary: the page was available through CloudFront, while the unsigned direct S3 request was denied. Check the stylesheet separately through the CloudFront URL at /style.css.

The incremental preview identified two uploads and two unchanged files.
Review the changes and submit the deployment. In AWS Console, open the distribution’s Invalidations tab. My completed invalidation contained exactly these paths:
/index.html
/notes.txt

The completed invalidation targeted only /index.html and /notes.txt.

Verify the Updated Site and Deployment Scope

After the incremental deployment, I verified that the CloudFront invalidation reached Completed status and included exactly two paths: /index.html and /notes.txt.

The Buckets preview identified 2 uploads and 2 unchanged files, matching the intended changes:

Modified: index.html
Newly added: notes.txt
Unchanged: style.css and large-test.bin

This confirmed that Buckets correctly identified the files requiring an update while recognizing the unchanged files.

As a final verification step, the updated index.html and newly added notes.txt can be accessed through the CloudFront HTTPS endpoint. For deeper verification, S3 object metadata such as Last modified timestamps or version IDs can also be compared before and after deployment.

Verify OAC list, create and delete operations

Alongside the site deployment, I tested OAC management using a separate, disposable OAC that was not attached to a distribution.
In Buckets, open the Origin Access Control list under the authorized AWS profile. Record the existing entries so they can be preserved.
Create a test OAC with these settings:

Setting	Value
Name	`buckets-intern-aditi-oac-20261007`
Origin type	S3
Signing behavior	Always
Signing protocol	SigV4

After creation, I verified that the new OAC appeared in both Buckets and AWS Console.

Buckets created the disposable OAC using S3, Always signing and SigV4.

The new OAC also appeared in AWS Console.
I then deleted only the disposable, unattached OAC. Buckets displayed a successful deletion result, and an independent AWS Console check confirmed that the entry was absent. The pre-existing OAC remained in the list.

Buckets reported successful deletion of the unattached test OAC.

The refreshed AWS list no longer contained the test OAC; the existing entry remained.
The deletion dialog also explained that AWS blocks deletion while an OAC is in use. This test demonstrated deletion of an unattached OAC; the OAC serving the deployed site was retained.

Troubleshooting: OAC Creation Error

During one deployment attempt, the site files uploaded, but OAC creation returned “The parameter Name is too big.” I checked AWS to identify the resources already created before retrying with a shorter disposable bucket name. The retry successfully created the delivery stack. The exact generated-name cause was not confirmed.

OAC creation failed with a name-length error after the site files uploaded

Cleanup and Resource Teardown

After completing the initial deployment, private-origin verification, and incremental update tests, I removed the disposable AWS resources created for this walkthrough.

I followed the dependency-aware cleanup order to avoid deleting resources that were still in use.

1. Remove the CloudFront distribution

I disabled and deleted the test CloudFront distribution. After deletion, the AWS CloudFront console displayed Distributions (0), confirming that no distributions remained in the selected account.

AWS CloudFront console showing zero distributions after deleting the test distribution.

2. Delete the Origin Access Control (OAC)

Using the Origin Access Controls interface in Buckets, I deleted the OAC associated with the test deployment.

Buckets displayed a successful deletion message. I independently checked the AWS CloudFront console, which showed Origin access controls (0).

Buckets confirming successful deletion of the test Origin Access Control.

3. Empty the S3 bucket

Before deleting the bucket, I used Buckets to remove the four test objects. The application confirmed that the bucket was emptied and the bucket list was synchronized.

4. Delete the S3 bucket

Finally, I deleted the disposable S3 bucket using Buckets. The application displayed a successful deletion notification and synchronized the bucket list.

Buckets confirming deletion of the disposable S3 bucket and synchronization of the bucket list.

Cleanup Result

The CloudFront distribution and OAC were confirmed absent in AWS, while Buckets confirmed the deletion of the four S3 objects and the test bucket.

This completed the application-side cleanup of the disposable resources used for the tutorial.

Conclusion

In this walkthrough, we deployed a static website using Buckets by Serverless Creed, with Amazon S3 as a private origin and Amazon CloudFront providing HTTPS delivery.

We verified that:

The website was accessible through its CloudFront HTTPS URL while direct, unauthenticated S3 access was denied.
CloudFront Origin Access Control (OAC) was configured to support access to the private S3 origin.
The incremental deployment preview identified the changed and newly added files for upload while marking unchanged files separately.
CloudFront invalidation targeted the updated paths, allowing the latest website content to be served.
The disposable CloudFront distribution, OAC, and S3 resources were removed after testing.

The key takeaway is that deploying a website is only part of the process. Verifying origin access, reviewing incremental changes, checking cache invalidation, and cleaning up test resources are equally important.

By combining the Buckets deployment workflow with independent AWS Console checks, we can better understand what the application performs and what AWS actually enforces.

Create a Private S3 Bucket with Buckets and Verify Its Settings in AWS

Aditi Dange — Tue, 06 Oct 2026 12:36:08 +0000

Introduction

Creating an S3 bucket is only part of the setup. You also need to verify that its configuration matches the settings you selected.

In this tutorial, I use Buckets by Serverless Creed to create a disposable private S3 bucket with versioning, Amazon S3-managed encryption (SSE-S3), and Block Public Access enabled. I then compare the selected settings with the configuration in AWS.

The walkthrough also explains bucket-list refresh, the empty-bucket view, and recovery from denied access-control requests. A supplementary run verifies Object Ownership and records both bucket-level and account-level Block Public Access settings.

Prerequisites and tested environment

Before following the walkthrough, you will need:

Buckets installed on your computer. The installer is available from the official download page.
An approved AWS sandbox and an authorized profile for bucket creation, configuration checks, and cleanup.
AWS Console access to independently verify the bucket settings.
A separate approved restricted profile for the permission-denied example.
A unique disposable bucket name and an approved AWS Region.

Use your assigned sandbox permissions rather than granting yourself general administrator access.

The evidence comes from separate documented tests on Windows in us-east-1, followed by a supplementary run using Buckets 2.7.47:

Part of the walkthrough	Recorded application version
Private bucket creation	2.7.9
Bucket-list refresh and empty-state checks	2.7.12
Historical denied CORS write	2.7.17
Supplementary creation, verification, empty view and denied reads	2.7.47

The historical tests used different disposable buckets. The supplementary run used one fresh bucket for the creation, empty view, AWS configuration checks and restricted-profile checks. Historical screenshots are labelled separately; they do not represent one continuous execution on a single build. Interface labels may differ between versions.
The supplementary work was performed on 6–7 October 2026 (India Standard Time). Its authorized profile was named aws-admin; older records use the profile name default. A profile name identifies a local configuration, so verify the account and identity rather than relying on the name alone. Private approval and account details belong in the supporting evidence record.

1. Choose the bucket settings

Before creating the bucket, decide which settings you intend to apply. For this test, I used the following configuration:

Setting	Selected value
AWS Region	`us-east-1`
Object Versioning	Enabled
Default encryption	Amazon S3-managed encryption (SSE-S3)
Block All Public Access	Enabled
Object Lock	Disabled
Static Website Hosting	Disabled

Versioning retains multiple versions of objects. SSE-S3 provides encryption at rest, while Block Public Access restricts public access through policies and ACLs. These controls serve different purposes: encryption does not grant access, and versioning does not prevent every form of deletion.

Object Ownership is checked separately in AWS. Only describe it as an application selection if that control is actually available in the tested form.

2. Create the bucket in Buckets

Open the bucket-creation form in Buckets and select the authorized AWS profile. Enter a unique bucket name, choose the approved Region, and select the configuration listed above.

For my recorded creation test, I used the default profile and a disposable bucket in us-east-1. I enabled Object Versioning, SSE-S3 encryption, and Block All Public Access, while leaving Object Lock and Static Website Hosting disabled.

Review the name, Region, and selected options before confirming creation.

Figure 1. Bucket-creation form showing the disposable bucket name, Region and selected options before confirmation.

After confirming, follow the operation through its creation stages. A bucket appearing in the list does not, by itself, prove that every selected setting was applied.

In my recorded test, creation completed without an observed error or partial-failure message. I reopened the bucket’s properties in Buckets, where Versioning appeared as Enabled and Public access appeared as Fully blocked.

These application values were an initial check. I then verified the configuration independently in AWS.

After creation, Buckets displayed Versioning as Enabled and Public access as Fully blocked.

3. Verify the bucket settings in AWS

After checking the bucket’s properties in Buckets, open the same bucket in AWS Console. Confirm its name and Region before inspecting the configuration.

Check Bucket Versioning and Default encryption under Properties, then check Block Public Access and Object Ownership under Permissions.

My recorded creation test documented the following AWS results:

Setting	Selected in Buckets	Recorded AWS result
Region	`us-east-1`	`us-east-1`
Bucket Versioning	Enabled	Enabled
Default encryption	SSE-S3	Server-side encryption with Amazon S3 managed keys
Block All Public Access	Enabled	On; all four individual flags enabled

AWS Console verification of SSE-S3 default encryption.

AWS Console verification of enabled bucket versioning.

AWS Console verification of all four bucket-level public-access blocks

These checks confirm the recorded configuration, rather than providing an absolute security guarantee. Versioning, encryption and access controls serve different purposes, and the bucket’s access also depends on applicable policies and account-level restrictions.

The documented AWS values matched the selected configuration. If a value differs, record the mismatch rather than treating the operation as fully successful.

Object Ownership and account-level checks in the supplementary run

In the supplementary 2.7.47 run, AWS Console showed versioning Enabled, default encryption SSE-S3, and all four bucket-level Block Public Access flags On. AWS also showed Bucket owner enforced Object Ownership, with ACLs disabled. Ownership was independently verified in AWS; I do not describe it as an option selected in Buckets.

Setting or check	Intended value / source	Observed result in the supplementary run
Region	`us-east-1`	`us-east-1` shown in Buckets
Versioning	Enabled	Enabled in AWS Console
Default encryption	SSE-S3	Amazon S3 managed keys in AWS Console
Bucket-level Block Public Access	All four flags enabled	All four flags On in AWS Console
Object Ownership	Independently inspect AWS state	Bucket owner enforced; ACLs disabled
Account-level Block Public Access	Inspect existing settings without changing them	All four settings Off

Supplementary run: AWS Console shows Bucket owner enforced ownership and disabled ACLs.

All four account-level Block Public Access settings were Off at the time of inspection; no account settings were changed.

Account-level settings being Off does not automatically grant public access. S3 applies the most restrictive combination of applicable bucket, account and organization settings. In this fixture, the bucket-level flags remained On. See AWS documentation on Block Public Access.

With Bucket owner enforced, ACLs are disabled. The Access Control ACL tab displayed that ownership state. This is different from an IAM permission-denied response; I did not enable ACLs for the test.

4. Refresh the bucket list

Refresh the bucket list under the same authorized AWS profile, then locate and open your bucket.

In a separate supporting Buckets version 2.7.12 on Windows, I created a disposable bucket directly in AWS Console. It did not initially appear in Buckets. Selecting Refresh Bucket List made it visible.

After deleting that test bucket through AWS Console, its entry remained visible in Buckets until I refreshed again. Refreshing removed the stale entry. This demonstrates why the displayed list should be refreshed after changes made outside the application.

The bucket created in AWS Console appeared in Buckets after refreshing the list

Refreshing after AWS-side deletion removed the test bucket from the list

5. Inspect the empty-bucket view

Open the bucket under the authorized AWS profile and inspect its object list.

In a separate supporting test on Windows version 2.7.12 and supplementary run using Buckets 2.7.47 on Windows, I opened an empty disposable bucket. Buckets displayed Create Folder and Upload Files actions, providing clear next steps for adding content.

Keep the bucket empty while capturing this part of the walkthrough. A failed or access-denied request does not prove that a bucket is empty; confirm that the object-list request completed successfully.

Separate empty-state test: an empty bucket displays Create Folder and Upload Files actions.

6. Handle denied access-control requests

A restricted AWS profile may be prevented from reading security settings, changing them, or both. The following tests demonstrate these differences.

Restricted-profile checks in Buckets 2.7.47

In the supplementary test using Buckets 2.7.47 on Windows, I used a separate temporary profile named tcacl006-restricted. It allowed bucket listing and basic reads of the disposable test bucket, while explicitly denying access to its security configuration.

Under this profile, I opened Access Control and checked the available tabs.

Tab	Observed result
Bucket Policy	Loading failed with an explicit deny for `s3:GetBucketPolicy`
Public Access	Loading failed with an explicit deny for `s3:GetBucketPublicAccessBlock`
CORS	Loading failed with an explicit deny for `s3:GetBucketCORS`

The restricted profile could not load Public Access settings because its identity policy explicitly denied s3:GetBucketPublicAccessBlock.

The Access Control dialog remained usable: I could switch tabs and close it after the errors.

The ACL tab displayed “ACLs disabled — Bucket owner enforced.” This was an ownership-related restriction, rather than a displayed IAM authorization error. I did not enable ACLs or change Object Ownership.

Because the Public Access settings failed to load, the tab did not display editable flags or a Save control. Resubmitting the existing Public Access Block values was therefore unavailable in this UI state. This test demonstrates denied configuration reads, rather than a denied PAB save.

Recover using the authorized profile

I closed the dialog, switched to the authorized aws-admin profile, and reopened Access Control for the same bucket.

The Public Access tab loaded successfully with all four blocking flags checked. The CORS tab displayed an empty configuration, [].

After switching to the authorized profile, the same bucket’s Public Access settings loaded with all four blocking flags checked.

I then completed an independent AWS Console check before cleanup to confirm that the intended configuration remained unchanged.

Recovery used the existing authorized profile. It did not require broadening the restricted profile’s permissions or weakening public-access controls.

Historical example: a denied CORS write in Buckets 2.7.17

An earlier, separate supporting test used Buckets 2.7.17 on Windows and a different disposable bucket. In that test, the restricted profile could read configuration, while security-configuration writes were restricted. The authorized profile was named default.

Under the restricted profile, I opened Access Control → CORS. The application initially displayed an empty configuration, [].

I attempted to save this test configuration:

[
  {
    "AllowedOrigins": ["https://example.invalid"],
    "AllowedMethods": ["GET"]
  }
]

AWS rejected the save. Buckets displayed an authorization error identifying s3:PutBucketCORS and an explicit deny in the restricted identity’s policy. The Access Control dialog remained usable.

Historical test on Buckets 2.7.17: AWS rejected the restricted profile’s CORS write with an explicit deny for s3:PutBucketCORS.

Verify that the denied CORS change was not applied

After the failed save, I closed and reopened the CORS section. It again displayed [].

I independently checked the bucket using the authorized default profile. The following command illustrates that verification; replace the example bucket and profile names with your approved test values:

aws s3api get-bucket-cors --bucket EXAMPLE_BUCKET --profile AUTHORIZED_PROFILE

AWS returned NoSuchCORSConfiguration, confirming that no CORS configuration existed after the denied save. Together with the initial empty configuration, this supported the conclusion that the attempted change was not applied.

Historical test: an independent check using the authorized default profile returned NoSuchCORSConfiguration after the denied save.

The historical test demonstrates a denied write. The supplementary 2.7.47 test demonstrates denied reads and successful configuration loading after returning to the authorized profile. They are separate tests with different permission settings.

7. Clean up the disposable resources

After retaining the evidence, remove only the disposable resources created for the walkthrough.

For the historical creation test, my cleanup record states that the bucket was empty and was deleted after evidence collection. For the separate empty-state test, I removed the uploaded test object and folder before deleting its bucket.

The historical permissions-test cleanup removed the temporary restricted IAM identity, access key, profile and associated test policy. The authorized default profile remained unchanged.

For the supplementary test using Buckets 2.7.47, I completed the final AWS configuration check and deleted the disposable bucket and temporary restricted IAM user after collecting evidence.

For your own cleanup:

Confirm that the bucket is the disposable resource you are authorized to remove.
Remove any test objects. If versioning is enabled and objects were uploaded, remove all created versions and delete markers as authorized.
Delete the disposable bucket.
Refresh the lists in AWS Console and Buckets to verify that the bucket is absent, rather than merely empty.
Remove the temporary restricted identity, its access keys and test policy. Remove any remaining local or application profile entries and temporary credential files.

Preserve shared resources and retain the final configuration checks and cleanup evidence with the test record.

8. Tested scope and limitations

This article combines historical Windows tests using Buckets versions 2.7.9, 2.7.12 and 2.7.17 with a supplementary test using version 2.7.47.

The historical tests used different disposable buckets. The supplementary test used one fresh bucket for creation, the empty-bucket view, AWS configuration verification and restricted-profile checks. The labelled screenshots should therefore be read in their respective test contexts.

The supplementary AWS verification showed:

Bucket Versioning enabled.
SSE-S3 default encryption.
All four bucket-level Block Public Access flags enabled.
Bucket owner enforced Object Ownership, with ACLs disabled.
All four account-level Block Public Access settings disabled at the time of inspection.

Object Ownership was independently verified in AWS; it is not presented as an option selected in the Buckets creation form. Account-level settings were inspected without modification. Their disabled state does not automatically grant public access: S3 applies the most restrictive combination of applicable public-access blocking settings.

The historical permissions example demonstrates a denied CORS write and subsequent verification that the change was not applied. The supplementary example demonstrates denied bucket-policy, Public Access Block and CORS reads, followed by successful loading through the authorized profile.

The ACL tab displayed ownership-related restrictions rather than an ACL permission-denied error. A PAB save attempt was unavailable because the restricted profile could not load the settings and the tab did not expose a Save control.

These observations describe the tested configurations and operations. They do not provide an absolute security guarantee or establish every possible access path or behaviour in other application versions.