Placeholders and Prepared Statements

## The two channels Every query entry point in `database/sql` has the same shape: ``` QueryContext(ctx context.Context, query string, args ...any) ``` The `query` string and the `args` slice are two separate channels, and the package keeps them separate for their whole journey. `database/sql` does not parse SQL, does not know your dialect, and does not perform substitution. It converts each argument to a value the driver accepts (through the driver's value converter) and passes the text plus the argument list down to the driver. The driver then sends the statement to the server and sends the values as **bind parameters** in the wire protocol. That ordering is the whole security property. The server receives the statement text, parses it into a tree, and decides what the query means — which tables, which operators, where the string literals are — **before** a single argument value is applied. When the values arrive, the shape of the statement is already fixed. A value is then only ever data occupying a slot; it cannot open a quote, add `OR 1=1`, start a comment, or append a second statement. ## What string formatting does instead ```go q := fmt.Sprintf("SELECT id FROM users WHERE email = '%s'", email) ``` Here the value is inside the text before the parser ever runs, so the parser cannot tell your intent from the attacker's input. An `email` of `x' OR '1'='1` produces a statement whose WHERE clause is a different expression from the one you wrote. Nothing downstream can recover the distinction — not the driver, not `database/sql`, not the server. The injection happened in your `fmt.Sprintf` call. The same is true of `+` concatenation, `text/template`, and any helper that renders a value into the statement string. ## There is no escape function, and that is on purpose Engineers arriving from other ecosystems often look for something like `sql.Escape`. `database/sql` has none. Correct escaping is dialect-specific, mode-specific (a MySQL server with `NO_BACKSLASH_ESCAPES` escapes differently), and encoding-specific, and it is easy to get subtly wrong. The package's position is that the parameter channel already exists, so any request to escape a value into text is a request you should decline. A few drivers can be configured to interpolate parameters client-side for round-trip reasons. That is still not the same as your own formatting: the driver knows its server's quoting rules and applies them to values it received through the parameter channel. Your code keeps the placeholder either way. ## What the package does check A driver may report how many parameters a statement takes through `NumInput`. When it does, `database/sql` compares that with the number of arguments you passed and fails with an argument-count error before anything reaches the server. When the driver reports that it does not know, the mismatch surfaces as a server-side error instead. Either way, a missing or extra argument is a loud failure rather than a silent one. ## What placeholders do not cover Placeholders bind **values**. They cannot stand in for a table name, a column name, a sort direction, or a whole WHERE fragment, because those decide the meaning of the statement at parse time. Code that needs a user-selected sort column must choose among fragments the program itself contains — the request may select, never supply. That is a separate technique, and it is the only place where building SQL text in Go is legitimate. ## Reviewing for it The review rule is mechanical: a query string should be a constant or a value assembled only from program-owned pieces, and every request-derived value should appear in the argument list. If a query string is produced by `fmt.Sprintf` with a `%s` or `%v` holding data, that is the finding. On the database side, the query log confirms it: parameterised statements show up with a stable text and the values recorded beside them as bound parameters.