Cloud storage permissions: why data ends up public and how access controls work

Cloud storage permissions decide who can read, list or change the files kept in services such as Amazon S3 buckets and Azure Storage containers. When those permissions are set too widely, files meant for a handful of staff can be readable by anyone on the internet who finds the address. This guide explains why publicly exposed storage happens, how AWS and Microsoft describe their public access controls, how sharing links fit in, and how teams audit what’s exposed.

Why it matters

Exposed storage is usually a configuration problem rather than a break-in. Nobody has to guess a password if the container allows anonymous reads. Microsoft’s shared responsibility model lists customer data and “configurations and settings” as the customer’s responsibility in every service type, so these settings sit with the team that owns the account.

If personal information is exposed, Australian privacy obligations may apply. Our explainer on data breaches covers the general picture, and the OAIC is the official source on the Notifiable Data Breaches scheme.

Why publicly exposed storage happens

Common patterns include:

• A quick fix that stays. Public access is switched on to share a file or test a website, then never switched off.
• Mixing public and private data. A storage account that hosts a public website also holds internal files.
• Settings at more than one level. Permissions can be set on the account, the bucket or container, individual objects, and through policies. A change at one level can quietly override another.
• Long-lived sharing links. A link created for one recipient keeps working for anyone who has it.
• Old resources nobody owns. Buckets created for a past project are forgotten but still online.

How Amazon S3 Block Public Access works

AWS’s documentation says that “by default, new buckets, access points, and objects don’t allow public access.” AWS announced that from April 2023 it automatically enables S3 Block Public Access and disables access control lists (ACLs) for all new buckets, applied in all AWS Regions. Older buckets, or buckets where someone changed the settings, may still differ.

Block Public Access has four settings, which AWS says can be used alone or together:

Key points from AWS’s page:

• Settings can apply at the organisation, account, bucket and access point levels. When they conflict, S3 “applies the most restrictive combination”.
• AWS recommends turning on all four settings for the account, and checking that applications work without public access before doing so.
• Block Public Access “don’t alter existing policies or ACLs”, so removing the setting makes a bucket with a public policy or ACL “publicly accessible” again.
• AWS also says to inspect identity-based and resource-based policies to confirm they don’t grant public access.

How to turn on Block Public Access for an AWS account

Based on AWS’s instructions (checked October 2026). The console can change; AWS’s guide to configuring Block Public Access for an account has the latest steps.

1. Sign in to the AWS Management Console and open the Amazon S3 console.
2. In the navigation pane, choose Account and organization settings.
3. Under Block Public Access settings for this account, choose Edit.
4. Choose the settings to change, then choose Save changes.
5. When asked to confirm, enter confirm, then choose Confirm.

AWS says that if the account is governed by an organisation-level Block Public Access policy, these settings can’t be changed in the account and the organisation’s administrator manages them.

How Azure Storage anonymous access works

Microsoft says that “by default, anonymous access to your data is never permitted” and that unless it is explicitly enabled, all requests to a container and its blobs must be authorised. Microsoft recommends disallowing anonymous access for all storage accounts unless a scenario specifically requires it.

There are two layers:

• Account level: the AllowBlobPublicAccess property. When it’s set to false, Microsoft says all blob requests to the account require authorisation, “regardless of the anonymous access setting for any individual container.”
• Container level: Private (the default for new containers), Blob (anonymous reads of individual blobs) or Container (anonymous reads plus listing the blobs).

Where some content has to be public, Microsoft describes moving those containers into separate storage accounts reserved only for anonymous access.

How to disallow anonymous access on an Azure storage account

Based on Microsoft’s instructions (checked October 2026). Portal menus can change; Microsoft’s guide to configuring anonymous read access has the latest steps.

1. In the Azure portal, go to the storage account.
2. Under Settings, select Configuration.
3. Set Allow Blob anonymous access to Disabled.

Microsoft notes it can take up to 30 seconds for the change to take effect, and that a static website’s $web container stays publicly accessible regardless of this setting. It also notes that afterwards some clients receive a 403 (Forbidden) error instead of 401 (Unauthorized), and describes making all containers private to avoid this. Microsoft says changing the setting needs the Owner, Contributor or Storage Account Contributor role.

How to share files without making storage public

Not every share needs public access. Both platforms offer time-limited links instead.

In Azure these are shared access signatures (SAS). Microsoft’s SAS guidance says that “if a SAS is leaked, it can be used by anyone who obtains it.” It describes:

• preferring a user delegation SAS, which is secured with Microsoft Entra credentials so the account key doesn’t need to be stored with code
• always using HTTPS
• near-term expiry times, and a SAS expiration policy on the account
• granting the least possible privileges, such as read-only
• having a revocation plan, including stored access policies for service SAS.

