Application security lab case studies

crAPI is OWASP's deliberately-vulnerable, realistic vehicle-service SaaS API with real user roles, JWT auth, and a community forum. A close stand-in for the multi-tenant SaaS APIs I test.

An authenticated attacker who owns no vehicles can read any other user's real-time GPS location. The community endpoint leaks other users' email + vehicleid (excessive data exposure); that vehicleid then works on the location endpoint, which never checks ownership.

Any free account can track any other customer's physical location in real time and harvest their email. That's a privacy and physical-safety breach, and all it takes to cross that boundary is a free signup.

The location endpoint authorizes on authentication (a valid JWT) but not on object ownership. It never asks whether the vehicle belongs to the caller. Separately, the community response returns fields the caller has no need to see (email, vehicleid), supplying the id used above.

Enforce server-side ownership on every object lookup: the vehicle's owner must equal the caller, else return 404. Trim the community response to non-sensitive fields only. Add object-level authorization tests to CI.

After applying the ownership check, the cross-user request should return 403 or 404 without location or personal data. The community feed should omit other users' email and vehicle identifiers, while legitimate owner access still succeeds. This section describes the checks to perform; it does not present a captured retest result.

A LangChain ReAct "banking assistant" whose system prompt explicitly says to operate ONLY on the current user's id and refuse any other. It exposes a GetUserTransactions tool. It's a faithful model of the agent/tool boundary I test in AI products.

The tool trusts the id it is handed: it returns another user's transactions without ownership scoping and interpolates that id directly into SQL. The reproduction below calls the tool directly to demonstrate both failures. It does not establish an end-to-end prompt-injection bypass through the conversational agent.

In the self-hosted lab, attacker-controlled tool arguments return another user's transactions and, through SQL injection, the users' stored credentials. The tool therefore needs its own authorization and input handling, independently of the assistant's prompt rules.

The tool derives authority from model/user-controlled arguments instead of the authenticated session, and builds SQL by string interpolation. Model output is treated as trusted input to a privileged data action.

Treat model output as untrusted. Scope the query to the authenticated user server-side and ignore any model-supplied id; parameterize the SQL; require confirmation for sensitive tool actions.

PASSED. With the scoped, parameterized tool the cross-user request returns only the caller's own rows and the injection payload is inert, while legitimate use still works.

Juice Shop is the most widely recognized deliberately-vulnerable web app. This one goes past the exploit to the corrected code, plus a regression test that proves the fix holds.

The login endpoint builds its SQL by string-interpolating the email field. The payload ' OR 1=1-- in the email logs the attacker in as the first user, the administrator, with no valid password.

Full administrator account takeover with no credentials: a single request returns an admin session token (decoded JWT role = admin).

User input (email) is concatenated into the SQL statement, so input can change the query's structure. That's the classic SQL-injection root cause.

Use parameterized queries / an ORM binding so input can never alter SQL structure (e.g. WHERE email = ? AND password = ?). Never interpolate request fields into SQL.

PASSED. A faithful reproduction of the same query shows the injection succeeds before the fix and fails after, while valid login still works and a wrong password is still rejected.