Any authenticated user can read/rename/delete ANY other user's habit

This is a full cross-tenant data breach. Habit names, timezones, streaks, and full check-in history are private per-user data -- the project's own README.md calls out "per-user data isolation" as a headline feature, and app/dependencies.py::get_current_habit has a comment explicitly describing the "never reveal a habit exists to someone who doesn't own it" contract. Right now that contract is broken for every route that loads a habit by id: GET, PATCH, DELETE /habits/{id}, and every /checkins route under it. Any logged-in user can enumerate sequential habit ids and read, rename, delete, or check in/out on habits belonging to other people -- this is a textbook Insecure Direct Object Reference (IDOR, OWASP API1:2023 -- "Broken Object Level Authorization"), the single most common API security vulnerability class. In a real deployment this is an incident, not a bug ticket: it needs a security disclosure, not just a changelog line.

get_habit_for_user's docstring still describes the intended contract ("load a habit only if it belongs to user"), but the query itself no longer filters on user_id at all -- it loads any habit by id, regardless of who owns it. app/dependencies.py::get_current_habit, which every habit/check-in route depends on, trusts this function completely.

cd fastapi/habit_tracker source .venv/bin/activate python - <<'PY' from fastapi.testclient import TestClient from app.main import app c = TestClient(app)

c.post("/auth/register", json={"email": "owner@example.com", "password": "supersecret1"}) owner_token = c.post("/auth/login", data={"username": "owner@example.com", "password": "supersecret1"}).json()["access_token"] habit = c.post("/habits", json={"name": "Private Journal", "timezone": "UTC"}, headers={"Authorization": f"Bearer {owner_token}"}).json()

c.post("/auth/register", json={"email": "", "password": "supersecret1"}) intruder_token = c.post("/auth/login", data={"username": "", "password": "supersecret1"}).json()["access_token"]

This is a great illustration of why "return None, caller 404s" access-control patterns are worth being paranoid about: the shape of the code (query → None-check → 404) still looks completely correct at every call site (get_current_habit, every route using it). The bug is entirely inside the one function that's supposed to enforce the boundary, and every caller inherits it silently. Grepping for 403 or "unauthorized" anywhere in this codebase won't find this bug -- you have to actually check which predicate the query filters on.

Compare this function to crud.list_habits a few lines above it, which correctly scopes by user_id. The fix is about restoring exactly one missing predicate -- resist the urge to add extra defenses (e.g. re-checking ownership again in every route) instead of fixing the one choke point this function exists to be.