Security answer
AI-generated code can introduce insecure defaults, weak validation, secret leaks, outdated APIs, or missing authorization checks.
Treat generated code as an untrusted patch
Security + AI coding is a current concern with strong practical value.
Where plausible code becomes dangerous
The dangerous part is not copy-paste itself. The dangerous part is copy-paste without threat modeling or understanding.
| Area | Risk to check |
|---|---|
| Auth | Missing authorization, not only authentication |
| Database | Injection or unsafe query building |
| Secrets | Hardcoded keys or logs |
| Files | Path traversal and unsafe uploads |
Review an authentication helper
Security review question:
What can an untrusted user control here,
and what happens if they control it maliciously?
This example is intentionally small. In a real codebase, the surrounding details matter: naming, error handling, tests, runtime config, permissions, and how easy the next developer can understand the change.
Use tests to challenge the happy path
- Check input validation.
- Check authorization on every sensitive action.
- Search for hardcoded secrets.
- Review database query construction.
- Add tests for forbidden access.
Warning signs people overlook
- Trusting code because it looks idiomatic.
- Checking login but not permissions.
- Logging tokens for debugging.
- Using outdated packages from generated examples.
- Not asking what an attacker controls.
State the review work you performed
Use a concrete sentence:
I used this pattern because [problem]. The main tradeoff was [tradeoff]. I verified it by [test or check].
That structure works because it shows judgment. Anyone can name a tool. Strong developers explain why they chose it, what could go wrong, and how they checked the result.
Related AI coding guides
- ai generated code review checklist developers
- webhook signature verification nodejs
- jwt vs sessions nodejs auth choice
Security references
The final responsibility stays human
AI-generated code can introduce insecure defaults, weak validation, secret leaks, outdated APIs, or missing authorization checks. Keep the implementation small, verify the edge cases, and write the decision down so the next person can trust it.
Review the dependency and permission surface
Generated code can be syntactically correct while quietly increasing authority. Before running it, inspect new packages, install scripts, filesystem access, network destinations, environment-variable reads, and shell commands. A misspelled package name or unnecessary SDK can create more risk than the function you asked the model to write.
For a backend repository, review the patch without secrets in the environment:
git diff --stat
git diff -- package.json package-lock.json
npm ci --ignore-scripts
npm audit --omit=dev
npm test
These commands are not a complete security review. They make the changed surface visible before you grant the code normal development credentials.
In CryptoEx, an AI-generated withdrawal handler that “checks the balance and then creates a transfer” may miss the race between those operations. The dangerous part is not style; it is the missing transaction, idempotency identity, and durable uniqueness constraint. A reviewer needs the workflow invariant before evaluating the generated implementation.
Challenge the patch with negative cases
Ask what happens when authorization is absent, input is oversized, a dependency times out after accepting work, the same request arrives twice, or logs contain a token. Write at least one failing test before accepting a security-sensitive fix. If you cannot explain why the test protects the system, you do not yet understand enough to merge the patch.
Questions before accepting generated code
What new authority does the patch gain? Which inputs can an attacker control? What happens on duplicate delivery, timeout, partial success, or missing authorization? Did the model add dependencies or network calls that were not requested? Can you explain every changed branch without asking the model again?
If the answer to the last question is no, keep the patch out of the main branch. Use it as a draft, reduce it to a smaller change, and write tests until the behavior is yours to defend.
Discussion
What would you try, change, or challenge after reading this guide? Specific results and errors help the next reader.
Comments will load as you reach this section.