Expression de Besoin — PD-19¶

Configurer CORS et Security Headers¶

1. Objet¶

Définir les exigences fonctionnelles et non fonctionnelles relatives à la maîtrise de l'exposition HTTP du backend ProbatioVault, afin de limiter les usages non prévus, les abus triviaux et les interprétations dangereuses par des agents clients (navigateurs, scripts, intermédiaires), indépendamment de la logique métier et cryptographique.

2. Contexte¶

2.1 Contexte fonctionnel¶

ProbatioVault est une application de coffre-fort numérique probatoire manipulant des données sensibles (documents probatoires, preuves cryptographiques, informations personnelles).

Le backend expose une API critique servant à : - L'authentification - L'orchestration de flux cryptographiques - L'accès à des ressources probatoires à forte valeur juridique - L'interfaçage avec des composants sensibles (HSM, horodatage, ancrage)

Cette API est accessible via Internet et est donc structurellement exposée à des acteurs non maîtrisés, y compris en dehors de tout scénario d'attaque sophistiquée.

2.2 Contexte technique (état actuel)¶

Le backend NestJS 10 avec Express est actuellement configuré avec : - Helmet.js v7.1.0 en configuration par défaut - CORS basique (origine unique via variable d'environnement CORS_ORIGIN) - Aucun mécanisme de rate limiting

L'API sera consommée par : - Une application mobile iOS/Android - Une Progressive Web App (PWA) - Potentiellement des intégrations tierces (B2B)

2.3 Périmètre¶

Inclus : - Toutes les interfaces HTTP exposées par le backend - Tous les environnements accessibles hors réseau interne strict - Tous les types de clients (navigateurs, scripts, applications)

Explicitement exclu : - La protection contre des attaques distribuées de grande ampleur (DDoS réseau) - La sécurité cryptographique des données - La gestion des clés, des identités ou des preuves - La détection d'attaques complexes ou ciblées - L'authentification et l'autorisation (JWT, sessions, permissions)

Ces exclusions sont conscientes et ne constituent pas un oubli.

3. Objectifs¶

3.1 Objectif principal¶

Réduire la surface d'exploitation involontaire du backend en encadrant strictement : - Les contextes dans lesquels l'API peut être appelée - La manière dont les réponses peuvent être interprétées par un client - La fréquence et l'intensité des appels acceptables

3.2 Objectifs secondaires¶

• Prévenir les abus non sophistiqués (scripts, erreurs client, intégrations sauvages)
• Éviter qu'un navigateur ou un agent tiers n'exploite des comportements par défaut non intentionnels
• Poser un socle de sécurité homogène applicable à l'ensemble du backend
• Garantir la transparence et l'auditabilité de la configuration de sécurité

4. Exigences fonctionnelles¶

EF-1 — Encadrement des contextes d'appel¶

Le backend doit restreindre les contextes dans lesquels ses interfaces peuvent être appelées depuis des agents clients susceptibles d'exécuter du code ou d'interpréter dynamiquement les réponses.

EF-2 — Neutralité d'interprétation des réponses¶

Le backend doit empêcher que ses réponses puissent être interprétées, exécutées ou détournées d'une manière non explicitement prévue par l'intention fonctionnelle initiale.

EF-3 — Limitation des usages excessifs¶

Le backend doit refuser ou contenir les usages caractérisés par une fréquence ou une intensité anormale, même lorsque les requêtes sont formellement valides.

5. Exigences non fonctionnelles¶

ENF-1 — Indépendance vis-à-vis du métier¶

Les mécanismes répondant à ce besoin ne doivent pas dépendre de la logique métier, du type d'utilisateur ou du contenu manipulé.

ENF-2 — Application transversale¶

Les exigences doivent s'appliquer de manière cohérente et systématique à l'ensemble des points d'exposition HTTP.

ENF-3 — Comportement prévisible¶

Le backend doit adopter un comportement déterministe et documentable face aux usages non conformes (refus, limitation, neutralisation).

ENF-4 — Différenciation par environnement¶

La configuration doit être adaptable par environnement (dev, test, prod) sans modification du code.

6. Contraintes¶

6.1 Juridiques et réglementaires¶

• RGPD : Les headers ne doivent pas exposer d'informations sur l'infrastructure (Server, X-Powered-By)
• eIDAS : L'intégrité des réponses API doit être garantie contre le tampering côté client

6.2 Temporelles¶

• La story fait partie du sprint de consolidation BACKEND-CORE
• Doit être compatible avec les développements en cours sur l'authentification (PD-32)

6.3 Organisationnelles¶

• Les développeurs front-end doivent pouvoir travailler en local sans être bloqués par les restrictions
• La configuration doit être documentée et auditable

7. Résultats inacceptables¶

Sont considérés comme inacceptables :

8. Tensions et conflits non résolus¶

Ouverture vs restriction¶

L'API doit rester intégrable par des clients légitimes tout en empêchant les usages non autorisés.

Tolérance vs protection¶

Un usage excessif peut résulter d'une erreur légitime (retry sur mauvaise connexion) ou d'un abus intentionnel.

Sécurité vs simplicité¶

Un durcissement excessif peut nuire à l'expérience développeur ou aux tests.

Partenaires B2B¶

Les intégrations B2B nécessitent des origines spécifiques. Comment gérer dynamiquement les partenaires sans redéploiement ?

Ces tensions sont acceptées et non arbitrées dans cette Expression de Besoin.

9. Questions ouvertes¶

1. Quelles origines doivent être autorisées en production ?
2. Domaines des apps (mobile, PWA) ?

3. Sous-domaines autorisés ou liste fixe ?

4. Quels seuils de limitation sont acceptables ?

5. Global par IP ?
6. Par endpoint (plus strict sur /auth/login) ?

7. Quel window (par seconde, par minute) ?

8. La limitation doit-elle être bypassable pour certains clients ?

9. API keys partenaires ?

10. IPs whitelistées ?

11. Comment notifier les équipes en cas de limitation déclenchée ?

12. Logs uniquement ?
13. Alerting ?
14. Métriques (Prometheus) ?

10. Hypothèses implicites assumées¶

• Le backend sera attaqué, testé, sondé, même sans motivation ciblée.
• Les erreurs de configuration sont inévitables à long terme.
• La sécurité repose aussi sur la réduction des comportements possibles, pas uniquement sur la robustesse du code.

11. Positionnement de PD-19¶

PD-19 constitue : - Une couche de sécurité de surface - Un pré-requis d'exploitation saine - Une base nécessaire mais non suffisante pour un backend critique

Elle ne prétend pas garantir la sécurité globale du système.

Document produit par le workflow de gouvernance IA — Étape 0 Date : 2026-02-09