PostgreSQL & Database Dependency Security in 2026: psycopg2 Supply Chain Risks, Prisma ORM Injection & SQLAlchemy Hardening GuideSécurité des Dépendances Base de Données en 2026 : Risques Supply Chain psycopg2, Injection ORM Prisma & Guide Durcissement SQLAlchemy

Your PostgreSQL application doesn't just talk directly to the database — it goes through a stack of drivers, ORMs, and SDKs. Each layer has its own vulnerability surface. In 2026, the risk is not only in your application logic or in the database server itself: it lives in your requirements.txt, your package.json, and in how your ORM translates Python or TypeScript into SQL.

Votre application PostgreSQL ne communique pas directement avec la base de données — elle passe par une pile de drivers, d'ORM et de SDK. Chaque couche a sa propre surface de vulnérabilité. En 2026, le risque ne réside plus seulement dans la logique applicative ou dans le serveur de base de données lui-même : il se cache dans votre requirements.txt, dans votre package.json, et dans la façon dont votre ORM traduit le Python ou le TypeScript en SQL.

This guide covers the four most common database dependency risks for PostgreSQL-backed applications in 2026: psycopg2-binary's bundled OpenSSL supply chain risk, Prisma ORM's injection vulnerabilities, SQLAlchemy's silent raw query traps, and database credentials leaking through developer environments.

Ce guide couvre les quatre risques de dépendances de base de données les plus courants pour les applications PostgreSQL en 2026 : le risque supply chain d'OpenSSL intégré dans psycopg2-binary, les vulnérabilités d'injection dans Prisma ORM, les pièges silencieux des requêtes brutes dans SQLAlchemy, et la fuite de credentials de base de données dans les environnements développeurs.

psycopg2-binary: The OpenSSL Bundle Problem

psycopg2-binary : Le problème du bundle OpenSSL

psycopg2 is the most widely used PostgreSQL driver for Python — downloaded tens of millions of times each month from PyPI. Most developers install psycopg2-binary (the pre-built wheel variant) instead of compiling from source, because it requires no system dependencies. This convenience comes with a hidden cost.

psycopg2 est le driver PostgreSQL le plus utilisé en Python — téléchargé des dizaines de millions de fois chaque mois sur PyPI. La plupart des développeurs installent psycopg2-binary (la variante wheel pré-compilée) plutôt que de compiler depuis les sources, car elle ne nécessite aucune dépendance système. Cette commodité a un coût caché.

The psycopg2 project itself has acknowledged this in GitHub issue #1043: "Bundling 3rd party dependencies is a security risk." When a critical OpenSSL CVE is released, your system OpenSSL gets patched by your OS package manager, but the OpenSSL copy inside psycopg2-binary only gets updated when the psycopg2 team releases a new binary wheel — which may lag by days or weeks.

Le projet psycopg2 lui-même a reconnu ce problème dans l'issue GitHub #1043 : "Bundler des dépendances tierces est un risque de sécurité." Quand une CVE critique OpenSSL est publiée, votre OpenSSL système est patché par votre gestionnaire de paquets OS, mais la copie OpenSSL dans psycopg2-binary n'est mise à jour que lorsque l'équipe psycopg2 publie un nouveau wheel binaire — ce qui peut prendre des jours ou des semaines.

The fix is straightforward: install psycopg2 (not psycopg2-binary) in production and compile it against your system's libpq. For projects starting in 2026, consider migrating to psycopg3 (psycopg), which uses the system libpq by default and follows modern async patterns.

La correction est simple : installez psycopg2 (pas psycopg2-binary) en production et compilez-le contre le libpq de votre système. Pour les projets démarrant en 2026, envisagez de migrer vers psycopg3 (psycopg), qui utilise le libpq système par défaut et suit des patterns async modernes.

# Production requirements.txt
# Avoid:
psycopg2-binary==2.9.10

# Use instead (requires libpq-dev on the build host):
psycopg2==2.9.10

# Or migrate to psycopg3 (async-native, uses system libpq):
psycopg[binary]==3.2.6    # binary variant for dev only
psycopg==3.2.6            # pure Python + system libpq for prod

