Database Security

---
name: database-security
description: "Prevent SQL and NoSQL injection, unsafe ORM and raw-query use, over-privileged database identities, weak tenant isolation, and unauthenticated database transport. Use when generating SQL or raw query strings, NoSQL filters, ORM models or queries, database migration files, or connection strings."
---

<!-- Native skill bundle for Claude Code. Generated by `secure-vibe dev regenerate`. -->
<!-- Do not edit by hand; the source of truth is skills/database-security/SKILL.md. -->

# Database Security

Prevent SQL and NoSQL injection, unsafe ORM and raw-query use, over-privileged database identities, weak tenant isolation, and unauthenticated database transport. Use when generating SQL or raw query strings, NoSQL filters, ORM models or queries, database migration files, or connection strings.

## 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.

## NEVER

- Manually quote or escape an untrusted SQL value as a substitute for the framework's documented parameterization mechanism.
- Use an ORM raw-query method (`.raw()`, `.objects.raw()`, `$queryRawUnsafe`, `session.execute(text(...))`) with an interpolated f-string or template literal. Raw SQL is not the problem; interpolation into it is.
- Evaluate server-side JavaScript over untrusted input (`$where`, `mapReduce`, `$accumulator`). There is no safe form of it — it is code execution inside the database.
- Run application workloads as the database superuser: `root`, `postgres`, `sa`.
- Grant destructive DDL capability to the normal application runtime identity.
- Send database traffic across an untrusted network without authenticated encryption, or disable certificate verification to work around a certificate error.
- Expose a database listener broadly to the public internet. Restrict reachability to explicitly authorized application and administrative sources, and prefer private connectivity for application traffic where the platform supports it.
- Emit database credentials, connection strings containing secrets, or sensitive bound values to logs. `logging-security` owns the shape this should take — statement template, parameter names, a hashed value identifier — and the redactor that enforces it.

## KNOWN FALSE POSITIVES

- Encryption without client-side certificate verification is not a finding where the channel is already authenticated by other means: a Unix domain socket (where `sslmode` does not apply at all), a cloud SQL proxy or sidecar terminating an authenticated tunnel, or a service mesh enforcing mTLS. The finding is an unauthenticated connection across a network, not the literal string `sslmode=require`.
- Some ORMs and DB-API drivers (Django, SQLAlchemy 1.x, psycopg2) use `%s` as a *parameter marker*, not a Python format placeholder. `cursor.execute(sql, [value])` with an unquoted `%s` is the safe form, not a violation.
- Trusted analyst-authored ad-hoc SQL in a dedicated analytics environment may intentionally contain dynamic SQL structure. Keep that capability behind explicit authorization and appropriately scoped data access. A read-only account limits modification but does not make untrusted query fragments safe, and does not prevent unauthorized reads.
- Static SQL with no untrusted dynamic values — `SELECT 1`, fixed schema introspection, constant migration statements — does not need artificial bind parameters to satisfy this skill.

## Reference files

Read these only when the task calls for them.

- `references/orm-safe-query-examples.md`
- `references/verifying-findings.md`