// Security by tool
Security for code generated with Cursor
Quick answer
Cursor generates the code you ask for, and without explicit instruction it writes the functional flow, not the secure one. The pattern that shows up most: the CRUD endpoint checks that you are logged in, but not that the resource is yours, the classic BOLA/IDOR. Alongside come JWT without signature validation, weak sessions, client-only authorization and skipped server-side validation.
It is not just the generated code: Cursor itself had CVE-2026-50548 and 50549 (DuneSlide), zero-click prompt injection that escapes the sandbox and executes code on the machine, CVSS 9.8. So the review has two axes: what Cursor wrote in your app, and how you configure Cursor itself.
What Cursor tends to generate wrong
The blind spot is always the same: the AI writes the feature and stops. It rarely adds the owner check, the input validation, the escaping. You have to ask, or review afterwards.
| Hole | Why it happens | Impact |
|---|---|---|
| Checks login, skips ownership | Endpoint validates session but not the resource owner | BOLA/IDOR: user reads another’s data |
| JWT without signature validation | Token decoded but not verified | Forged token accepted |
| Unsanitized input | Handler trusts user data | SQL injection / XSS / command injection |
| Authorization only on the client | Access rule on the screen, not the server | Bypass by changing the call |
How RET reviews Cursor code
RET takes the endpoints that touch data and tests ownership: logged in as user A, can I read/edit user B’s resource? It checks JWT signature validation, input sanitization and whether authorization lives on the server. And it reviews the Cursor configuration (agent permissions, MCP, execution) because of the RCE CVEs.
Since the problem is usually access logic, the natural path is Risk Review: a human read of 1 to 3 flows, exactly where IDOR hides.
- Ownership test endpoint by endpoint (does A reach B’s data?).
- JWT validation, session and input sanitization check.
- Review of Cursor’s own config (agent, MCP, permissions).
You may already be exposed if
Signals that call for a review in Cursor-generated code:
- Your endpoints check login but you never verified they check the data owner.
- You use JWT and do not know if the signature is validated.
- Plan/resource access rules live only in the frontend.
- You run Cursor with an agent/MCP without reviewing execution permissions.
Frequently asked questions
What is IDOR/BOLA and why does Cursor generate it?
It is when the endpoint checks that you are logged in but not that the requested resource is yours, so by changing an id you reach another user’s data. Cursor generates it this way because it writes the functional flow (fetch the resource by id) and does not add the owner check unless you ask.
Should I worry about the security of Cursor itself?
Yes. CVE-2026-50548/50549 (DuneSlide) allow zero-click prompt injection with code execution on the machine, CVSS 9.8. It is worth keeping it updated and reviewing agent, MCP and auto-execution permissions, not just the code it generates.
Does a scanner find these holes?
A scanner finds little IDOR/BOLA because it is a business-logic flaw: it does not know that id should belong to the owner. That is why a human review (Risk Review) is the right path for this kind of hole.
Who runs the review at RET?
Gabriel Lima Ferreira, founder and lead pentester, with authorization and a tight scope.