# SEC-16 — PostgreSQL : TLS incohérent et certificat non authentifié

**Gravité : Moyenne, avant correction.**

**État au 14 septembre 2026 :** Chemins principaux corrigés dans le code suivi ; confiance CA et scripts secondaires à vérifier.

## Executive Summary

Un intermédiaire capable de détourner la connexion d'un client PostgreSQL est la menace pour l'identité du serveur. Un second effet concerne simplement la disponibilité : un client n'activant pas TLS ne peut pas joindre une base configurée pour exiger hostssl. Ces deux effets ne doivent pas être confondus avec une injection SQL.

Le snapshot préaudit `8446f87` est la version vulnérable vérifiée ; le correctif est présent dans `c09b8be`. Aucun tag local ni version de production vérifiée ne permet d'annoncer une première release affectée ou une release déployée corrigée. La validation combine relecture du source et tests locaux documentés ; aucun incident réel n'est affirmé.

## Background

La frontière de sécurité est celle décrite par les prérequis ci-dessus. Le paramétrage fourni par le dépôt ne permet pas de connaître la topologie et les valeurs effectivement en ligne. Les preuves disponibles doivent donc être lues séparément des conditions de déploiement restant à vérifier.

## Vulnerability Details

Dans le snapshot préaudit, la CLI TypeORM active `ssl` si DATABASE_SSL vaut true mais fournit `rejectUnauthorized: false`. L'API et les clients de démarrage n'appliquent pas ce même drapeau. Le même opérateur pouvait donc croire que DATABASE_SSL sécurisait tous les accès alors que chaque chemin avait une politique différente. La configuration de production fournie dans le dépôt décrit une base hostssl, mais son application effective n'a pas été testée. Un chiffrement sans authentification du certificat ne suffit pas contre un relais actif ; une connexion sans TLS à une base qui l'exige échoue plutôt que de devenir implicitement sûre.

Sources courantes, fonctions et tests concernés :

- [apps/backend/src/infrastructure/persistence/typeorm/database-tls.ts](../../apps/backend/src/infrastructure/persistence/typeorm/database-tls.ts)
- [apps/backend/src/infrastructure/persistence/typeorm/data-source.ts](../../apps/backend/src/infrastructure/persistence/typeorm/data-source.ts)
- [apps/backend/src/app.module.ts](../../apps/backend/src/app.module.ts)
- [apps/backend/scripts/setup/startup.js](../../apps/backend/scripts/setup/startup.js)
- [apps/backend/scripts/setup/run-migrations.js](../../apps/backend/scripts/setup/run-migrations.js)
- [apps/backend/src/infrastructure/persistence/typeorm/database-tls.spec.ts](../../apps/backend/src/infrastructure/persistence/typeorm/database-tls.spec.ts)
- [apps/backend/src/infrastructure/persistence/typeorm/database-startup.spec.ts](../../apps/backend/src/infrastructure/persistence/typeorm/database-startup.spec.ts)

Pour comparer au snapshot vulnérable, consulter ces mêmes chemins dans la révision citée, sans supposer que les numéros de lignes actuels correspondent à l'ancienne version.

## Exploitability Analysis

Risque d'interception ou de modification du trafic pour les clients sans vérification d'identité, sous contrôle réseau actif ; risque d'échec de démarrage ou de migration pour les chemins incompatibles. Aucune base réelle, aucun credential de production et aucune migration en ligne n'ont été utilisés. Le port accessible publiquement, les règles réseau et le certificat réel restent inconnus.

Le problème ne requiert pas de supprimer les contrôles métier ou cryptographiques voisins. Il exploite précisément la différence entre le contrôle attendu et celui effectivement exécuté. Les contre-exemples ci-dessous précisent ce que les tests isolent ; ils ne constituent pas un test de pénétration du site en ligne.

## Proof of Concept

La passe du 10 septembre documente 11 tests du helper et de handshakes TLS locaux : certificat approuvé pour la bonne IP accepté, chaîne non approuvée et identité IP incorrecte refusées. Deux tests de démarrage vérifient la transmission des options en simulant PostgreSQL/TypeORM. Aucun test contre le serveur de production ne prouve la distribution effective de sa CA.

Les artefacts sont déjà dans les fichiers de test liés ci-dessus. Aucun faux journal d'exploitation ni nouvelle commande d'attaque de production n'est fourni. Voir [VALIDATION.md](../VALIDATION.md) pour le périmètre et les résultats consolidés.

## Remediation

`databaseTlsOptions` est partagé par app.module, data-source, startup, run-migrations et l'entrypoint historique. Avec DATABASE_SSL=true, il exige la chaîne approuvée et l'identité de DATABASE_HOST. DATABASE_SSL_CA permet d'ajouter le certificat public de confiance ; son absence conserve les autorités Node et ne désactive pas la vérification. Le mode false demeure possible et doit être réservé aux topologies qui le justifient. Ne pas distribuer de clé privée. Les scripts de maintenance hors chemins principaux n'ont pas tous été recensés et alignés.

La présente passe documente ce changement antérieur ; elle n'ajoute aucun correctif applicatif et ne confirme pas son déploiement.

## Summary

Le mécanisme décrit est confirmé dans la révision vulnérable citée, et la portée du correctif local est bornée par les tests disponibles. Chemins principaux corrigés dans le code suivi ; confiance CA et scripts secondaires à vérifier. Les limites de couverture générale sont détaillées dans [COUVERTURE.md](../COUVERTURE.md).