A city portal stores a citizen nickname that is later reused in a different admin report query. Injection fails on the registration request but succeeds when staff generate that report. What injection class best fits this pattern?
Select an answer to reveal the explanation.
Short Explanation
Picture writing a note that looks harmless when you drop it in the inbox — then it blows up when someone else reads it into a search. Second-order SQLi is that delayed fuse: the bad string sits in storage and only runs when a later query trusts it. The first request can look clean and still leave a landmine.
Full Explanation
Second-order SQL injection occurs when data is stored safely enough to survive the first request, then later concatenated into a different query path without proper parameterization. A city portal that accepts a citizen nickname at registration without immediate breakage, yet fails when staff generate an admin report that reuses that nickname, matches this class: the dangerous sink is deferred. Civic reporting features are frequent second-order sinks because staff tools trust stored resident fields.
Reflected XSS in the registration response is a different client-side class and does not explain a later report query failure. Classic first-order SQLi that must always break the immediate request misses deferred sinks. CSRF forcing nickname re-submit is an anti-forgery theme, not the stored-then-queried SQL pattern described.
Exam caveat: hunt second-order paths by tracing where stored civic fields are reused in admin exports, search, and batch jobs—not only by fuzzing the entry form. CPTS SQLi taxonomy distinguishes first-order from second-order by sink timing.
Operational check: map nickname storage to the admin report query, confirm parameterization or escaping at the later sink, use a minimal non-destructive proof under RoE, and avoid dumping unrelated citizen tables while evidencing the issue.