database-security

Database Security

Rules (for AI agents)

ALWAYS

• Bind every untrusted data value through the driver or ORM parameter API. Never place it into SQL with language-level interpolation or concatenation — +, f-strings, % formatting, .format(), JavaScript template interpolation. Driver placeholders (%s, ?, $1, :name, @name) are the binding mechanism, not string formatting; confusing the two is how this rule is most often misread. The same applies to values read back out of the database and used to build a later query: stored input is still input, and second-order injection is this bug with a delay.
• Prefer the ORM's structured query-expression API over textual SQL. Where raw SQL is genuinely needed, use that framework's documented parameter-binding mechanism and never interpolate untrusted values into it. references/orm-safe-query-examples.md carries the verified form per framework.
• For SQL structure that cannot be a bind parameter — table and column identifiers, sort direction, sometimes the operator itself — map the external value to a fixed operator-controlled allowlist. Never copy an untrusted identifier or SQL fragment into the statement, escaped or not.
• Treat a NoSQL query as a structure, not a string. Build filters with the driver's typed query objects, and coerce every request-supplied value to its expected scalar type before it reaches a filter. A JSON body substituting {"$ne": null} where a string was expected turns an equality check into a match-all — operator injection needs no quote to break out of.
• Give each application its own database identity with the minimum grants it needs, and separate runtime privileges from migration privileges. The runtime identity must not receive schema-owner or DDL rights merely because migrations require them.
• For shared-table multi-tenancy, enforce tenant isolation at a deliberate security boundary. Where database RLS is used: confirm the application role cannot bypass it — a superuser, a BYPASSRLS role, and the table owner itself all bypass policies unless the table is set to FORCE ROW LEVEL SECURITY — test write policies as well as read, and bind the tenant context transaction-locally. A session-scoped tenant context that survives a connection's return to the pool serves tenant A's rows to tenant B.
• Authenticate the database server, do not merely encrypt to it. Encryption without certificate verification (sslmode=require, MySQL sslMode=REQUIRED, TrustServerCertificate=True) stops passive capture but not a redirected connection. Where the client is what establishes trust, use a verifying mode — PostgreSQL verify-full, MySQL Connector/J VERIFY_IDENTITY, Microsoft.Data.SqlClient with TrustServerCertificate=False — against the deployment's trusted CA configuration.
• Obtain database credentials from an operator-controlled secret-management mechanism; prefer workload identity or short-lived dynamic credentials where the platform supports them. A runtime-injected environment variable is an acceptable fallback, not the target — it is readable through process inspection, crash dumps, and many orchestrator APIs. Any static credential must support rotation and revocation. See secret-detection for what counts as a committed credential.