What to require from a team building your backend

This is written for the person commissioning a build rather than writing it. If you are the engineer, the companion guide — Laravel security: the rules that actually get broken — is the concrete version of the same subject.

The difficulty with backend security is that it is invisible while it is working. Nothing on a demo tells you whether the team building your system has handled it, and by the time it becomes visible the cost is no longer a development cost. So it has to be asked about deliberately, and the questions below are the ones that actually separate teams.

Ask what happens on an error in production

A misconfigured application answers an unexpected error by displaying its own configuration — database passwords, third-party keys — to whoever triggered it. Triggering it does not require an attacker; a mistyped URL will do.

A team that has considered this will tell you immediately how errors surface in production, where they are logged, and who sees them. Hesitation here is informative.

Ask how one user is prevented from reading another's data

This is the most common serious flaw in real systems, and it is worth understanding why. Checking that someone is logged in is easy and gets done. Checking that this particular logged-in user is allowed to see this particular record is a separate check, and it is the one that gets missed.

When it is missed, changing a number in a URL returns somebody else's information. Ask specifically: not “is it behind a login”, but “what stops a logged-in customer reading another customer's record”.

Ask where secrets live

Credentials belong in a secrets manager or environment configuration excluded from version control — never committed alongside the code, and never shared across environments. If a staging system and the live one share encryption keys, access to staging is effectively access to production.

Ask what is reachable that should not be

Development and monitoring tools are enormously useful and routinely left switched on after launch. Some record full request contents — including passwords and one-time codes — and serve them over the web. Others allow queued work to be retried or deleted by anyone who finds the page.

There should be a post-deployment check confirming those routes are unreachable. Ask whether one exists and whether it runs every time.

Ask about the boring operational things

• Uploads — are private files actually private, or merely at an address nobody has guessed?
• Logging — is there a rule against writing passwords, tokens and card numbers into logs? Logs get shipped to third parties and pasted into support tickets.
• Rate limiting — on login, and on anything expensive to run.
• Dependencies — how are third-party packages kept current, and who notices when one has a published vulnerability?
• Administrator accounts — do they carry stronger requirements than ordinary users, given they can read everyone's data?

Ask what happens when something goes wrong

A team that has thought about incidents can answer three questions without preparing: how would we find out, who is responsible for responding, and what would we be able to reconstruct afterwards from the logs.

Nobody expects a rehearsed plan on a small build. The value is in whether the questions have been considered at all, because a team that has considered them has usually also built the things that make the answers possible.

What good looks like

You are not looking for a supplier who claims their system is secure. That claim cannot be verified and should be treated with suspicion. You are looking for one who describes their standard — what is checked, when, and by whom — and can show you the checklist rather than describe it.

The difference between the two is close to the whole of it. Security in a delivered system is not a feature that was added; it is a set of defaults that were never switched off, and a list somebody ran before every release.