AI coding tools/Cursor
Cursor produces working code reliably; whether it produces safe code depends entirely on review. Because it edits across a whole repository, a single prompt can introduce the same weak pattern in several files at once. The recurring findings are hardcoded credentials, authorisation checks that exist only on the client, and database queries built by string concatenation.
Cursor is an AI-first code editor that reads and edits an entire repository. Cursor works across a whole codebase rather than a single file, so its changes land in many places at once and are reviewed as a batch — or not reviewed at all.
These are patterns we look for in code produced this way — not flaws in Cursor itself. Each names the check that finds it.
Cursor's advantage is repository-wide context, and that is also the risk: asked to add a feature, it will follow the pattern it inferred from your existing code. If that pattern was already weak — an unparameterised query, an unvalidated body — it gets propagated rather than corrected, and a reviewer skimming a large diff sees consistency and reads it as correctness.
Detected by: Unparameterized database query
Connecting a new API mid-session is where keys get pasted directly into source to make something work, with the intention of moving them to environment variables later. That intention does not survive the next prompt, and the key is then in git history permanently.
Detected by: Hardcoded API key or secret
Asked to make a page admin-only, an assistant will frequently satisfy the request in the component — hiding the control, redirecting the route — while the underlying API handler stays open to anyone who calls it directly. The feature looks correct in the browser and is not enforced anywhere.
Detected by: Unvalidated request input
Long editing sessions leave diagnostic logging behind. When the value being logged is a token, a session or a request body, that data ends up in whatever aggregates your production logs, and log stores are rarely held to the same access standard as the database.
Detected by: console.log with sensitive data
Every check named above runs automatically. Free on public repositories, no signup, results in under three minutes — with the file and line for each finding.
Yes, with review. Cursor is a capable editor and the concern is not the tool but unreviewed output. Treat its changes the way you would treat a pull request from a fast, confident contributor who does not know your threat model: read the diff, test the authorisation, and scan for credentials before merging.
Exposed credentials, by a wide margin. They enter the codebase during the session that wires up a service and are rarely removed afterwards. GitGuardian found 35% of private repositories contain at least one plaintext secret, and AI-assisted development adds credentials faster than review removes them.
Git history is the honest record, not memory of the session. Diff the branch against its base and read every changed file, paying particular attention to files you did not expect to be touched — repository-wide edits are exactly where unreviewed changes hide.
No. It pattern-matches against code it has seen, without a model of your threat surface, your compliance obligations or your data sensitivity. The output is a plausible completion, not a security decision, and it should be reviewed as such.