A plain-English website and app security checklist for small businesses

Most small-business sites don't get hacked by a genius in a hoodie. They get hacked because a plugin was two years out of date, because a former freelancer still had an admin login, or because a backup file was sitting in a public folder with the database password inside.

The good news is that the boring stuff is also the fixable stuff. This checklist is the version we'd hand to a friend who runs a shop, a booking site or a small app and has no idea where to begin. Grab a coffee and work through it. Anything you can't answer is already useful information.

1. Who can get in?

Start with people, because accounts are the front door. A strong lock doesn't help if you've handed out too many keys.

1. List every account that can change your site. Hosting, domain registrar, CMS or admin panel, app stores, email, payment provider. If you can't produce the list in ten minutes, that's your first finding.
2. Remove anyone who doesn't need access today. Past developers, agencies, interns and that one contractor from 2021. Delete the account instead of just changing the password.
3. Turn on two-step login everywhere it's offered, starting with email, the domain registrar and hosting. Whoever controls your email can reset almost every other password.
4. Stop sharing one login. If three people use the same admin account, you can't tell who did what, and you can't remove one person without changing it for everyone.
5. Check passwords against known leaks. Paste your work email into Have I Been Pwned and change anything that shows up. A password manager makes long, unique passwords painless.

2. Is everything up to date?

Old software is the most common way in, because attackers don't need to find new flaws when published ones still work.

1. Know your versions. Which CMS, which plugins or themes, which PHP or Node version, which app libraries. Write them down once.
2. Update plugins, themes and libraries on a schedule, not when you remember. Monthly is a sensible default; critical security fixes shouldn't wait.
3. Delete what you don't use. An inactive plugin still sits on your server and can still be attacked. Fewer things installed means fewer things to patch.
4. Check your server language is still supported. If you run PHP, look at the supported versions page. Versions past their end-of-life date get no security fixes at all.

Running PHP and seeing odd errors on screen? That's worth fixing too. Our guide to common PHP errors explains what each one means.

3. Is your connection and setup locked down?

1. Every page loads over HTTPS, and http:// redirects to https://. Test both, including the www and non-www versions.
2. Run your domain through [SSL Labs](https://www.ssllabs.com/ssltest/). You're looking for a good grade and no warnings about old protocols.
3. Check your security headers with a free scanner such as securityheaders.com. The ones that matter most for a typical site are Strict-Transport-Security, X-Content-Type-Options and a framing rule (frame-ancestors or X-Frame-Options) so nobody can embed your site inside theirs.
4. Lock your domain. Ask your registrar to enable a transfer lock and make sure its account has two-step login. Losing a domain is one of the most painful and least recoverable mistakes.
5. Look at your DNS records for anything you don't recognise, especially old subdomains pointing at services you stopped paying for.

4. Is anything sitting where it shouldn't?

This is the section people are most surprised by. Files meant for you end up public all the time.

1. Try a few addresses on your own site: /.env, /.git/config, /backup.zip, /phpinfo.php. Each one should return a "not found" or "forbidden" page. If any of them shows content, treat it as an emergency. We wrote a full walkthrough on exposed .env files and leaked keys.
2. Make sure folders don't list their contents. Visit a folder URL such as /uploads/ and check you don't get a file list.
3. Find your admin pages (/admin, /wp-admin, /login). They don't have to be secret, but they should require a strong login, ideally with two-step verification and a limit on failed attempts.
4. Search for leftovers: old staging sites, "test" subdomains, and copies like site-old or v2-backup. If it's still online, it's still attackable.

5. Do your forms and logins fight back?

1. Try ten wrong passwords in a row on your own login. If nothing slows you down or locks you out, an attacker can guess all day. This one is surprisingly common, and it's a real finding in many audits.
2. Submit your contact form with silly input, such as a very long message, special characters and an empty required field. It should show a clear error and keep what you typed.
3. Check you receive form messages, and that spam doesn't flood you. A simple honeypot field or a privacy-friendly challenge helps.
4. Look at what error messages reveal. "Wrong password" is fine. A page full of file paths and database details is not.

6. Can you recover from a bad day?

1. Have automatic backups of both files and database. A decent rule of thumb is three copies, on two kinds of storage, with one kept somewhere else.
2. Restore one. A backup you've never restored is a hope, not a plan. Try it on a test copy once and time how long it takes.
3. Know who to call. Write down who handles hosting, the domain, and the developer who can fix things, along with how to reach each of them out of hours.

7. What else runs on your pages?

1. List every third-party script: analytics, chat widgets, ad pixels, fonts, booking tools. Each one runs with the same power as your own code.
2. Remove the ones nobody uses. They slow the site down and widen the target.
3. For mobile apps, update your SDKs and check that no secret keys are bundled inside the app. Anything shipped in the app file can be pulled out by anyone who wants to.

A quick way to score yourself

Count how many of the 28 items you could answer confidently without looking anything up. Twenty or more means you're in better shape than most small businesses. Under fourteen means there's likely something exposed, and it's cheaper to find it now than after a customer reports it.

What a checklist can't do

Everything above is visible from the outside or from your account settings. It won't tell you whether the checkout works on an older iPhone, whether your own code builds database queries safely, or whether one particular page quietly leaks customer details. Those need someone to test the real thing, on real devices, with a trained eye.

That's the gap our audit fills. You send us the link, we test your live app or site, and you get a report that ranks every issue by priority with a plain-English fix for each.