SQL injection occurs when untrusted input changes SQL structure; server-side parameters keep values separate but cannot parameterize identifiers or arbitrary syntax. Protect database access with allowlisted query shapes, least privilege, secret rotation, verified TLS, secure storage and backups, careful logs, and application-level encryption or tokenization when the threat model requires it.
Security is layered: prevent structural injection, authenticate server/client, authorize role, encrypt appropriate paths, minimize stored data, audit access, and retain recovery. Encryption cannot repair excessive privileges or a compromised application that legitimately decrypts data.
Unsafe:
Safe value parameter:
Sort columns/directions must come from a fixed application allowlist and be composed with the driver’s identifier facilities—not passed as a value or copied from a model.
Use TLS with certificate/hostname verification according to deployment. Managed “encryption at rest” usually covers provider storage, not every insider/application threat. Backups, replicas, exports, logs, temp files, and keys need their own controls.
Prompt injection can cause a model to request dangerous tool arguments, but the database risk is contained by semantic tools, parameters, allowlists, RLS, read-only transactions, limits, timeouts, and approval. Never place database passwords or raw sensitive rows into a model prompt or trace.
Run injection strings against parameterized tests and confirm they remain values. Test unauthorized identifiers are rejected by the allowlist. Validate TLS mode/certificate behavior in an isolated environment. Scan source, logs, images, CI output, and prompt traces for seeded fake secrets.
Build a safe sort builder supporting only created_at, priority, and status, with two directions.
Acceptance criterion: all unexpected model/user tokens are rejected, values remain parameters, and runtime role cannot execute DDL.