asyncpg, the other popular async PostgreSQL driver for Python, does not bundle OpenSSL in the same way — it uses the system libssl directly. However, it is compiled as a native extension (C extension via Cython), which means you still need to monitor it via pip-audit or OSV-based tooling for known CVEs in the published wheel.

asyncpg, l'autre driver PostgreSQL async populaire pour Python, ne bundle pas OpenSSL de la même façon — il utilise le libssl système directement. Cependant, c'est une extension native (extension C via Cython), ce qui signifie que vous devez quand même le surveiller via pip-audit ou des outils basés sur OSV pour les CVE connues dans le wheel publié.

Prisma ORM: Three Injection Attack Vectors

Prisma ORM : Trois vecteurs d'attaque par injection

Prisma is the dominant TypeScript/Node.js ORM for PostgreSQL in 2026. Its type-safe query API gives developers confidence that their queries are safe — but that confidence has limits. There are three distinct injection attack vectors in Prisma that developers need to understand.

Prisma est l'ORM TypeScript/Node.js dominant pour PostgreSQL en 2026. Son API de requêtes type-safe donne aux développeurs la confiance que leurs requêtes sont sûres — mais cette confiance a des limites. Il existe trois vecteurs d'attaque par injection distincts dans Prisma que les développeurs doivent comprendre.

1. $queryRawUnsafe — The Explicit Risk

1. $queryRawUnsafe — Le risque explicite

Prisma exposes both safe and unsafe raw query methods. The unsafe variant bypasses all of Prisma's escaping mechanisms and is vulnerable to classic SQL injection when user input is interpolated directly:

Prisma expose des méthodes de requêtes brutes sûres et non sûres. La variante non sûre contourne tous les mécanismes d'échappement de Prisma et est vulnérable à l'injection SQL classique lorsque l'input utilisateur est interpolé directement :

// VULNERABLE — never do this
const userId = req.query.id;  // could be: "1 OR 1=1"
const user = await prisma.$queryRawUnsafe(
  `SELECT * FROM users WHERE id = ${userId}`
);

// SAFE — always use $queryRaw with tagged template literals
const user = await prisma.$queryRaw`
  SELECT * FROM users WHERE id = ${userId}
`;

// ALSO SAFE — using Prisma.sql for composed queries
const filter = Prisma.sql`id = ${userId}`;
const user = await prisma.$queryRaw`SELECT * FROM users WHERE ${filter}`;

2. plORMbing — Time-Based ORM Leak Attacks

2. plORMbing — Attaques ORM Leak par délai temporel

In 2024, security researchers at elttam published the plORMbing technique: a time-based ORM Leak attack specific to Prisma. Unlike classic SQL injection, this attack exploits the fact that Prisma gives developers unusually fine control over query structure — including the ability to pass arbitrary SQL fragments in certain query patterns. By injecting crafted timing expressions, an attacker can exfiltrate data from your database one bit at a time, even through a properly sanitized application layer.

En 2024, des chercheurs en sécurité chez elttam ont publié la technique plORMbing : une attaque ORM Leak par délai temporel spécifique à Prisma. Contrairement à l'injection SQL classique, cette attaque exploite le fait que Prisma donne aux développeurs un contrôle inhabituellement fin sur la structure des requêtes — y compris la possibilité de passer des fragments SQL arbitraires dans certains patterns de requête. En injectant des expressions de timing craftées, un attaquant peut exfiltrer des données de votre base de données bit par bit, même à travers une couche applicative correctement nettoyée.

3. Operator Injection — The Surprising Risk in Relational Databases

3. Injection d'opérateurs — Le risque surprenant dans les bases relationnelles

Aikido Security researchers discovered that Prisma ORM is vulnerable to a NoSQL-style operator injection attack — even when used with PostgreSQL, a fully relational database. Prisma's query operators (not, in, contains, startsWith, etc.) are valid inputs in findFirst, findMany, updateMany, and deleteMany. These operators are not filtered at runtime because they are part of the expected API.

