Exposed Cloud Storage and Misconfigured Databases
Nobody has to break into a misconfigured database. It’s already open — they just have to be looking.
Nobody has to break into a misconfigured database. It's already open. They just have to be looking, and there are search engines built specifically for looking.
A cloud storage bucket set to "public" during a rushed migration. A database left listening to the open internet with no password because that was easier during setup and nobody circled back. A backup server that someone stood up "temporarily." None of these are hacks. They're doors that were never closed — and there are tools that index every open door on the internet and let anyone search them.
The internet has a search engine for exposed devices
Alongside the web search engines everyone knows, there are search engines that index connected devices and services — what's running, where, on what software version. Tools like Censys map an organization's internet-facing infrastructure and platforms like Kamerka plot exposed systems geographically.1 The legitimate use is defensive: seeing your own exposure the way an outsider does. The same visibility is available to anyone.
What these tools show: open ports, exposed databases, storage that's readable without authentication, admin panels facing the internet, and the specific software versions running — which, as we covered in Chapter 1, is a todo list for hackers.2
Secured
- Data behind authentication
- Storage private
- Database not internet-facing
- Admin panels VPN-only
Exposed
- A bucket flipped to public
- A database port open to the world
- A forgotten test server
- An admin login on the open internet
Why firms end up exposed without knowing
It's almost never malice or even carelessness in the moment. It's drift:
- A vendor or past web person set something up "just to get it working" and it stayed that way.
- A cloud service defaulted to convenient rather than closed, and nobody changed it.
- A backup, a staging copy, or a test environment got stood up with real data and never locked down.
- A service that was fine three years ago is now running a version with a known, published weakness.
The common thread is that nobody is looking at the firm's exposure from the outside — which is precisely the vantage point the attacker starts from.
What actually fixes this
1. Look at yourself from the outside. The entire defense starts with an external view of your firm's internet-facing footprint — the same view the attacker has. You can't close doors you don't know are open.
2. Default everything to private. Storage, databases, admin panels: closed unless there's a specific, documented reason to be open. "Public because it was easier" is not a reason.
3. Get databases off the open internet. A database should almost never be directly reachable from the public internet. Put it behind the application, behind a VPN, behind something.
4. Find the forgotten servers. The test copy, the old backup host, the staging site with real data — these are where exposures hide because nobody remembers they exist. Inventory them, then lock or kill them.
5. Patch what's exposed first. Anything internet-facing is the priority for updates, because it's what the device search engines index and what gets probed first.
6. Recheck on a schedule. Configuration drifts. A clean external scan is a snapshot, not a guarantee — the next migration can undo it.
This connects forward to Chapter 11 (unsecured IoT), which is the same problem — internet-exposed things nobody's watching — wearing a different costume.
No access required — we only look at what's already reachable from the public internet. That framing is the argument: everything in the report is something an outsider could already query.
Your firm's cloud & database checklist
Footnotes
Trusted by professionals like you.
