Deleting your own expense can delete someone else's too

Nobody has started this yet — be first.

Business impact

This is the worst possible category of bug for a financial-records product: silent, irreversible data loss across account boundaries. Any authenticated user who deletes any one of their own expenses will, in the same request, also delete every other expense they own -- and far worse, if they know or guess another user's expense id (sequential integer ids, trivially guessable), a single DELETE call against that id deletes that stranger's expense too, with no ownership check actually stopping it. A user reports "all my expenses vanished after I deleted one" -- that's this bug, and there is no undo.

Problem

Repo.Delete's SQL is DELETE FROM expenses WHERE id = $1 OR user_id = $2 -- the AND that's supposed to scope deletion to "this specific row, and only if it's mine" has become an OR, so the WHERE clause matches (a) the row with that exact id, regardless of owner, unioned with (b) every single row owned by the caller, regardless of which id was requested.

Current behavior

Deleting one of your own expenses deletes every expense you own, and deleting an expense id that belongs to a different user succeeds anyway, wiping out that stranger's row too.

Expected behavior

WHERE id = $1 AND user_id = $2 -- deletes at most one row, and only if it is both the requested id and owned by the caller.

Steps to reproduce

As user A, create two expenses (ids e1, e2). As user A, DELETE /expenses/{e1} (intending to delete just e1). Check: does e2 still exist? It shouldn't have been touched -- but it's gone too. Separately: as user B (with no expenses of their own), DELETE /expenses/{e1's id} using an id you know belongs to user A.

The call succeeds and A's expense is deleted, despite B never owning it.

Why this matters

This is the exact "operator flip" class of bug this whole project exists to catch -- the SQL WHERE clause is the single enforcement point for ownership (by this project's own design), so getting the boolean operator between "which row" and "who owns it" wrong doesn't just fail to protect the boundary, it makes a single-row delete potentially multi-row and cross-account, silently, with no error of any kind (a matched-many-rows DELETE isn't itself an error in Postgres).

Suggested approach

Compare Repo.Delete's WHERE clause against Repo.Get and Repo.Update in the very same file -- both correctly use the identical id = $.. AND user_id = $.. shape a few lines above and below this function.

Acceptance criteria

Deleting your own expense by id removes exactly that one row and no others.
A delete/get/update request for another user's expense id returns 404 and leaves that row completely untouched.
Deleting one of your own expenses does not affect any of your other expenses.

Verification

go test ./practicetickets/... -run TestTicket09 -v

Hints (0/2)

Try it without hints first — the reading is the exercise.

Working on this ticket

Work on a branch named for the ticket — that's what you'll submit.

Branch off your fork

$git checkout -b fix/expense-delete-or-vs-and

Fix it and commit

Meet every acceptance criterion, and add a test that would have caught this.

Push the branch

$git push -u origin fix/expense-delete-or-vs-and

Submit it below

Paste your fork URL and the branch name, with a short write-up of the root cause.

Submit your fix

Questions

Stuck on something?

Ask about anything unclear in the ticket — the maintainer and anyone who has solved it can answer. Please don't post full solutions.

No questions yet. If something in this ticket reads ambiguously, you are probably not the only one — ask.

The project

Expense Tracker — SQL-Enforced Multi-User Isolation

A production-style multi-user expense tracker in Go where the authorization boundary between one user's financial data and everyone else's is a literal SQL `WHERE id = $1 AND user_id = $2` clause -- not an application-layer check -- so a single flipped operator or dropped predicate is a real, silent cross-account data breach, not a cosmetic bug.

Fork on GitHub

Download

Setup

Expense Tracker — SQL-Enforced Multi-User Isolation

git clone <your-fork>
cd expense_tracker
docker compose up --build   # postgres (host port 5434) + app (host port 8082)

auto-applies on first boot via Postgres's mechanism, seeding the seven global default categories (ids 1-7). The compose project is named , so it won't collide with sibling projects on the same machine. Health-check on gates 's startup so the API never starts before the schema exists.