Cursor app security review

How to review an app written with Cursor (or Claude Code, Windsurf, Copilot) for the mistakes an editor agent makes when nobody asks the security question.

Cursor is not a template. It writes whatever stack you ask for, so a Cursor-built app can be a Next.js and Prisma project, a FastAPI service, an Express API, a SvelteKit app on Cloudflare. What the projects have in common is how they were written: feature by feature, in prompts that describe the happy path. Authorization, limits and secret handling are not part of the happy path, so they are added only when the prompt says so. This review reads the code for the places where that shows.

Read the rules files first

.cursor/rules, .cursorrules, CLAUDE.md, and AGENTS.md are instructions to the agent. They tell you what the author cared about and what they did not. If none of them mention auth, validation or secrets, assume every route was written without them. Also check that nothing in these files was pasted from an untrusted source: an instruction file that tells the agent to disable checks or add a dependency is a supply-chain problem.

Authorization on every handler

• List every route handler, server action, tRPC procedure, or view. For each one that takes an id, find the line that checks the caller owns that record. If the check is missing, that is an IDOR. Editor agents copy the pattern from the first route they wrote; if that one was public, they all are.
• Server actions in Next.js are POST endpoints callable by anyone. A "use server" file with a function that deletes or updates by id needs the same auth check as an API route.
• Middleware-only auth: if the app relies on middleware.ts to protect paths, check the matcher covers the API routes and the actions, not only the pages.
• Admin: find how "admin" is decided. A role read from the session is fine; a role read from a request header, a cookie the client sets, or a query parameter is not.

Input and queries

• Raw SQL: prisma.$queryRawUnsafe, template strings passed to db.execute, Python f-strings in cursor.execute. Each needs parameters, not interpolation.
• Mass assignment: a handler that spreads req.body into an update lets the client set any column, including role or credits. Allow-list the fields.
• File uploads: path built from a user-supplied filename, no size limit, no type check.
• Redirects built from a next or returnTo parameter without an allow-list.

Secrets

• git log -p for keys: agents fix a leaked key by deleting the line, not by rotating it. The commit is still there.
• Client-visible variables (NEXT_PUBLIC_, VITE_, EXPO_PUBLIC_) with secret-looking names.
• Hard-coded fallbacks such as process.env.JWT_SECRET || "secret". The fallback is the value in production when the variable is unset.

Payments, AI, limits

Prices from the client, webhooks without signature checks, AI routes without auth or quota, and no rate limit on login and signup are the same on every stack; the checklist has the exact questions. A Cursor-specific note: when asked for "a rate limiter", agents often write an in-memory map. On serverless it resets every cold start and protects nothing. Use the platform's store (Redis, KV, the database).

Errors and logging

Agents like to return error.message and sometimes the whole error to the client. Check the catch blocks in the handlers. Check the logger for request bodies that contain passwords or tokens.

Dependencies and CI

Run the audit for your package manager. Read the GitHub Actions workflows: a job triggered by pull_request_target that checks out the PR and has production secrets in its environment hands those secrets to anyone who opens a pull request.

When you want it done for you

Repo Review is a static review of your repository: every item above and the full seven-area checklist, read in your code and judged reachable or not, with the file and line and a fix snippet for each finding. HTML and PDF report within 48 hours, from $79. See the sample report first.

Order a review, from $79 How it works