A compliance officer at a bank was preparing for an upcoming audit when she asked a question nobody on the engineering team had a clean answer to. Every customer who opened an account had uploaded a government ID and a proof of address. Where exactly were those files sitting, who could actually open them, and could the bank prove that. The honest answer was uncomfortable. The files were sitting in a storage bucket, reachable by a plain public link, generated once at upload time and never expiring. Anyone who ever got hold of one of those links, through a shared screenshot, a browser history, a support ticket, could open a customer's ID months or years later. Nothing had leaked yet. But nobody could say with any confidence that it never would.
This is not a rare mistake. It is what happens by default when file upload is treated as a simple feature instead of something that needs the same discipline as handling money itself.
Why this risk hides so well
Uploading a document and storing a link to it works, in the sense that the feature functions and nobody notices a problem in testing. The risk is invisible until the exact moment it is not, a leaked link, a support agent who should never have seen a customer's ID, a storage bucket accidentally left open to the public. By the time it is noticed, the damage is already done, and for a bank, a document like a government ID or a bank statement is not something you get to quietly walk back.