Les chercheurs d'Aikido Security ont découvert que Prisma ORM est vulnérable à une attaque par injection d'opérateurs de style NoSQL — même lorsqu'il est utilisé avec PostgreSQL, une base de données entièrement relationnelle. Les opérateurs de requête Prisma (not, in, contains, startsWith, etc.) sont des inputs valides dans findFirst, findMany, updateMany et deleteMany. Ces opérateurs ne sont pas filtrés à l'exécution car ils font partie de l'API attendue.

// Vulnerable endpoint: takes a JSON body and passes to Prisma directly
app.post('/login', async (req, res) => {
  const { email, password } = req.body;  // ← user-controlled

  const user = await prisma.user.findFirst({
    where: { email, password }  // ← dangerous: no input validation
  });
  if (user) return res.json({ token: sign(user.id) });
  return res.status(401).json({ error: 'Invalid credentials' });
});

// Attacker sends: { "email": "victim@example.com", "password": { "not": "" } }
// Prisma generates: WHERE email = 'victim@...' AND password != ''
// Result: authenticated as the victim without knowing their password

The fix: always validate input shape before passing it to Prisma. Use a schema validation library like Zod or Joi to enforce that password is a string, never an object.

La correction : validez toujours la forme des inputs avant de les passer à Prisma. Utilisez une bibliothèque de validation de schémas comme Zod ou Joi pour imposer que password est une chaîne, jamais un objet.

import { z } from 'zod';

const LoginSchema = z.object({
  email: z.string().email(),
  password: z.string().min(8).max(128),  // enforces string type — blocks { "not": "" }
});

app.post('/login', async (req, res) => {
  const { email, password } = LoginSchema.parse(req.body);  // throws if invalid
  const user = await prisma.user.findFirst({ where: { email, password } });
  // ...
});

SQLAlchemy: The Raw Query Trap

SQLAlchemy : Le piège des requêtes brutes

SQLAlchemy is the dominant Python ORM for PostgreSQL — used in FastAPI, Flask, and Django projects alike. Its ORM layer provides complete protection against SQL injection through parameterized queries. The problem is a common pattern that silently bypasses this protection: using Python f-strings or string formatting to build queries.

SQLAlchemy est l'ORM Python dominant pour PostgreSQL — utilisé dans les projets FastAPI, Flask et Django. Sa couche ORM offre une protection complète contre l'injection SQL via des requêtes paramétrées. Le problème est un pattern courant qui contourne silencieusement cette protection : l'utilisation des f-strings Python ou du formatage de chaînes pour construire des requêtes.

from sqlalchemy import text

# VULNERABLE — f-string injects user input directly into SQL
user_input = request.args.get('search')
result = db.execute(f"SELECT * FROM products WHERE name LIKE '%{user_input}%'")

# ALSO VULNERABLE — text() with string formatting does NOT protect you
result = db.execute(text(f"SELECT * FROM users WHERE id = {user_id}"))

# SAFE — text() with bound parameters
result = db.execute(
    text("SELECT * FROM users WHERE id = :user_id"),
    {"user_id": user_id}
)

# SAFEST — ORM query (parameterized automatically)
result = db.query(User).filter(User.id == user_id).first()

# SQLAlchemy 2.0 style (recommended)
stmt = select(User).where(User.id == user_id)
result = db.execute(stmt).scalar_one_or_none()

A particularly dangerous pattern is dynamic table or column names, which cannot be parameterized. If you must build queries with dynamic identifiers, use an explicit allowlist approach:

Un pattern particulièrement dangereux est celui des noms de tables ou de colonnes dynamiques, qui ne peuvent pas être paramétrés. Si vous devez construire des requêtes avec des identifiants dynamiques, utilisez une approche par liste d'autorisation explicite :

from sqlalchemy import text, inspect

# VULNERABLE — never use user input directly as a table/column name
table = request.args.get('table')  # could be: "users; DROP TABLE users --"
result = db.execute(text(f"SELECT * FROM {table}"))

# SAFE — allowlist of permitted table names
ALLOWED_TABLES = {'products', 'categories', 'reviews'}
table = request.args.get('table')
if table not in ALLOWED_TABLES:
    raise ValueError(f"Unknown table: {table}")

# For column names, use inspect() to verify they exist on the model
from sqlalchemy import Column
inspector = inspect(db.bind)
valid_columns = {c['name'] for c in inspector.get_columns('products')}
if sort_col not in valid_columns:
    sort_col = 'id'  # safe default

