Also published on Substack on 2026-10-13.
Security reviews don’t have to be long to be useful. Most of the API vulnerabilities I’ve seen in production weren’t exotic. They were simple mistakes that slipped through code review because nobody asked the right question at the right moment.
So I keep a short checklist and run it on every pull request that adds or changes an endpoint. It takes about two minutes.
1. Who can call this?
Is authentication enforced on the route itself, or only in the frontend that normally calls it? Hiding a button is not access control. If the endpoint exists, assume someone will call it directly.
2. Can user A access user B’s data by changing an ID?
This is the one that matters most. If a request includes an order ID, account ID or document ID, the server has to check that the current user actually owns or is allowed to see that record. Insecure direct object references are easy to introduce and easy to miss, and this single question catches more real bugs than any scanner I’ve used.
3. What’s in the response?
Are we returning fields the client doesn’t need? Internal IDs, emails of other users, password hashes, internal flags and full database rows often end up in responses because serialising the whole object was the quickest thing to do. Return only what the client uses.
4. What happens with bad input?
Huge payloads, wrong types, missing fields, unexpected nesting, negative numbers, very long strings. Validation should happen at the edge, with clear limits, before the data reaches business logic or the database.
5. Does the error message leak internals?
Stack traces, SQL fragments, file paths, library versions and internal hostnames in error responses give attackers a map of your system. Log the details on the server. Return a generic message to the client.
6. Is there rate limiting on anything expensive or sensitive?
Login, password reset, OTP verification, search, exports, anything that sends emails or SMS, and anything that calls a paid third-party API. Without limits, these become targets for brute force, enumeration and cost attacks.
7. Is this endpoint temporary?
“Temporary” debug routes, quick admin helpers and migration endpoints have a habit of becoming permanent. If it’s temporary, write down when it gets removed, and who’s responsible for removing it.
Why a checklist works
Checklists work because they move security from “something a reviewer might think of” to “something every reviewer asks.” They don’t replace deeper reviews, threat modelling or testing. But they catch the common mistakes cheaply and consistently, which is where most real incidents start.
Copy this into your pull request template, adapt it to your stack, and run it on your next review.