Home / Knowledge hub / Object storage security
Knowledge hub
Object storage security
Locking down buckets and blobs: access rules, encryption, versioning and logging.
What it means
Object storage keeps files as objects in containers called buckets or blobs, reached over the web. Amazon S3, Azure Blob Storage and Google Cloud Storage are well-known examples. It is cheap, large and easy to share, which is why it holds uploads, backups, exports and logs.
Object storage security is the set of controls that decide who can read or change those objects, how they are protected, and how you know what happened to them. Most storage incidents come from access rules, not from broken encryption.
Why it matters
A public bucket exposes everything in it to anyone who finds the address. That has leaked customer records, backups and keys for many companies, and each case started as a simple setting. Because the data sits outside your app, the app's own checks do not protect it.
Files also last. Without versioning and logging, an overwritten or deleted object is hard to recover, and you may not learn who read it. See the related risk of S3 bucket exposure and the wider cloud misconfiguration. Fixing it early is cheap.
How it shows up
Check these settings: block public access at account level where the provider offers it, grant access through narrow roles and policies, keep encryption on, turn on versioning for important data, and log access to sensitive buckets. Set short lifetimes on pre-signed links, which are temporary URLs that give access to one object.
The usual mistakes are one bucket for public assets and private data, wide policies written in a hurry, long-lived signed links, and buckets nobody remembers. Test your app for places where it hands out storage links or accepts a bucket name from the user, since those can turn private files into reachable ones.
Questions people ask
Object storage security, answered
How do buckets become public?
Usually through an access policy or an ACL that grants read to everyone, added to make something work and never removed. Provider settings that block public access prevent this from happening by mistake.
Turn those on at account level.
Is encryption enough?
Encryption protects against some risks, such as lost disks, but does not decide who may read the object. A public bucket serves the decrypted file to anyone who asks.
Access rules come first.
What is a pre-signed URL?
It is a temporary link that gives access to one object without needing an account. It works for anyone who holds it until it expires.
Keep lifetimes short and scope narrow.
Why turn on versioning?
It keeps earlier versions of each object, so an accidental or malicious overwrite or delete can be reversed. It also helps with ransomware-style damage.
Combine it with controls over who can delete versions.
How do we test our storage?
Check that anonymous requests are refused, that one account cannot reach another's objects through your app, and that links expire. Review policies for wildcard grants.
Test the app that hands out the links, not only the bucket.
Sources
Where this comes from
Related
Terms that sit next to this one
S3 bucket exposure
A cloud storage bucket left open so anyone on the internet can read its files.
Cloud misconfiguration
A cloud setting left unsafe, such as open storage or an overly broad permission.
Snapshot exposure
Disk or database backups shared or left public by mistake.
Encryption at rest
Stored data scrambled so a stolen disk is useless without the key.
IAM role
A set of cloud permissions that a person or service can temporarily assume.
Can anyone fetch your files?
We test the app paths that hand out files and storage links, including one account reaching another's uploads, and show the request that proved it. Book a pilot on one app.
Or start with a $199 pilot on one application: thirty days, success criteria agreed before day one, credited against the annual if you convert.