Hero image: editorial concept illustration, not a product screenshot or a client installation.
Your application stores invoices in Amazon S3, while your website serves public images. Are those two access requirements actually separated, or did a convenient upload configuration leave business files more widely accessible than intended?
A cloud-storage review should start with who needs each file and how they obtain it. ITZ’s software consulting service can help map an application’s storage dependencies and plan an access review. For a UAE business, include customer documents, staff records and supplier exports in that conversation, not just the files visible on the public website.
Classify the files and the routes to them
Create a register of buckets, owning accounts, Regions, applications and data owners. Then identify the intended reader for each type of content: the public, an authenticated customer, an employee or an integration. Record whether access goes directly to S3, through application code, through a signed link or through a content-delivery service. Confirm production and test environments separately.
For example, a hypothetical distributor may publish catalogue photos but keep customer-specific invoices behind its portal. Putting both under one broad public access rule is a design problem. A clearer design separates these access requirements and documents the boundary. The appropriate separation may involve distinct buckets and application roles; it requires checking the existing dependencies before migration.
Check what Block Public Access does
AWS’s S3 Block Public Access documentation describes controls that restrict public access through policies and access control lists. Review the effective organisation, account, bucket and access-point settings where applicable; a more restrictive organisation policy can still apply when a bucket-level control is off. Do not assume that a private-looking bucket name, an obscure object path or encryption at rest establishes the access boundary.
Blocking public access is not the same as denying every authenticated request. Your own application or another authorised principal may still read objects under its permissions. Review identities, actions and resource scope as well as public-access settings. In particular, an application that reads an entire bucket needs a business justification if its task only concerns a limited set of objects.
Review public and cross-account findings
IAM Access Analyzer for S3 can identify public and cross-account access findings. Confirm that the required analyzer and permissions exist in each relevant Region. An empty view is not a substitute for checking coverage. Investigate what grants the access and whether a named business owner intended it.
Cross-account sharing can be legitimate, such as an approved integration. Document the recipient, purpose and review date rather than treating every finding as an incident or dismissing all findings as expected. AWS documents update delays for findings and summaries, so combine them with direct configuration checks when validating a change. Findings do not, by themselves, establish who actually downloaded a file.
Review Your Business Cloud File Access to discuss bucket ownership, public website assets, private application documents and a controlled verification plan. A high-level architecture sketch is more useful for the first conversation than confidential files or access keys.
Keep public delivery separate from a public bucket
A website can publish selected assets through CloudFront while restricting direct access to its S3 origin. AWS’s origin access control guidance describes that pattern. It requires an appropriate regular S3 bucket origin; an S3 website endpoint cannot use that OAC arrangement. The bucket policy must authorise the intended distribution.
That protects the origin route, not automatically the viewer route. If a CloudFront distribution serves an invoice to anyone who knows its URL, restricting the bucket to CloudFront has not made the invoice private to its customer. Private downloads need an appropriate viewer-authorisation design as well. Ask the developer to explain both boundaries before accepting the implementation.
Handle signed links as access credentials
AWS explains in its presigned URL guidance that these links grant time-limited access using the signing identity’s permissions. Anyone holding a valid link can use that granted access; it is not automatically tied to the customer who requested it. Expiry can also be limited by the underlying credentials.
Define who can generate links, which objects and operations are allowed, and how long access is needed. Avoid putting sensitive signed URLs into support tickets, analytics events or shared chat transcripts. Do not treat a signed URL as inherently single-use. If your application needs one-time download behaviour or an immediate revocation workflow, design and test that explicitly rather than assuming the URL provides it.
Verify changes without exposing customer records
- Capture the current policies and application dependencies in restricted records, then agree the change and recovery plan.
- Use harmless test objects with the same relevant access settings; never make a real invoice public to prove a point.
- Confirm an unauthorised request cannot read the private test object through direct and application-facing routes.
- Confirm the intended user can still perform approved uploads and downloads, and cannot obtain another user’s private object.
- Retest public assets, exports and background jobs, then review configuration and analyzer findings when they have refreshed.
Work only within your own authorised environment. A browser receiving “access denied” on one URL is useful evidence for that request, not proof that every object and access path is secure. Suspected exposure requires incident assessment and cybersecurity support, including appropriate evidence preservation, rather than only a routine settings tidy-up.
Access control also differs from retention and recovery. Use the S3 cleanup and retention guide before deleting old objects, and the restore-test checklist when validating recovery. None of those replaces an application authorisation review.
Review Your Business Cloud File Access. Use the form below to discuss storage ownership, application permissions, signed downloads and an agreed test of public-versus-private access.
Review Your Business Cloud File Access ↗
Official AWS documentation reviewed on 16 October 2026. This guide focuses on S3 general purpose bucket access and is not a complete cloud-security assessment or evidence of regulatory compliance.
