Run a 30-minute review in six timed blocks: scope, authentication, data access, dependencies, secrets and deployment settings. End with one of three verdicts: pass, fix then pass, or not ready. The goal is to find the common serious problems quickly, not to certify the code.
Before you start
Bring the repository, a running copy with test accounts, and the owner of the prototype. Agree up front that the output is a short list of findings with owners and dates.
The six blocks
Minutes 0 to 5: Scope. What does the prototype do, who will use it, what data does it read and write, and what can it call? Write the answers down. If the data includes anything sensitive, the review should be longer than thirty minutes.
Minutes 5 to 10: Authentication. Can you reach any page or endpoint without logging in? Try each route from a private browser window. Check how sessions are stored. MDN notes that a cookie with the HttpOnly attribute cannot be read by JavaScript and one with Secure is only sent over HTTPS, so look at how the app sets its session cookie.
Minutes 10 to 15: Data access. With two test users, request each other's records by changing the id. OWASP lists broken object level authorization as the first item in its API Security Top 10 and notes that object ids can be sequential integers, UUIDs or strings, so do not assume unguessable ids are enough.
Minutes 15 to 20: Dependencies. List direct packages. Is each one needed? Are they pinned in a lockfile? Run your scanner and look at anything high severity that the app can actually reach.
Minutes 20 to 25: Secrets. Search the repository, the history and the built output for keys. Check that environment files are ignored and that no secret sits in a browser-exposed variable.
Minutes 25 to 30: Deployment. Where does it run, who can reach it, what permissions does its service account have, and are debug modes off? Is there logging, and does it avoid personal data?
The verdict
| Verdict | Meaning | Next step |
|---|---|---|
| Pass | No serious findings | Proceed, with owner and gates in place |
| Fix then pass | Findings with clear fixes | Fix, then a short re-check |
| Not ready | Missing auth, exposed secrets or unclear data handling | Return to prototype tier |
Keep the output useful
Record findings in the pull request or tracker with a severity, an owner and a date. Do not write long reports. Keep the checklist in the repository and improve it after every review.
Where Safeguard fits
For the dependency block, Safeguard offers dependency scanning, reachability analysis to see what is actually called, and policies and gates for pull requests. A free scan is available at gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how many findings drop away when only reachable code counts.
Quick check
Is 30 minutes really enough?
For a small prototype with no sensitive data, it catches the common serious issues. Anything handling sensitive data or payments needs a deeper review.
Who should lead the review?
Someone other than the author, ideally with security or senior engineering experience, with the author present to answer questions.
Sources
Last reviewed: 19 October 2026.