Database Credentials in Developer Environments

Credentials de base de données dans les environnements développeurs

The most common database security failure in 2026 is not a CVE in a driver — it is a production DATABASE_URL hardcoded in a .env file that got committed to Git, or a docker-compose.yml with plaintext database passwords stored in a public or internal repository.

La défaillance de sécurité de base de données la plus courante en 2026 n'est pas une CVE dans un driver — c'est un DATABASE_URL de production hardcodé dans un fichier .env qui a été commité dans Git, ou un docker-compose.yml avec des mots de passe de base de données en clair stockés dans un dépôt public ou interne.

Several database credential patterns are targeted by supply chain attacks in 2026. When malicious packages run postinstall scripts, they specifically look for these files:

Plusieurs patterns de credentials de base de données sont ciblés par les attaques supply chain en 2026. Quand des packages malveillants exécutent des scripts postinstall, ils recherchent spécifiquement ces fichiers :

# Files targeted by malware in 2026 supply chain attacks:
~/.pgpass                    # PostgreSQL password file
.env                         # DATABASE_URL, POSTGRES_PASSWORD
.env.local / .env.production
docker-compose.yml           # POSTGRES_PASSWORD env vars
prisma/.env                  # Prisma DATABASE_URL
alembic.ini                  # SQLAlchemy database URL
config/database.yml          # Rails-style DB config

