Inspecting what reaches cursor.execute catches the f-string login four green tests cleared

The whole difference is the second positional argument to execute. One implementation hands the driver a finished string, built with an f-string that interpolates the username and the password into the WHERE clause ^[3]. The other hands it `SELECT id FROM users WHERE username = ? AND password = ?` plus a tuple of the two values ^[4]. The response is identical either way: 200 with `{"ok": True}` for valid credentials, 401 with `{"ok": False}` for invalid ones ^[5].

A reader on the author's earlier post put the fix in one line: "Assert that the query is parameterized before it reaches cursor.execute." ^[1] The post splits the problem into two boundaries, request parameters to response body and status, and request parameters to SQL string and parameters to cursor.execute ^[18]. Behavior tests cover the first, and here they covered it correctly ^[6].

FakeDb.execute takes `(self, sql, params=None)` and stores both on the instance; fetchone returns `(1,)` when the constructor's valid flag is set and None otherwise ^[7]. No SQL runs. The assertion reads `db.sql` and `db.params` after the call ^[8].

`assert_parameterized` makes four checks: a `?` somewhere in the SQL, params equal to the expected tuple, and the username and the password absent from the SQL text ^[8]. The last two are substring tests against a template made of English words. A user registered as `id`, `users` or `password` is a substring of `SELECT id FROM users WHERE username = ? AND password = ?`, so `assert username not in sql` fails on the implementation that is correct ^[17]. The experiment's fixture username is alice, which does not collide ^[9].

The `?` is SQLite's placeholder. psycopg commonly uses `%s` and asyncpg commonly uses `$1`, according to the post ^[10]. Lift the test into a psycopg codebase unchanged and `assert "?" in sql` fails on every parameterized query it inspects ^[16]. The post's own production advice is stricter than its demo: an approved query constant plus the expected parameter tuple "is usually stronger than checking for one character in the SQL string" ^[11].

The scanner run is the cheap half. code-audit-cli reported one finding on the unsafe file, severity high, pattern sql-concat, line 6, and zero findings on the safe one ^[12]. The post says that finding points to the f-string construction for human review, that it "does not prove that every possible exploit succeeds", and that it does not replace checking the input source, the execution path, authorization behavior, or the surrounding login logic ^[13].

What the contract test settles is one boundary, on two functions, with controlled values ^[9]. The post is explicit that this is a controlled demonstration and not a complete login-security review, and that it does not cover password hashing, account enumeration, rate limiting, account lockout, audit logging, session handling, or authorization ^[15].