Preview draft. Copy and visuals are pending review and may change before launch.

Practice

Authorization for object and file storage

Object storage is deceptively simple: put a file in, get a URL out. Exactly how that URL is protected is where the design work actually lives.

← Back to the library

Data, Access Models, and Boundaries · Published 2026-09-05

A flat namespace with an unusually blunt failure mode

Object and file storage systems typically present a simple abstraction — a bucket, a key, a URL — that hides how differently access can be scoped underneath. A single bucket-level setting, misconfigured once, can expose every object inside it at once, which is a much blunter and more consequential failure mode than a typical application-level access-control bug affecting one resource at a time.

This is part of why storage misconfiguration is such a recurring category of real-world breach: the failure isn't a subtle logic bug in application code, it's a single setting that, if wrong, exposes an entire bucket's contents to anyone who finds the URL.

Presigned access as the more deliberate pattern

Rather than making a bucket broadly readable, a more deliberate pattern issues time-limited, scoped access to individual objects on demand — a presigned URL good for one object, for a bounded window, generated only when a specific, already-authorized request needs it. This narrows what any single leaked link or misconfiguration can expose, compared to a blanket setting covering the whole bucket.

The tradeoff is that this pattern requires the application to be in the loop generating access on demand, rather than simply pointing users at a permanently accessible location — more moving parts, in exchange for access that's scoped and expires rather than open-ended.