Application Security & Secure Code Review

The secure-code-review onsite hands you unfamiliar code and watches what you flag first. Strong reviewers don't memorize CVEs - they recognize a handful of vulnerability classes and trace each one to its root cause in seconds.

A Security Software Engineer at Cursor is a builder who reasons about attack surface fluently. The screens reward pattern recognition: you should look at a line and feel the class it belongs to, then name the fix that kills the whole class rather than the single line. That instinct is what separates a security engineer from a linter.

Almost every web vuln you'll be shown collapses into a small number of families. Learn the root cause and the paved-road fix for each and you can review code you've never seen.

The injection familyuntrusted data crosses into a different interpreter

Injection bugs share one root cause: data the attacker controls gets concatenated into a string that some interpreter then executes - SQL, a shell, an HTTP client, a template engine. The fix is always to keep data as data. Parameterize, don't interpolate.

q = f"SELECT * FROM users WHERE email = '{email}'"   # injectable
cur.execute("SELECT * FROM users WHERE email = %s", (email,))  # safe

XSS and CSRFthe browser-trust pair

XSS runs attacker JavaScript in a victim's session: stored (saved to the DB and served to everyone), reflected (echoed from the request) or DOM-based (client-side code writes untrusted data into the page). CSRF is the inverse - it rides the victim's existing session to make a state-changing request they didn't intend.

Deserialization, path traversal, file handlingtrust placed in bytes from outside

• Insecure deserialization. Feeding attacker bytes to pickle.loads, Java readObject or an unsafe YAML loader can run code during reconstruction. Use data-only formats (JSON) and yaml.safe_load; never deserialize untrusted input into live objects.
• Path traversal. A filename like ../../etc/passwd escapes the intended directory. Resolve the full path and assert it stays inside the allowed root after normalization - don't just strip .., which a double-encode defeats.
• File-handling bugs. Trusting a client-supplied content type or extension, serving uploads from the app origin or unzipping without a size cap (zip bombs). Validate by content, store outside the web root, serve from a sandboxed origin.

Authentication asks "who are you?" Authorization asks "are you allowed to do this?" Most real-world breaches you'll review aren't login bypasses - they're authorization that someone forgot to write.

IDOR is the one you'll be shownbroken object-level authorization

Broken Object-Level Authorization (IDOR) tops the OWASP API list for a reason: the endpoint authenticates you fine, then trusts an ID in the request and skips the check that this user owns that object. GET /api/invoices/1043 returns invoice 1043 whether or not it's yours.

# vulnerable - authenticated, but no ownership check
invoice = db.get(Invoice, request.params.id)
return invoice

# fixed - scope the query to the caller
invoice = db.get(Invoice, id=request.params.id, owner_id=current_user.id)
if invoice is None: raise NotFound()  # don't leak existence

RBAC vs ABAC and centralizing the decisionmake authz hard to forget

The design that survives is one where authorization is a single chokepoint every request flows through - a policy layer, middleware or a can(user, action, resource) helper. Scattered if user.is_admin checks rot: someone adds an endpoint and forgets one. Centralize the decision so the default is deny and forgetting it fails closed.

Sessions, tokens and JWT misusewhere token handling goes wrong

• `alg: none` and algorithm confusion. A verifier that trusts the token's own alg header can be tricked into skipping signature checks or into verifying an RS256 token with the public key used as an HMAC secret. Pin the expected algorithm server-side.
• No expiry or no revocation. Long-lived JWTs can't be recalled once issued. Keep access tokens short and pair them with a server-checked refresh or session, so a stolen token dies quickly.
• Tokens in the wrong place. A JWT in localStorage is reachable by any XSS. Prefer HttpOnly, Secure, SameSite cookies for browser sessions; keep secrets out of URLs and logs.
• Trusting unsigned claims. Authorization decisions must read server-verified claims, never fields the client can edit. is_admin: true in a tampered token is the classic.

The fastest way into a company isn't a clever exploit - it's a leaked key in a git history or a backdoored dependency you installed yourself. Supply-chain and secrets review is high-impact because the failure mode is total.

Secret managementthe rules and how to check them

• No secrets in code or logs. Keys belong in a secrets manager or injected env, never committed and never printed. Grep history, not just HEAD - a removed key is still in the pack files.
• Scope tightly. A token should grant the least it needs (one bucket, read-only, one environment). A broad key turns one leak into full compromise.
• Rotate and make rotation cheap. Rotation only happens if it's a one-command operation. If rotating a key means an outage, it never gets rotated, so design for it up front.
• Detect. Secret scanning on commit and in CI catches the leak before it ships. Assume a secret that ever touched a repo is burned and must be rotated, even after you delete the line.

Dependency and supply-chain riskyour code is mostly other people's code

CI gates as paved-road controlsmake the secure path the default path

The builder-first move is to encode these checks so engineers never have to remember them. Secret scanning and dependency audit run in CI; a finding blocks the merge. The developer gets a clear message at the moment they can fix it, not a ticket three weeks later.

