You Don't Have to Take Their Word for It

Here's the bind every non-technical owner is in with security. You can't see it, you can't read the code, and the person telling you it's fine is the same person you'd be checking up on. So mostly people just hope, quietly, because they don't even know what they'd ask instead.

You have more to work with than that. Security isn't a private art known only to your developer. Two of its most important reference points are completely public, and between them they give you a real grip: one is a list your developer should know by heart, and one is a tool you can run yourself in about thirty seconds.

The list the whole industry already uses

There's an organization called OWASP, the Open Worldwide Application Security Project, and its most famous work is the OWASP Top 10: a ranked, public list of the ten most critical ways web applications get attacked. It's built from real-world data across a huge number of applications, it's respected across the entire industry, and it's updated every few years. The current version is the 2025 one, and you can find it at owasp.org/Top10.

You do not need to read it. That's the developer's job, and a good one knows it cold. What you need is one fact and one question.

The fact: the number one risk on that list, again in 2025, is something called broken access control. In plain terms, that's the app failing to properly check whether you're actually allowed to do the thing you're doing, so someone can reach data or actions that should have been off limits to them. If that sounds familiar, it's the same family as a door with no lock. It sits at number one because, in OWASP's own testing, some version of it showed up in essentially every application they looked at. The single most common security failure in the world is an app not checking who's allowed in.

Why a public list changes your position

Here's what the existence of that list actually does for you. Because the risks are published and ranked, "we didn't know about that" stops being an acceptable answer. The whole industry has written down, in order, the things that go wrong. Nobody building web apps for a living gets to be surprised by the top of that list.

So your job isn't to learn the list. It's accountability. You hand your developer one question and you listen to how they answer it: are we covered against the OWASP Top 10, and who specifically owns access control on our app? Someone on top of their work answers easily and specifically. Someone who gets vague or waves it off has just told you something important, without meaning to.

The tool you can run yourself

The second reference point you don't hand to anyone. You use it. It's a free website called Have I Been Pwned, at haveibeenpwned.com, and it does one useful thing: you type in an email address, or your whole domain, and it tells you whether that address has turned up in any known data breach.

Go type in your business email right now. If it comes back clean, good. If it comes back with hits, it means the login details for that address have appeared in a breach somewhere and are circulating, which makes reusing that password anywhere a live risk worth fixing today. You can also verify your domain and switch on monitoring, so you're alerted if any address at your company shows up in a future breach.

One honest caveat, so it doesn't mislead you. This is a smoke detector, not a sprinkler. It tells you a breach happened somewhere, not that your app is secure, and a hit usually means some other site you used got breached rather than your own system. It never shows you an actual password. It's detection, not prevention. But detection you can run yourself, for free, is a rare and genuinely useful thing.

Prevention and detection, in two questions

Put the two together and you've got both ends covered without writing or reading a line of code.

OWASP is the before: are we protected against the known ways this goes wrong? You ask it, and you hold your developer to the answer. Have I Been Pwned is the after: has something already leaked? You check it yourself, and you keep checking.

That's the whole thing. You were never going to become a security expert, and you don't have to. But "I just have to trust them" was never the only option on the table. The industry publishes its standards. The breach data is public. You don't have to take anyone's word for it. You only have to know the two places to look, and pay attention to how freely the answers come.