A Non-Developer's Guide to Knowing If Your Website Is Secure
You don't need to read code to sanity-check your own site's security. Here's a plain-language checklist covering the things that actually matter for a small business site.
Most business owners can't audit their own website's code, and shouldn't have to. But there are a handful of things you can check yourself in five minutes, without touching a line of code, that catch the most common problems.
The five-minute checklist
- Does the address bar show a padlock / `https://`? If any page — especially a login or a form — loads as plain
http://, anything typed into it can be intercepted in transit. This should be automatic on any modern host; if it's missing, that's a real problem, not a cosmetic one. - Can you log into the admin area from a random public wifi and it still feels "normal"? No warning about an insecure connection, no browser flag. That's expected — but if your login page has no rate limiting, an attacker can guess passwords all day without being slowed down. You can't check this yourself easily, but it's worth asking whoever built the site directly.
- Try submitting a contact form with obvious garbage. Random symbols, a fake email, an empty name field where one's required. A well-built form either rejects it cleanly or handles it without erroring out. If it crashes the page or emails you something clearly broken, that's a sign of thin input handling — the same category of gap that, in a worse form, becomes a real vulnerability like SQL injection.
- Does your staff share one login, or does each person have their own? Shared credentials mean you can't tell who did what, and you can't revoke access for one person without changing it for everyone. Per-person logins with an audit trail (who did what, when) should be table stakes for anything with an admin area — here's what that actually looks like in practice.
- When was the site last updated? Not redesigned — updated. If a site runs on WordPress or another plugin-based platform and nobody's applied an update in a year, that's accumulated risk, not stability.
What you genuinely can't check yourself
- Whether the backend properly validates and escapes input before it touches a database.
- Whether secrets (API keys, database passwords) are stored safely or sitting in a file that could leak.
- Whether dependencies have known vulnerabilities.
These aren't things a checklist replaces — they need someone who can actually read the code. That's fine; the point of the checklist above isn't to make you a security auditor, it's to give you enough signal to know when it's worth asking for one.
If something on this list doesn't check out
That's not a reason to panic — most of it is fixable without a rebuild. It is a reason to get someone to look. See how I approach security-minded development, or reach out if you want a second opinion on a specific site.