fix(security): check_secrets.py ne détecte pas un PIN en query string (?pin=) #58

New Issue

2026-09-13T10:22:04+02:00

OpenCode commented

2026-09-13 10:22:04 +02:00

Constat

Relevé lors de la revue d'OpenCode de la PR #53 (fix(security): détecter les PIN Pronote littéraux, fusionnée).

scripts/check_secrets.py couvre désormais les noms *_PIN pour les affectations littérales (quotées et non quotées, _LITERAL_SECRET_RE / _UNQUOTED_SECRET_RE), mais _URL_SECRET_RE — qui cible les secrets présents dans une query string — n'a pas été étendu à pin.

Impact

Une fuite de type https://example.com/api?pin=1234 (ou &pin=1234) n'est pas détectée par le scanner, alors que les autres identifiants sensibles (password, secret, token, icalsecurise, …) le sont. Incohérence de couverture dans un contrôle à vocation fail-closed.

Sévérité estimée : faible. Le PIN d'authentification QR/compte Pronote ne transite pas par une URL dans l'architecture actuelle ; c'est une lacune de durcissement, pas une exploitation directe.

Correctif attendu

Ajouter pin à l'alternance de noms de _URL_SECRET_RE (scripts/check_secrets.py).
Vérifier qu'aucun test ou fixture du dépôt ne contient de placeholder d'URL ?pin=… qui deviendrait un faux positif (sinon étendre la liste blanche de placeholders d'URL _URL_PLACEHOLDER_RE).
Ajouter un test de détection positive (?pin=<PIN sentinelle> détecté, valeur non imprimée) et vérifier la non-régression de la suite existante.

Contexte

Observation non bloquante documentée dans le compte rendu de revue d'OpenCode sur PR #53.
Le commit de la PR #53 porte l'intention « limiter PIN aux affectations » ; ce ticket acte la décision de couvrir aussi les URL si un tel usage apparaît.

## Constat Relevé lors de la revue d'OpenCode de la PR #53 (`fix(security): détecter les PIN Pronote littéraux`, fusionnée). `scripts/check_secrets.py` couvre désormais les noms `*_PIN` pour les **affectations littérales** (quotées et non quotées, `_LITERAL_SECRET_RE` / `_UNQUOTED_SECRET_RE`), mais `_URL_SECRET_RE` — qui cible les secrets présents dans une *query string* — n'a **pas** été étendu à `pin`. ## Impact Une fuite de type `https://example.com/api?pin=1234` (ou `&pin=1234`) n'est pas détectée par le scanner, alors que les autres identifiants sensibles (`password`, `secret`, `token`, `icalsecurise`, …) le sont. Incohérence de couverture dans un contrôle à vocation *fail-closed*. Sévérité estimée : **faible**. Le PIN d'authentification QR/compte Pronote ne transite pas par une URL dans l'architecture actuelle ; c'est une lacune de durcissement, pas une exploitation directe. ## Correctif attendu - Ajouter `pin` à l'alternance de noms de `_URL_SECRET_RE` (`scripts/check_secrets.py`). - Vérifier qu'aucun test ou fixture du dépôt ne contient de placeholder d'URL `?pin=…` qui deviendrait un faux positif (sinon étendre la liste blanche de placeholders d'URL `_URL_PLACEHOLDER_RE`). - Ajouter un test de détection positive (`?pin=<PIN sentinelle>` détecté, valeur non imprimée) et vérifier la non-régression de la suite existante. ## Contexte - Observation non bloquante documentée dans le compte rendu de revue d'OpenCode sur PR #53. - Le commit de la PR #53 porte l'intention « limiter PIN aux affectations » ; ce ticket acte la décision de couvrir aussi les URL *si un tel usage apparaît*.

OpenCode added the priority:low area:security labels 2026-09-13 10:22:04 +02:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: AntoineVe/college-infos#58

fix(security): check_secrets.py ne détecte pas un PIN en query string (?pin=) #58

Constat

Impact

Correctif attendu

Contexte

fix(security): `check_secrets.py` ne détecte pas un PIN en query string (`?pin=`) #58