The discovery
An application stores internal documents in an object-storage container. After a configuration change, someone discovers that certain links allow files to be downloaded without authentication. No sophisticated attack needs to be imagined to recognize the seriousness of the situation: an incorrectly defined permission can affect many documents at once.
Why it happens
Cloud infrastructure provides identity controls, policies, logging and encryption, but someone must configure them according to the service model. An account with broad privileges, an accidentally exposed resource or a temporary exception that was never revoked may expand access. The precise allocation of responsibility depends on the roles of the provider and the customer.
What needs to be established
It is not enough to declare that the container “was public.” It matters when the exposure began, which paths or keys were affected, who could gain access, which operations were possible and which logs have been retained. The absence of downloads in an incomplete log does not necessarily establish that no one accessed the material.
The subsequent review must look beyond the exposed resource. Inherited policies, service identities, signed links and deployment automations may explain why a manual fix disappears at the next update. If the error originated in a template, other environments created from that template need to be located. A durable solution is not simply to mark a resource as private once, but to prevent the insecure configuration from being deployed again without review or alerts.
Containment and preservation
The initial response usually seeks to restrict exposure and protect credentials while documenting the observed state, modifications and available logs. A rushed investigation that overwrites configuration or deletes logs may make it impossible to reconstruct the sequence of events. Unnecessary copies of sensitive material should be avoided.
Privacy and continuity implications
Where personal data are affected, obligations to assess, document and, where applicable, notify may arise under the GDPR. The analysis should not be reduced to volume alone: the nature of the data, potential recipients and plausible harm all matter. Dependencies and automation that could expose the resource again must also be reviewed.
“It is in the cloud” does not tell us whether it is protected. The verifiable question is who could access which resource, under what conditions, over what period and on what evidence.
How a shared link changes exposure
In a cloud service, a document may be private, visible to a team, accessible to anyone in an organisation or shared through an open link. These choices look similar in an interface but produce different levels of exposure. The common error is not always a sophisticated attack: copying a link configured for public access and sending it to someone outside the organisation is enough. An assessment begins by checking the resource’s permissions and which identities could actually use them.
A junior technician should examine inherited permissions, groups, service accounts and organisation-wide storage policies. A file may inherit broad access from a folder or belong to a collaborative workspace whose configuration changed months ago. This is why checking a single object in isolation is not always enough: the rules governing the folder, project and organisation must also be understood.
Detecting access is not the same as proving extraction
When a public permission is found, exposure should be limited promptly. But a different question then arises: did anyone actually access the content? The answer depends on the available logs, their scope and retention periods. Some services distinguish opening, downloading, previewing and failed requests; others record only administrative activity. The lack of a conclusive log does not demonstrate that no one saw the file.
It is useful to preserve the configuration as found, relevant events and the sequence of corrections before deleting information needed for the investigation. Changing permissions can contain the risk without yet establishing how long access was available or which users were authorised. Communicating this uncertainty is better than declaring a confirmed data leak or dismissing one without evidence.
Design permissions that are easy to manage
Security improves when defaults are cautious and broader permissions require a deliberate decision. Clear labels, link expiration, periodic reviews and alerts about unusual exposure can reduce errors. Personal accounts should also be avoided for automations, and access should be reviewed after team or provider changes.
In practice, a sound audit relates the classification of information to the need to share it. A public draft may need broad circulation; a case file containing personal information does not. Technology should accommodate that difference without requiring every user to know the whole permissions architecture. If sharing correctly is excessively complicated, teams may resort to informal workarounds that create new risks.
Access reviews after team changes
Access rights do not remain justified forever. A project may finish, a provider may cease supplying services or a folder may change purpose while retaining old permissions. Periodic reviews should therefore compare who has access with who currently needs it. The aim is not to revoke every permission indiscriminately: a correction must take legitimate operations and automated processes into account. A change log and a functional test can help withdraw privileges without disrupting services, while making clear who approved access and under what conditions.
Further references: OWASP · NIST Cybersecurity Framework 2.0