Second-Order SQL Injection
detect, understand, remediate

What is second-order SQL injection?

Second-order SQL injection (also called stored or persistent SQL injection) is the SQL injection class where the tainted value is stored by one request and triggered by a later request. The endpoint that accepted the input often parameterises its own query correctly, so the input reaches the database safely. The vulnerable sink lives in a different handler, a scheduled job, an admin tool, or a reporting query, where the stored value is read back and concatenated into an SQL string with no further sanitisation. The bug surfaces when the second query runs, sometimes minutes or hours after the input was supplied.

The class sits inside CWE-89 alongside the standard first-order SQL injection most testers know, but the detection and remediation conversation is materially different. A first-order injection is reproducible from a single request and shows up in any DAST tool that mutates parameters and watches the response. A second-order injection is reproducible only when the tester replays the stored value through the application surface that consumes it. Static dynamic scanning misses second-order paths because the trigger does not fire on the same request as the input.

Real-world examples span profile fields read by admin dashboards, search history rows replayed into recommendation queries, audit log entries reused in compliance reports, and message bodies indexed by full-text search jobs. The shared pattern is an input layer that treats the field as data and a reader layer that treats the field as identifier or fragment. The persistence step lets the payload survive the input-validation barrier; the reader step is where the injection actually executes.

How a second-order finding plays out on a pentest

Where second-order SQL injection tends to live

The patterns below cover most second-order findings on web, API, and back-office engagements. Each one shares the same shape: a write path that handles input correctly and a read path elsewhere in the stack that does not.

A worked example: stored display name in an admin search

A common shape on B2B engagements is a profile API that lets the user set a display name, paired with an admin support tool that searches across users by typing into a free-text box. The profile API parameterises its insert correctly. The admin search builds its query by string concatenation because the developer wanted to compose multiple LIKE clauses dynamically.

# Safe: profile update parameterises the insert
@app.post("/api/profile")
def update_profile(req: ProfileRequest, user = Depends(current_user)):
    db.execute(
        "UPDATE users SET display_name = %s WHERE id = %s",
        (req.display_name, user.id),
    )

The same value gets read back by the internal admin search, which composes a query string from a list of LIKE clauses across multiple columns. The display_name value is interpolated into the SQL string rather than passed as a parameter:

# Vulnerable: admin search interpolates a stored value
@app.get("/admin/users")
def admin_search(q: str):
    rows = db.execute(
        f"SELECT id, email, display_name FROM users "
        f"WHERE display_name LIKE '%{q}%' "
        f"   OR email LIKE '%{q}%' "
        f"   OR id::text = '{q}'"
    )
    return rows

The injection does not happen on the admin search field. The pentester sets their display name to a value that closes the LIKE clause and appends a UNION, then asks an admin to run a search that hits the row. The display_name read back into the SQL string makes the planted payload execute. The proof is the request that planted the value, the admin request that triggered the read, and the database response that returned the unioned row set.

# Tester action 1: store a payload through the safe write endpoint
POST /api/profile  body: {"display_name": "alice%' UNION SELECT id, password_hash, email FROM users -- "}

# Tester action 2: trigger the unsafe read with a search that lists the row
GET /admin/users?q=alice

# The admin search composes:
SELECT id, email, display_name FROM users
WHERE display_name LIKE '%alice%' UNION SELECT id, password_hash, email FROM users -- %'
   OR email LIKE '%alice%' UNION ...
   OR id::text = 'alice%' UNION ...

# Result: the union returns password hashes through the admin search response.

The fix is in two places, not one. The reader query has to use parameterisation for the LIKE pattern, and the application has to commit to the rule that any column read back into an SQL string is treated as untrusted regardless of who originally wrote it. Recoding the reader to use parameter binding closes this finding; auditing every other reader for the same pattern closes the class.

# Fixed: the admin search parameterises every input
@app.get("/admin/users")
def admin_search(q: str):
    pattern = f"%{q}%"
    rows = db.execute(
        "SELECT id, email, display_name FROM users "
        "WHERE display_name LIKE %s "
        "   OR email LIKE %s "
        "   OR (CASE WHEN %s ~ '^[0-9]+$' THEN id = %s::int ELSE FALSE END)",
        (pattern, pattern, q, q),
    )
    return rows

On a SecPortal engagement, the finding is recorded against both the storage endpoint (as the path that allowed the payload to land) and the reader endpoint (as the path that executed it). The CVSS vector reflects the full impact of the reader query: confidentiality is high because the union returned credential material, integrity depends on whether the reader runs INSERT or UPDATE, and availability depends on whether the planted value can break the reader for other users. The retest verifies that the reader rejects the same stored payload and that the auditing rule (treat every column read into SQL as untrusted) is documented in the codebase.

How to detect second-order SQL injection

How to fix second-order SQL injection

Reporting a second-order SQL injection finding

Second-order findings get pushed back more than first-order findings because the writer and the reader sit in different parts of the codebase and different parts of the team. Engineering looks at the writing endpoint, sees a parameterised insert, and disputes the finding. The strongest reports name both endpoints, the database column that links them, the reader query that interpolated the stored value, and the response or out-of-band evidence that proves execution. The CWE mapping is CWE-89 like first-order SQL injection, but the report should call out the second-order shape explicitly so the remediation team understands that fixing the writer alone does not close the bug.

On a SecPortal engagement, the finding is recorded against the consuming endpoint (the reader) with cross-references to the storage endpoint and the column path. The CVSS 3.1 vector reflects the reader query's actual privileges and data access, the request and response captures sit on the finding, and the planted-then-triggered evidence chain shows both stages. Pentest engagement records keep the proof linked to the original commit and the retest verification, so the remediation conversation references the actual reader-side fix rather than treating it as a generic SQL injection. The finding triage workflow covers how to separate scanner-derived candidates (a reader that concatenates a stored value) from manually validated findings (a planted payload that returned credential material) so the report differentiates suspected exposure from confirmed exploit. Pentest report writing guidance covers how to express the two-stage chain in a way that survives engineering review.

Compliance impact

A pentester checklist for second-order SQL injection

The checklist below is the minimum coverage a tester should walk before declaring a target's storage-and-read surface acceptable for SQL injection. Each item maps to a recognisable shape with a CVSS profile that depends on the reader query's privileges and the data the planted payload reaches.