the 14 things we check before calling a site shipped

Every build we ship gets attacked by us before we call it done. We work through the list below by hand rather than pointing a scanner at it. It's included in the price, because handing over something breakable isn't finished work.

You don't have to be a specialist to walk this with your own developer. If you have a site live right now that has never been checked, it's a reasonable afternoon's work.

Access and identity

1. Can one user reach another user's data by changing a number in the URL? Log in as two accounts and try. This is the single most common serious flaw we find, and it's usually in an invoice, order, or document endpoint that checks you're logged in but never checks who you are.
2. Does the admin area enforce a role check on every route, including the API? Hiding the link isn't a control. Request the admin endpoint directly as a normal user and see what comes back.
3. Do password reset tokens expire, and are they single-use? Request a reset, wait a day, use the old link. Then use it twice.
4. Is multi-factor authentication available on admin accounts, and enforced? Available but optional means off.
5. Does a removed employee lose access everywhere? Run through your last leaver: email, cloud console, git, hosting, database, password manager, third-party dashboards.

Input and output

6. Are database queries parameterised everywhere? Grep for string concatenation in queries. Any hit is a finding until proven otherwise.
7. Is user content escaped when rendered? Post <img src=x onerror=alert(1)> into every field that gets displayed back, including names, notes, and file names.
8. Are file uploads restricted by actual content type, size, and storage location? Extension checks are trivially bypassed. Uploaded files should never be executable and never sit in the web root.
9. Is there rate limiting on login, reset, and any endpoint that sends email or costs money? Without it, credential stuffing and bill-running are free.

Secrets and configuration

10. Are there credentials in the git history? The current files aren't the whole story, so search the history too. If you find one, rotating the key matters more than deleting the commit.
11. Are storage buckets, database ports, and admin panels private? Backups sitting in a public bucket is a classic, and it hands over everything at once.
12. Are error pages generic in production? Stack traces, framework versions, and SQL errors are free reconnaissance.

Transport and dependencies

13. Is HTTPS enforced everywhere, with HSTS, secure cookies, and a sane Content-Security-Policy? Check that the redirect happens on www and bare-domain variants too.
14. Are dependencies current, and is something watching them? Run an audit today, then automate it. Most real-world compromises come through a known vulnerability in a package nobody updated.

And two that aren't on the list but should be

Have you restored from a backup recently? A backup you have never restored is a hypothesis. Test the restore, time it, and write down how long it took.

Do you know who to call at 11pm? Write down, in advance: who cuts access, who talks to customers, who decides whether to take the site offline. The middle of an incident is a bad time to work that out.

What this doesn't cover

This is a pre-launch sanity pass, not a penetration test. It won't find business-logic abuse, chained exploits, or anything that takes sustained creative effort against your specific application, and that's the category most breaches come from. Treat it as the floor, not the ceiling.

When you want the ceiling, our security practice runs full penetration tests with a fixed scope, a report your board can read, and a free retest once you've fixed things. Ask for a scope.