Search treats literal %/_ in the query as SQL wildcards

Any user whose search term happens to contain a % or _ character (price tags like "50% off", filenames like "report_v2", usernames, version strings, etc.) gets search results that make no logical sense -- either far too many notes match (a % in the query silently turns into "match anything"), or a search returns a note that doesn't actually contain what was typed (a _ matches any single character). This is subtle enough that it usually isn't caught by manual testing, but once it ships, it's confusing and hard for an end user to describe precisely -- "search is broken" bug reports that are actually hard to reproduce without knowing to suspect LIKE wildcards specifically. Unlike the other bugs in this set, this one was not deliberately injected -- it was found already present in the untouched codebase during a real audit, which is exactly why it earns a higher priority than its documented "Medium" label: it is live, unstaged, and shipping right now.

list_notes builds a SQL LIKE pattern directly from user input: like = f"%{q}%". SQL's LIKE operator treats % as "any sequence of characters" and _ as "any single character" everywhere in the pattern, including inside the part that came from q itself. The code never escapes those two characters in the user-supplied search term before building the pattern.

cd fastapi/notes_api source .venv/bin/activate uvicorn app.main:app --reload & curl -s -X POST http://127.0.0.1:8000/notes -H "Content-Type: application/json"
-d '{"title":"Discount code: 50% off","content":"Discount code: 50% off"}' curl -s -X POST http://127.0.0.1:8000/notes -H "Content-Type: application/json"
-d '{"title":"I saved exactly 50 dollars today","content":"I saved exactly 50 dollars today"}' curl -s "http://127.0.0.1:8000/notes?q=50%25" # %25 is the URL-encoded literal "%"

-> returns BOTH notes, even though only the first actually contains "50%"

This is a real, production-grade SQL LIKE metacharacter escaping bug -- the same category of mistake as forgetting to parameterize a query, except here the query is parameterized (SQLAlchemy handles that part correctly); the unescaped part is specifically the LIKE-pattern metacharacters within an otherwise-safe bound parameter. It requires recognizing that "safe from SQL injection" and "produces the search semantics you intended" are two different properties -- and it is precisely because this class of gap is easy to wave off as "not a real injection bug" that it tends to survive audits unfixed.

Look at how like is constructed in list_notes, and at SQLAlchemy's .like() method signature -- it accepts an escape= keyword specifically for this. You'll need to escape occurrences of the escape character itself, plus % and _, in q before interpolating it into the pattern, and pass the matching escape= argument so the database actually treats your escape character as an escape rather than a literal character too.