Web Application Security for Business Owners

What actually happens

Businesses are rarely breached by novel techniques. They are breached because a dependency had a known vulnerability nobody patched, because a user could reach data they should not have, or because a credential ended up somewhere public.

That is encouraging, because all three are addressable with process rather than genius.

The five that cover most risk

1. Keep dependencies current. Automated alerts, a monthly update cycle, no exceptions for “working” libraries.
2. Check permissions on every request. Not just in the interface — on the server, every time, for every record.
3. Keep secrets out of the codebase. Environment variables or a secret manager, and rotate anything that has ever been committed.
4. Parameterise every query. Injection is thirty years old and still on every top-ten list.
5. Test your backups by restoring one. An untested backup is a hypothesis.

The commonest real-world flaw we find in application reviews is not exotic. It is a page that checks whether you are logged in, and forgets to check whether the record belongs to you.

Access control is where the interesting bugs live

The pattern is always the same: a user requests a record by its identifier, and the server returns it without checking whether that user should see it. Change the number in the URL and you are reading someone else's invoice.

• Every request re-checks ownership on the server, not in the client
• Identifiers that are hard to guess, as a second layer rather than the first
• Deny by default; grant explicitly
• Automated tests that assert a user cannot reach another user's data

What to ask your developer

1. How do we find out about vulnerable dependencies, and how often are they updated?
2. Where are our secrets stored, and who can read them?
3. How is it verified that one customer cannot see another's data?
4. When did we last restore a backup, and how long did it take?
5. Who has production access, and how is it removed when someone leaves?

You do not need to evaluate the technical answer. A supplier who answers all five specifically is in control; one who answers vaguely is not, and that is the information you were after.

Things worth buying, and things not

Preparing for the bad day

Assume something will go wrong and decide now who does what. Who is called, who can take the system offline, who talks to customers, where the backups are and how long a restore takes.

One page, agreed in advance, and reviewed once a year. The businesses that handle incidents well are not the ones with better security — they are the ones who had already decided who makes the decisions.

Frequently asked questions