An AI-generated login endpoint "works" - I still found SQL concatenation before launch

yuan ming — Thu, 10 Sep 2026 09:47:45 +0000

Functional tests passing is not the same as code being safe to ship. Here is a reproducible case: an AI-generated login endpoint that behaves correctly, the scan finding I checked before launch, and the fix that made the pattern disappear.

The code runs, but I would not ship it like this

This is a local demo equivalent of a login endpoint, not live production code and not a client project:

username = request.form.get("username", "")
password = request.form.get("password", "")

sql = f"SELECT id FROM users WHERE username = '{username}' AND password = '{password}'"
cursor.execute(sql)
row = cursor.fetchone()

if row:
    return {"ok": True}
return {"ok": False}, 401

It works: correct credentials return success. My concern is not whether it works today. It is that username and password come from an HTTP request and are placed directly inside an SQL string.

A first-pass scan finds the pattern to check

I did not read every line first. I ran a local quick scan:

code-audit app --format html --output report.html

One result was:

Severity	Rule	Risk	Location
High	`sql-concat`	SQL assembled from strings, user input can reach the query	`app/login.py:12`

A high finding is not an automatic conclusion. I confirm it in four steps.

1. Where does the input come from?

username and password come from request.form. That means a client can submit arbitrary values. Input from HTTP requests is untrusted by default.

2. Where does it go?

The values skip length checks, type checks, escaping and parameterization, then enter the SQL template:

sql = f"SELECT id FROM users WHERE username = '{username}' AND password = '{password}'"
cursor.execute(sql)

The source is a request parameter. The sink is SQL execution. There is no boundary between them.

3. Can it be exploited?

I do not attack my own project. I reason through SQL syntax:

If username contains:

' OR '1'='1

the resulting SQL can become:

SELECT id FROM users WHERE username = '' OR '1'='1' AND password = '{password}'

I cannot prove that every login is bypassable. I can confirm there is a suspicious path that does not require advanced exploitation. For a login endpoint, fixing it before launch is cheaper than investigating it after launch.

4. Use a parameterized query

The fix is not filtering single quotes. It is keeping user input out of the SQL string:

cursor.execute(
    "SELECT id, password_hash FROM users WHERE username = %s",
    (username,),
)
row = cursor.fetchone()

if row and verify_password(password, row["password_hash"]):
    return {"ok": True}
return {"ok": False}, 401

This also changes the login flow to fetch the password hash by username first and verify the password separately, instead of putting the plaintext password into SQL.

After the fix, the sql-concat High finding no longer appears.

A clean scan is not "absolutely safe"

A clean scan only means this round did not find that rule pattern. It does not mean:

There are no other vulnerabilities.
The login flow meets every production security requirement.
You can skip rate limiting, lockout policy, audit logging and access checks.

Pre-launch checking is a process, not a verdict: scan for suspicious locations, confirm with a human, fix what can be fixed, and list what still needs review.

Evidence you can inspect

The rules, sample output and boundaries are public on GitHub: https://github.com/yuan1521913/code-audit-cli

The full source package is a separate licensed delivery. If you want a local scanner that produces Markdown, JSON, HTML or SARIF reports and can act as a CI gate, the English source package is here: https://5552463341538.gumroad.com/l/code-audit-cli-source

The scanner runs locally and does not upload your code. Automatic results still need human confirmation.

DEV Community: yuan ming