Most people picture a breach as an attacker breaking in and stealing a database. Just as often, the data was never protected in the first place, and it simply leaked. Sensitive data exposure is what happens when information that should be locked away, such as passwords, personal details, or payment data, is stored or moved in a way that lets the wrong person read it. This post explains what counts as sensitive data, the handful of mistakes that expose it, and which of those you can actually see from the outside.
What counts as sensitive data, and where it leaks
Sensitive data is anything that would harm your users or your business if it were seen by someone who should not see it. The obvious cases are passwords, payment card details, and personal information like names, addresses, and dates of birth. The less obvious cases are session tokens, API keys, and internal identifiers that let an attacker act as someone else. Data leaks at three points: while it is stored (at rest), while it travels between the browser and your server (in transit), and when it is handed to a third party such as an analytics or logging service. A good security posture protects all three, and most exposures happen because one of them was quietly left open.
The mistakes that cause it
Exposure rarely comes from exotic cryptography being broken. It comes from a short, familiar list of shortcuts.
- Traffic that is not properly encrypted. If any part of your site is served over plain HTTP, or your HTTPS is misconfigured, data can be read or tampered with in transit. This is one of the few things that is fully visible from outside.
- Passwords stored in a way that can be reversed. Passwords should never be stored as plain text, and they should be hashed with a slow, modern algorithm designed for the job. Storing them in plain text, or with fast general-purpose hashing, means one database leak exposes every account.
- Secrets and keys left in the wrong place. API keys, database credentials, and tokens committed into code or shipped to the browser are a direct route to your data. We cover this failure in depth in secrets, keys and config: the quiet gaps.
- Sensitive values in URLs and logs. Tokens or personal data placed in a web address, or written into application logs, end up in browser history, server logs, and third-party tools where they were never meant to live.
- Unencrypted or over-shared backups. A database can be perfectly protected while a copy of it sits in unencrypted storage that far more people can reach.
- Handing more data to third parties than you meant to. Analytics, error trackers, and support tools often receive far more than they need, quietly widening the circle of who holds your users' information.
Why fast-built apps get this wrong
None of this comes from carelessness. A modern framework or hosting platform gives you a working, encrypted app out of the box, which is genuinely good. What it does not do is make the judgement calls: which fields are sensitive, how long tokens should live, what your logging tool is allowed to see, and whether that convenient copy of the database is encrypted. Those are decisions someone has to make on purpose, and when an app is scaffolded quickly they are easy to skip. If your app was built this way, our Supabase security checklist and our pre-launch checklist walk through the practical points.
What you can and cannot see from the outside
The transit half of this problem is genuinely visible from the public internet. A quick Surface Check can tell you whether your traffic is properly encrypted, whether you enforce HTTPS, and whether your session cookies carry the flags that stop a browser leaking them, and it takes about thirty seconds. What an outside-in scan cannot see is how you store data, how you hash passwords, or what you send to third parties, because that lives inside your application. That is the honest limit of any external check, and it is the same gap we describe in what your Surface Score does and does not mean. If you want a fuller reference, OWASP maintains a practical cryptographic storage cheat sheet.
Next steps
Start with the free Surface Check to clear the parts that are visible from outside, then look hard at how data is stored, hashed, logged, and shared, which an external tool cannot reach. If you want that done properly, our application security assessment reviews data handling alongside authentication, access control, and configuration, in the round rather than in isolation. We prepare the fixes and hand them to your team to review and deploy, or apply them directly where you have authorised us to do so in writing. You can get in touch through our website.