Best practice for database connection strings: never store them in files that could be committed. Use environment variables injected at runtime from a secrets manager (HashiCorp Vault, AWS Secrets Manager, or your CI/CD platform's native secrets store). For Prisma, the DATABASE_URL in prisma/.env must be in your .gitignore — it is not automatically excluded.

Bonne pratique pour les chaînes de connexion : ne les stockez jamais dans des fichiers qui pourraient être commités. Utilisez des variables d'environnement injectées à l'exécution depuis un gestionnaire de secrets (HashiCorp Vault, AWS Secrets Manager, ou le store de secrets natif de votre plateforme CI/CD). Pour Prisma, le DATABASE_URL dans prisma/.env doit être dans votre .gitignore — il n'est pas exclu automatiquement.

# prisma/.gitignore — create this file if it doesn't exist
.env

# Or in root .gitignore — add all .env variants
.env
.env.*
!.env.example    # only commit the example template

Database Dependency Security Checklist for 2026

Checklist de sécurité des dépendances de base de données pour 2026

• ✓ Use psycopg2 (not psycopg2-binary) in production — the binary variant bundles OpenSSL and libpq, making them invisible to OS-level patching. Build from source against system libpq-dev. Utiliser psycopg2 (pas psycopg2-binary) en production — la variante binary bundle OpenSSL et libpq, les rendant invisibles au patching au niveau OS. Compiler depuis les sources contre le libpq-dev système.
• ✓ Validate input shape before passing to Prisma — use Zod or Joi to enforce that all query fields are the expected primitive types. Prevent operator injection by ensuring fields like password or email are always strings. Valider la forme des inputs avant de les passer à Prisma — utiliser Zod ou Joi pour imposer que tous les champs de requête sont des types primitifs attendus. Prévenir l'injection d'opérateurs en s'assurant que les champs comme password ou email sont toujours des chaînes.
• ✓ Audit all $queryRawUnsafe usages — search your codebase for queryRawUnsafe and $executeRawUnsafe. Every occurrence should be reviewed; most can be replaced with safe tagged template literals. Auditer toutes les utilisations de $queryRawUnsafe — rechercher dans votre codebase queryRawUnsafe et $executeRawUnsafe. Chaque occurrence doit être passée en revue ; la plupart peuvent être remplacées par des template literals sûrs.
• ✓ Replace f-strings in SQLAlchemy queries — search for f"SELECT, f"INSERT, f"UPDATE, f"DELETE, and .format( patterns in your Python code. Convert to bound parameters with text("... WHERE id = :id", {"id": val}). Remplacer les f-strings dans les requêtes SQLAlchemy — rechercher f"SELECT, f"INSERT, f"UPDATE, f"DELETE et les patterns .format( dans votre code Python. Convertir en paramètres liés avec text("... WHERE id = :id", {"id": val}).
• ✓ Add prisma/.env to .gitignore — Prisma creates this file during prisma init and it is not automatically excluded from Git. It contains your DATABASE_URL. Ajouter prisma/.env au .gitignore — Prisma crée ce fichier lors de prisma init et il n'est pas automatiquement exclu de Git. Il contient votre DATABASE_URL.
• ✓ Run pip-audit and npm audit on every PR — for psycopg2, asyncpg, SQLAlchemy, Prisma, and all database-related packages. CVEs in drivers are rare but real; automation catches them before they reach production. Exécuter pip-audit et npm audit sur chaque PR — pour psycopg2, asyncpg, SQLAlchemy, Prisma, et tous les packages liés à la base de données. Les CVE dans les drivers sont rares mais réelles ; l'automatisation les détecte avant qu'elles n'atteignent la production.
• ✓ Rotate database credentials regularly — given that 64% of leaked secrets from 2022 are still valid today, implement automated rotation. AWS RDS, Cloud SQL, and Supabase all support managed credential rotation. For self-hosted PostgreSQL, consider using Vault's database secrets engine. Faire tourner les credentials de base de données régulièrement — étant donné que 64% des secrets fuités en 2022 sont encore valides aujourd'hui, implémenter la rotation automatique. AWS RDS, Cloud SQL et Supabase supportent tous la rotation gérée des credentials. Pour PostgreSQL auto-hébergé, considérer l'utilisation du moteur de secrets de base de données de Vault.
• ✓ Pin your driver versions in lockfiles — poetry.lock, requirements.txt with pinned hashes (--hash), or package-lock.json. Floating versions (psycopg2>=2.9) allow a supply chain attack to inject a malicious version. Épingler les versions de vos drivers dans les lockfiles — poetry.lock, requirements.txt avec des hashes épinglés (--hash), ou package-lock.json. Les versions flottantes (psycopg2>=2.9) permettent à une attaque supply chain d'injecter une version malveillante.

supabase-js and node-postgres (pg): What to Know

supabase-js et node-postgres (pg) : Ce qu'il faut savoir

supabase-js (@supabase/supabase-js) is an npm package with millions of weekly downloads. Unlike psycopg2-binary, it does not bundle native libraries — it communicates with Supabase via the PostgREST API over HTTPS, so your local OpenSSL is never directly involved. Snyk's database currently shows no direct vulnerabilities for the published package. The primary risk with supabase-js is the supply chain risk common to all npm packages: monitor it via npm audit and lock your version in package-lock.json.

supabase-js (@supabase/supabase-js) est un package npm avec des millions de téléchargements par semaine. Contrairement à psycopg2-binary, il ne bundle pas de bibliothèques natives — il communique avec Supabase via l'API PostgREST sur HTTPS, donc votre OpenSSL local n'est jamais directement impliqué. La base de données Snyk ne montre actuellement aucune vulnérabilité directe pour le package publié. Le risque principal avec supabase-js est le risque supply chain commun à tous les packages npm : surveillez-le via npm audit et verrouillez votre version dans package-lock.json.

node-postgres (pg), the underlying PostgreSQL driver for Node.js, uses parameterized queries by default. The key risk is the same pattern as SQLAlchemy: string concatenation in raw query strings. Always use the parameterized form:

node-postgres (pg), le driver PostgreSQL sous-jacent pour Node.js, utilise des requêtes paramétrées par défaut. Le risque principal est le même pattern que SQLAlchemy : la concaténation de chaînes dans les chaînes de requêtes brutes. Utilisez toujours la forme paramétrée :

const { Pool } = require('pg');
const pool = new Pool();

// VULNERABLE — string concatenation
const result = await pool.query(
  `SELECT * FROM users WHERE email = '${email}'`
);

// SAFE — parameterized query
const result = await pool.query(
  'SELECT * FROM users WHERE email = $1',
  [email]
);

// ALSO SAFE — positional parameters in pg
const result = await pool.query(
  'SELECT * FROM orders WHERE user_id = $1 AND status = $2',
  [userId, status]
);

Frequently Asked Questions

Questions fréquentes