Data and secret leaks: what has already left

The mental image of a data leak is an attacker breaching a perimeter. In practice, the overwhelming majority of what an attacker finds about an organisation was published by someone inside it, legitimately, and simply left in the open.

A developer commits a configuration file with a live key. A team publishes an API collection to share it with a partner. A backup is dropped in a web-accessible directory "for a moment". A storage bucket is created with default permissions. Nobody was careless in a way that felt careless at the time.

Two consequences follow, and both are uncomfortable.

• There is nothing to detect. No intrusion happened, so no alert fires, and your logs show nothing unusual. Leaks are found by looking outward, not by monitoring inward.
• Publication is effectively irreversible. Public code is cloned, search engines cache, archives snapshot. Deleting the original does not retract the copies.

This is why leak handling is built around revocation rather than removal. You cannot unpublish a secret. You can only make it worthless.

API keys, database passwords, cloud tokens and private keys end up in public repositories constantly, and they are harvested within minutes of being pushed. Automated scanners watch public commit streams continuously. The window between publishing a key and seeing it used is measured in minutes, not days, which is what makes the response order below matter so much.

Deleting the file is not enough This is the most common and most expensive mistake. Removing a secret in a new commit leaves it fully readable in the repository history, and every clone made in the meantime keeps it permanently.

The order that actually works:

• Revoke and rotate the secret first. Before the cleanup, before the post-mortem, before telling anyone. A revoked key is harmless wherever it has already spread, and you do not control where that is.
• Then purge it from history with git filter-repo or BFG Repo-Cleaner, accepting that existing clones still hold it.
• Then add pre-commit secret scanning, with gitleaks or trufflehog, so the next one is caught before publication instead of after. ReconScope runs trufflehog against your public code for exactly this reason.

Beyond git repositories Public API collections, shared workspaces on collaboration platforms and public projects on forges routinely carry keys, tokens and internal URLs that were never meant to be shared. They get reviewed far less often than code, because people file them mentally as documentation. Postman workspaces and public GitLab projects are the two that turn up most. Anything published under your brand deserves the same scrutiny as a repository.

Front-end secrets A key hardcoded into client-side JavaScript is readable by every visitor. No obfuscation changes this, because the browser has to read it, so anyone can. It needs to be revoked and moved server-side, not hidden better.

This category has grown faster than any other, and it is the one organisations most often have no visibility on at all.

An infostealer is malware running on an individual workstation, an employee, a contractor, sometimes a customer, that exfiltrates everything the browser holds: saved passwords, session cookies, autofill data, VPN profiles. The output is packaged and sold on criminal marketplaces, sorted by the domains it grants access to. Your domain is the index key.

The session cookies are what make this dangerous, and it is the part most people miss. A stolen password is defeated by multi-factor authentication. A stolen session cookie is not. It represents a session that already passed authentication, so replaying it walks straight past MFA. Your logs show a normal, authenticated user.

The infected machine is frequently outside your control, a personal laptop used for remote access, a supplier workstation, so your endpoint protection never sees it. In practice the first signal is your domain turning up in a leaked credential set, which is why checking is not optional.

Responding - Force a password reset for the exposed accounts, and invalidate active sessions. A reset that leaves sessions alive fixes nothing, because the cookie is what was stolen. - Enable MFA everywhere, knowing it mitigates stolen passwords and not stolen sessions. - Isolate and rebuild the compromised machine. Cleaning an infostealer infection in place is not reliable. - Monitor continuously. New sets appear constantly, so a one-off check tells you about one moment and nothing else.

Search engines index far more than intended: database dumps, backups, configuration files, log files, administration portals, internal documents. Anyone can find them with a targeted query, a technique usually called dorking, and it requires no skill at all. The queries circulate in public lists.

Here is the part that catches people out. Removing a file from your server does not remove it from the index. The cached copy stays available until the index refreshes, and an archive may hold a copy indefinitely.

So the sequence matters:

• Remove or restrict the content on your side.
• Request removal from the index explicitly, through the Removals tool in Google Search Console. Waiting for a natural refresh can take weeks.
• Rotate every secret the file contained, on the assumption that it was read. You cannot prove otherwise, and the rotation costs less than the assumption being wrong.

Web archives Archiving services snapshot pages over time. A configuration file, an export or a backup exposed for a single afternoon three years ago may still be retrievable today, long after every trace of it left your servers. Historical URLs are worth reviewing precisely because they document what used to be exposed, and because nobody ever audits them.

A storage bucket left publicly readable is one of the highest-yield findings there is, because of what buckets typically hold: backups, database exports, user uploads, invoices, attachments.

What makes them particularly exposed is that bucket names are guessable. They follow the brand — company-backup, company-assets, company-prod — so an attacker does not need to discover the name. They generate candidates and test them.

Responding Confirm the bucket is actually yours before acting, then block public access at the account level rather than object by object — that is what prevents the next misconfiguration as well as this one. Review what was exposed, and rotate every credential or key that was stored inside. A bucket containing a backup very often contains a configuration file, and that configuration file very often contains a password.

This one is quieter than the rest, and it is not about secrets. Every published document — PDF, spreadsheet, presentation — carries metadata: author names, internal usernames, software versions, sometimes internal file paths and printer or server names.

None of it is a vulnerability on its own. Together, across a few dozen public documents, it produces something valuable to an attacker: a list of real staff names, the account naming convention, and the software in use. That is the raw material for credible targeted phishing, and for password attacks against a known username format.

The fix is procedural rather than technical: strip metadata before publishing, and make sanitisation a step in the publication process rather than something remembered case by case.

The sequence matters more than the speed, and getting it wrong wastes the only hours that count.

• Revoke first. Before investigating, before cleaning up, before informing anyone. An exposed credential is dangerous only while it remains valid, and revocation is usually the fastest action available.
• Assume it was read. Do not spend time trying to establish whether anyone saw it — you cannot prove a negative, and the assumption costs you a rotation you should perform anyway.
• Then remove, knowing removal is incomplete. Delete the file, purge the history, request de-indexing. Treat this as reducing further spread, not as undoing the leak.
• Find how it was published. A leak is a symptom of a process: a missing review step, a default permission, an unmonitored workstation. Fixing the instance without fixing the process guarantees a repeat.
• Consider your legal obligations. If personal data is involved, GDPR notification duties may apply, with a 72-hour window for notifying the supervisory authority. Establish this early, not after the technical work is done.