fix(securite): supprime le secret JWT de repli présent dans le dépôt

JWT_SECRET retombait sur "data-sentinel-secret-change-in-prod", une valeur
lisible par quiconque a accès au code : un oubli de configuration suffisait
à permettre de forger un jeton d'administrateur.

Sans JWT_SECRET, une clé aléatoire est désormais tirée au démarrage, avec un
avertissement explicite. Le démarrage n'est volontairement pas bloqué : un
oubli de variable d'environnement ne doit pas transformer une configuration
incomplète en indisponibilité totale du service. Contrepartie assumée et
documentée : les sessions ne survivent pas à un redémarrage tant que la
variable n'est pas définie.

Vérifié : la production signe déjà avec un secret propre, ce correctif ne
change donc rien à son fonctionnement.

Ajoute par ailleurs APP_BUILD, injecté par la CI depuis le SHA du commit et
exposé par GET /health (et /version.json côté front). Jusqu'ici, rien ne
permettait de savoir quelle version tournait réellement : un déploiement
non appliqué était indiscernable d'un déploiement réussi.
This commit is contained in:
2026-08-15 14:46:49 +02:00
parent cb84e20e9a
commit 4bc4770e2d
6 changed files with 74 additions and 6 deletions
+8 -1
View File
@@ -81,7 +81,13 @@ async def security_headers(request: Request, call_next):
@app.get("/health", tags=["Système"])
def health_check():
"""Ping API + test connexion SQL Server."""
"""
Ping API + test connexion SQL Server.
`build` porte le SHA du commit dont l'image a été construite (injecté par
la CI). C'est le seul moyen fiable de vérifier qu'un déploiement a bien
pris : comparer ce champ au dernier commit poussé.
"""
try:
with get_cursor() as cursor:
cursor.execute("SELECT 1")
@@ -94,6 +100,7 @@ def health_check():
"api" : "ok",
"database" : db_status,
"version" : Config.API_VERSION,
"build" : Config.BUILD,
"nb_monitorings" : len(MONITO_TABLES),
}