Next.js
The fastest review for a Claude-built Next.js app
A short, practical loop for Next.js apps built with Claude Code: external scan first, then targeted source fixes, then scan again.
· 5 min read
Start with the production URL. Not the repo, not the local dev server, not a screenshot. The deployed URL tells you what headers, redirects, cookies, HTML and public files actually reached the internet — which is frequently not what the code implies.
Scan first, then group by owner
Run an external scan, then group the findings by where they will be fixed rather than by severity. Headers usually live in framework config, proxy code, or hosting rules. Cookie findings live where sessions are set. Exposed-file findings live in public asset handling or deployment packaging. Discoverability findings live in metadata, robots, and response headers.
Grouping this way means one trip into each file instead of five, and it makes the diffs coherent enough to review.
One finding per prompt
Bring Claude Code in with a single finding at a time. Give it the evidence, ask it to find the owning file, and require npx tsc --noEmit, npm run lint and npm run build after the patch.
Small prompts produce safer diffs than one giant security cleanup request. They also fail more usefully — when something breaks, you know exactly which change did it. There is more on prompting agents for security fixes here.
Then scan again
The second scan is the step people skip, and it is the only one that proves anything. A header configured in next.config.ts is a header you intended; a header in the response is a header you have.
The point is not to slow the project down. It is to keep the speed while adding a habit: scan, patch, verify, ship. That habit catches the quiet mistakes vibe-coded apps otherwise carry into production.
Common questions
How often should I scan?
Before every launch, and after any change to headers, hosting, middleware, or deployment configuration. Those are the changes that alter what the public sees without touching what you tested locally.
Why scan the deployed URL rather than localhost?
Because hosting adds, strips and rewrites headers, and your local server is not your CDN. The deployed response is the only one your users and attackers will ever see.
Does a clean scan mean my app is secure?
No. It means a specific list of external mistakes was avoided. Application logic, dependencies, infrastructure and access control are not visible from outside and still need review.
Keep reading
Using Claude Code to fix security findings safely
AI coding agents are strongest when the finding is specific, the desired behaviour is clear, and you ask for verification instead of blind edits.
Vibe-coded apps ship with real security debt
AI-assisted builds still need boring checks. Headers, cookies, exposed files and auth boundaries do not become optional because the first version worked.
Prompting an agent to fix CSP safely
Content Security Policy is powerful and easy to over-tighten. Give your coding agent evidence, constraints, and a verification loop.