A client asked me a plain question last month, mid-call, almost as an afterthought: "is this actually secure?" I gave the answer I always give in that moment, something like "yeah, it's solid, we've tested it thoroughly." It came out fast and confident. It was only after I hung up that I actually sat with what I'd meant by that.
What "tested thoroughly" actually meant
I had tested it. Every feature worked the way it was supposed to. Forms submitted correctly, the dashboard loaded the right data, notifications fired on schedule. I'd clicked through the whole thing more times than I could count, as a user, doing exactly what a user is supposed to do.
What I hadn't done, not once, was open the app with the specific goal of making it misbehave. I'd never tried to see another account's data while logged in as someone else. I'd never tried to hit an internal route without logging in first. I'd never gone looking for a key sitting somewhere it shouldn't be. "Tested thoroughly" meant I'd confirmed the app does what it's supposed to do. It said nothing at all about whether it refuses what it's not supposed to do, and those turned out to be two completely different exercises.
Why that distinction hadn't occurred to me before
Building something and trying to break it require two different mindsets, and switching between them on your own work is genuinely hard. When you're building, every decision is in service of making the feature work. Your brain is optimizing for "does this do the thing." Sitting down afterward and asking "how would I abuse this if I wanted to" requires actively working against the instinct you just spent hours reinforcing. It's not that I was careless. It's that I'd never separated the two questions in my own head.
What I actually did after that call
I opened the app that evening with a genuinely different intention: not to confirm it worked, but to find the place where it didn't hold up. Created two test accounts. Tried to load one account's records while logged in as the other by editing an ID in the request. Opened a private window with no session at all and tried every internal route I could remember building. Grepped the whole repo for anything that looked like a key.
I found one real issue: an internal reporting page that checked whether you were logged in, but never checked whether you were logged in as an admin specifically. Any regular account could reach it by typing the URL. Not catastrophic, but exactly the kind of gap that only shows up when you're actively trying to misuse the thing you built, and invisible to every test that only confirms the happy path.
What changed for me going forward
Now, before I answer "is this secure" with any confidence, I ask myself a more specific question first: have I actually tried to break this on purpose, recently, or am I just remembering that it worked the last time someone used it correctly. Those are not the same evidence, and until that call, I'd been treating them like they were.