Query structure and values are different

Data and the structure that processes it have different jobs.

Values are not grammar

Parameterization keeps query structure separate from values supplied through the database interface. A search term remains a value instead of becoming part of the instructions. This separation must occur where the database query is constructed; merely labeling a browser field “parameter” does not establish it.

Structural choices need a different treatment. Ordinary value parameters cannot substitute for arbitrary column names or sorting grammar. A server can map a small set of approved labels to fixed, known structural choices using its database library’s supported facilities.

Fictional search specification

Assume a library catalog permits searching titles and sorting by newest or alphabetical order. Results must still respect each reader’s collection access.

• Q1: The search term is passed as a bound value through the database driver.
• Q2: The interface offers “newest” and “alphabetical,” but the server’s structural selection has no documented mapping or rejection rule.
• Q3: The review claims that Q1 proves every input is safely parameterized.

Review the missing decision

Q1 supports a useful protection for the term. It does not establish how Q2 chooses structure. Require a server-owned mapping for the two approved labels, with a defined response to unsupported choices. Do not make punctuation removal the main defense: a book title can legitimately contain punctuation.

Even a correctly constructed query can return records that the caller should not receive. Collection authorization and a database account limited to required operations remain separate decisions.

Approval condition: Preserve bound values, document constrained structure, and verify access to the records returned.