Microsoft also notes that “it’s not possible to audit the generation of SAS tokens”, and that Shared Key access can be disallowed to stop SAS tokens signed with the account key for blob and queue workloads.

For files in Microsoft 365 rather than Azure Storage, our guide to SharePoint and OneDrive sharing settings explains “Anyone” links and the related settings.

How to audit what’s exposed

Teams generally check storage exposure in three ways:

• Provider tools. AWS’s IAM best practices describe using IAM Access Analyzer to “verify public and cross-account access to resources” and to monitor resources for it.
• Configuration review. Listing each bucket or storage account with its Block Public Access or anonymous access setting, its owner and whether it is still needed.
• Least privilege for people. The ACSC’s tenants guidance lists “least access privileges” for administering cloud services. Fewer people able to change storage policy means fewer accidental changes. See cloud identity and access management.

Logs of who changed a storage policy, and when, come from the platform’s activity logs, described in cloud logging and monitoring.

A fictional example

Tom manages a small events business, bookings.example. A contractor set up an Azure storage container years ago to share brochures, with access set to Container. Over time staff saved booking spreadsheets there too. During a review, Tom sees the account allows anonymous access. Following Microsoft’s guidance, he moves the brochures to a separate account used only for public files, sets the original account’s Allow Blob anonymous access to Disabled, and replaces an old shared link with a short-lived, read-only SAS for a partner who needs one file.

Things to watch for

• Turning a control off “just for a minute”. AWS warns that removing Block Public Access re-exposes anything with a public policy or ACL.
• Static websites. Microsoft notes the $web container is always public, so nothing private belongs there.
• Account keys in code. A storage account key can create SAS tokens without the owner knowing; see secrets and API keys.
• Long expiry on links. A SAS that lasts a year behaves much like a public link once it leaks.
• Policies outside the bucket. AWS notes identity-based and resource-based policies can also grant public access.

Common questions

How do I stop my cloud storage from being public?

AWS and Microsoft each describe an account-wide switch. AWS recommends turning on all four S3 Block Public Access settings for the account, after checking applications don’t rely on public access. Microsoft recommends disallowing anonymous access on all Azure storage accounts unless a scenario specifically requires it, and keeping genuinely public files in a separate account. For sharing, both describe short-lived links instead of public access. See how to turn on Block Public Access and the Azure steps.

How do S3 buckets become public?

Through bucket policies, access control lists or access point policies that grant public access. AWS says new buckets don’t allow public access by default, and since April 2023 Block Public Access is enabled for all new buckets, so older buckets are the ones most likely to differ. AWS also says Block Public Access doesn’t alter existing policies or ACLs, so turning it off can make a bucket public again. See how Amazon S3 Block Public Access works.

Is Azure blob storage public by default?

No. Microsoft says anonymous access to data is never permitted by default, and new containers default to Private. Anonymous access only happens if someone enables it at both the account and container level. Microsoft notes one exception: a static website’s $web container stays publicly accessible regardless of the account setting, so nothing private belongs there. See how Azure Storage anonymous access works.

What is a SAS token and is it safe to share?

A shared access signature is a link that grants limited, time-bound access to Azure Storage. Microsoft says a leaked SAS can be used by anyone who obtains it, and that it’s not possible to audit the generation of SAS tokens. It describes preferring a user delegation SAS, always using HTTPS, near-term expiry, read-only or other least-privilege access, and a revocation plan. See how to share files without making storage public.

How can I check whether any of my cloud storage is exposed?

Teams generally use provider tools, such as AWS IAM Access Analyzer, which AWS describes for verifying public and cross-account access. They also review the configuration directly: listing each bucket or storage account with its Block Public Access or anonymous access setting, its owner and whether it’s still needed. Activity logs show who changed a storage policy and when. See how to audit what’s exposed.

What do I do if I find personal information in a public bucket or container?

The settings in this guide describe how AWS and Microsoft block public access, and activity logs can show when a policy changed. If personal information was exposed, Australian privacy obligations may apply, and the OAIC is the official source on the Notifiable Data Breaches scheme. The ACSC takes reports through ReportCyber and runs a 24/7 hotline on 1300 CYBER1 (1300 292 371). Our data breaches guide covers the general picture.

Where to get official help

• Microsoft Learn: remediating anonymous read access for blob data.
• AWS: blocking public access to Amazon S3 storage.
• The ACSC for cloud security guidance, ReportCyber and the 24/7 hotline (1300 CYBER1, 1300 292 371).
• The OAIC for information about data breaches involving personal information.