- run: gitleaks detect --no-banner            # block committed secrets
- run: pip-audit --strict                     # block known-vuln deps
- run: cosign verify $IMAGE                    # only signed artifacts deploy

The onsite hands you a few hundred lines of plausible-looking code and a clock. The pros don't read top to bottom - they follow the data, from where untrusted input enters to where it does something dangerous.

Carry one method and narrate it. The reviewers are grading whether you have a repeatable approach that finds real bugs and a habit of pairing each finding with a fix an engineer can apply today.

1. 1Map the entry points. Where does untrusted data enter - routes, request bodies, query params, headers, file uploads, webhooks, message queues? Start at the perimeter.
2. 2Draw the trust boundaries. Mark where data crosses from untrusted to trusted: the auth check, the tenant scoping, the deserializer. Bugs cluster on these lines.
3. 3Follow data to the sinks. Trace each input to where it does something powerful: a DB query, a shell call, a file path, an HTML render, an outbound fetch. An input that reaches a sink unsanitized is a finding.
4. 4Check the controls. At each boundary and sink, is there authn, authz, validation, encoding or escaping? Note what's missing, not just what's present.
5. 5Triage by reachability and impact. Rank what an attacker can actually hit and what they gain. Unauthenticated + high-impact rises to the top.
6. 6Write each finding with a fix. State the vuln, the exact line, the impact in one sentence and a concrete remediation. No remediation, no finding.

Write the finding like a PR commentclear, actionable, non-preachy

A finding that lands is one the author can act on without re-deriving your reasoning. Skip the lecture. Name the bug, show the line, state the impact and give the fix - ideally as a suggested diff.

SSRF - line 42, `fetch(req.body.url)` calls an attacker-controlled URL
with no allowlist, so it can reach internal services and cloud metadata.
Fix: resolve the host, reject private/link-local ranges and allowlist
the handful of domains this integration actually needs.

That framing is exactly how Cursor's own agent-assisted Security Review operates in production: it leaves findings as PR comments and blocks CI on security issues. Reviewing the way the company already reviews is a strong, honest signal that you'd fit the workflow.

Cursor reviews its own code with AI. The agent-assisted Security Review runs on 3,000+ internal PRs a week and has kept hundreds of issues out of production - the flagship responsibility this role exists to build.

Be honest about the public facts and reason from them. Cursor built a dedicated agent-assisted review rather than buying a general scanner, because an off-the-shelf tool couldn't be tuned to the threat model of a company shipping autonomous coding agents. The general lesson is that a security review is only as good as how well it understands what you're actually afraid of.

The agent buys you context, but it introduces a failure mode a static rule doesn't have: it can make things up. That gives you two problems to defend against. False negatives - it misses a real bug - you blunt by running the review in parallel and priming it with specific things to look for. False positives - it invents a bug that isn't there - you blunt with a validation loop, which is exactly why the pipeline below escalates to a human before it enforces anything.

The pipeline, end to endhow a PR becomes a blocked merge

1. 1A PR opens. The change triggers a cloud agent dedicated to security review, separate from the engineer's own Cursor session.
2. 2The agent investigates with a custom security MCPModel Context Protocol. A standard that lets an AI agent pull in context from outside the repo, like Jira tickets or internal docs. tool. A serverless tool gives the agent the context and capabilities it needs to reason about this codebase's threat model, not a generic ruleset.
3. 3Dedup via model classification. A model groups and de-duplicates findings so the same issue across files doesn't spam the author with noise.
4. 4Escalate to humans. Plausible findings go to a Slack channel where the security team validates before anything is enforced - human-in-the-loop, not blind automation.
5. 5Comment and gate. Confirmed findings land as a PR comment with the fix and security findings block CI so they can't reach production.

Layer the controls across the lifecyclein-flight validation, then PR-time, then manual

The PR-time pipeline above is the last gate, not the only one. A practitioner who builds this kind of review describes a layered architecture where each control sits at a different point in the dev lifecycle, so a bug has to get past several checks to ship.

Why block CI on security, not on every nitwhere the friction is worth it

Blocking the build is the strongest, most annoying control you have, so spend it where the cost of shipping the issue is highest. A security vuln in production can mean a breach; a missing test or a style nit can be fixed in the next PR. Gating on security and merely commenting on quality keeps the gate credible - engineers stop respecting a bot that blocks merges over trivia.

The offensive edge: from PoC to exploitwhere agent-driven security is heading

The same workflow that reviews defensively also points toward offensive security. A practitioner working in this space frames it honestly: the agent already finds bugs and writes proof-of-concepts, so there is not a giant leap to having it run that PoC as an actual exploit, and teams are known to be chaining A-to-B-to-C attack paths. His own preference is to lean on perfect visibility of the code and the configuration as the source of truth - if he can get a validated issue straight from code and config, he doesn't necessarily need a live exploit to prove it. The discipline worth copying: don't warranty work you haven't actually done yourself.