SQL injection

SQL gives a database instructions: which records to select or change and under what conditions. Injection occurs when untrusted input changes those instructions instead of remaining a value. The boundary matters whether data came from a form, a queue, a partner, or an earlier database record.

Bind values; constrain structure

Parameterized queries keep values separate from SQL syntax. Prepared statements are a common way to achieve that separation. Parameters generally cannot stand in for table names, column names, or ordering keywords. When users choose a sort order, map their choice to a small set of server-defined structures.

Correctly implemented stored procedures can also be safe. A procedure or ORM becomes unsafe when it constructs executable SQL from untrusted text. The label on the library is not the control; the actual query-construction path is. OWASP documents these alternatives.

Scenario: the bookstore report

The bookstore binds the author name as a search value and maps the sort selector to either title or publication date. A later reporting job reuses saved search names. Those stored names still need binding at their new use: storing data did not make it trusted SQL.

Second-order injection occurs when stored untrusted data is later interpreted as SQL instructions or structure; delayed reuse alone is not injection. The lesson is to preserve the boundary every time data reaches an interpreter, not only when the application first accepts it.

Evidence has limits

An error message may reveal database details, but an error alone does not prove injection. Timing can reflect load, network variation, or other work. A defensible assessment combines the application’s query-construction logic, approved diagnostic evidence, and the expected data flow.

A useful report distinguishes confirmed construction flaws from unverified impact. It need not retrieve private records to explain that a query boundary is missing.

Separate prevention from blast radius

A WAF may reduce exposure to some inputs without repairing unsafe query construction. A read-only database account can limit writes while still exposing private records. Least privilege complements parameterization; it does not replace it.

Likewise, correct parameter binding does not enforce tenant ownership or business rules. A perfectly parameterized query can still return the wrong customer’s data if its authorization filter is missing. Moving to NoSQL changes the query language, not the need to separate data from operators.

Review the complete fix

Trace every dynamic query fragment, bind data values, constrain structural choices, and retain the relevant access checks. Include background jobs and reporting paths in the review. Record the approved behavior and remaining uncertainty so the fix can be verified without expanding the data exposure.

Separate three requirements in one report

The fictional bookstore supplies a review packet for its report builder. Q1 binds the author-search value using its database API. Q2 selects an ordering column from a fixed server-owned map. Q3 selects records without the shop-ownership filter required by the report policy. The database account is read-only.

Q1 and Q2 address different parts of query construction: values remain values, while structural choices stay within the server’s defined set. Neither supplies the missing ownership condition in Q3. Read-only access limits changes but can still disclose another shop’s records.

PredictThe builder has parameterized every data value. Can the reviewer approve the report’s shop isolation?

The packet still shows the required ownership condition is absent. Parameterization protects a query’s interpretation boundary; authorization determines which records that query may return. The report needs both.

Now include the scheduled report job. It reads saved filter values and builds its own database request. Saved filters remain data, even if an earlier interactive search handled them correctly. The job needs the same value separation and structural constraints at its own use, plus the correct shop context for the work it performs.

Write separate acceptance criteria. For construction, identify every variable value and structural choice and its handling in both paths. For authorization, establish that each report returns only the records permitted by the stated shop rule. For authority, confirm the account has only the access its duties require.

An unexpected error in one report would warrant diagnostics, not a claim that records were retrieved through injection. Conversely, no error does not establish correct construction. The supplied implementation records support a specific missing ownership check; actual exposure and historical use require additional evidence.