mediumScenarioCodingMidSeniorStaff
You are handed 200 lines of AI-generated code in an interview and told some of it is exploitable. Where do you look first?
Start a secure code review of AI-generated code at the trust boundaries, not at line one. Find where untrusted input enters and where it reaches a query, a shell, a file path or an authorisation decision, then check what is missing between them as hard as what is present.
5 min readUpdated 2026-10-09
Answer
Short answer
Look at the trust boundaries first. A secure code review of 200 lines starts by listing where untrusted input enters (route parameters, headers, uploaded files, deserialised bodies) and where it lands somewhere dangerous: a query, a shell, a file path, a template, a redirect, an authorisation decision. Then check the path between each pair. With AI-generated code, give as much attention to what is missing — an ownership check, a size limit — as to what is written wrongly.
Was this answer helpful?
Likely follow-ups
- The file uses an ORM everywhere except one raw query. Why is that the line you spend your time on?
- How would you convince the interviewer the ownership bug is exploitable without running the code?
- Which of your findings would a static analyser flag, and which would it never see?
- If the generated code had come with its own tests, how much would they change where you look?
Related questions
- You are told there is a memory-safety bug somewhere in a large C or C++ codebase, and you cannot read all of it. How do you narrow the search?hardAlso on appsec5 min
- Walk me through applying STRIDE to the boundary where our order service calls the payments service over the network.mediumAlso on appsec4 min
- Your vulnerability scanner just reported four thousand findings across the codebase. How do you actually triage that?mediumAlso on appsec3 min
- Your WAF starts blocking legitimate checkout traffic during a sale. How do you tell an attack from a spike, live?hardAlso on appsec5 min