Tests

Sécurité : périmètre, attendus et preuves

En bref :

  • Ce n’est pas un pentest : la page transforme les constats de l’audit en conditions vérifiables avant ouverture au public.
  • POC de novembre : aucun secret livré, liste blanche des champs, test de non-divulgation, aucune unité ZRR. Avant lancement : tests, pentest et gate ci-dessous.
  • Les constats sur l’existant LPI sont tenus à jour dans une seule page : sécurité et RGPD.

Modèle de menace public

L’ouverture Internet rend ordinaires les scénarios suivants :

  • robots et scraping massif ;
  • déni de service applicatif et requêtes coûteuses ;
  • énumération de profils et de champs ;
  • injection dans la recherche ou les contenus ;
  • découverte d’interfaces d’administration ;
  • vol de token après XSS ;
  • accès horizontal à la donnée d’un autre utilisateur ;
  • empoisonnement ou confusion du cache ;
  • fuite de secrets dans le bundle, les URLs ou les logs ;
  • compromission d’un compte éditorial ou de la chaîne CI/CD.

Minimum exigé dès le POC

  • Aucun secret, jeton ou clé d’API dans le site généré ni dans ses sources publiées.
  • Données issues d’une liste blanche de champs ; tout nouveau champ est privé par défaut.
  • Aucune unité ZRR dans le corpus, liste des structures validée par le FSD.
  • Test de non-divulgation : recherche, dans les pages générées, des champs exclus (emails, téléphones, identifiants internes).

Architecture de sécurité attendue

Architecture de sécurité attendue
Chargement du schéma pédagogique...

Frontière publique

  • pages générées depuis un export en liste blanche, sans API publique dans la Partie 1 ;
  • aucune dépendance à Keycloak pour consulter une fiche ;
  • aucun accès direct du navigateur à Neo4j, Apollo ou une API d’administration ;
  • méthodes, tailles, pagination et coûts bornés ;
  • rate limiting au CDN/WAF ;
  • validation stricte des entrées et réponses amont ;
  • contenu riche assaini ;
  • protection contre SSRF et redirections ouvertes.

Surfaces privées

Doivent rester non joignables depuis Internet, sauf interface explicitement protégée :

  • administration Django ;
  • Swagger ou schéma interne ;
  • console Apollo et introspection non maîtrisée ;
  • Neo4j, PostgreSQL, Redis et OpenSearch ;
  • métriques, traces et endpoints de diagnostic ;
  • files, webhooks non authentifiés et outils de synchronisation.

Headers et navigateur

  • CSP sans unsafe-eval en production et sources tierces minimales.
  • HSTS après validation de tous les sous-domaines concernés.
  • X-Content-Type-Options: nosniff.
  • Referrer-Policy adaptée aux liens externes et identifiants dans les URLs.
  • Permissions-Policy restrictive.
  • Protection contre l’intégration en iframe selon le besoin.
  • Cookies éventuels Secure, HttpOnly et SameSite adaptés.
  • Aucun secret dans le JavaScript, les source maps publiques ou les variables exposées.
Si la contribution des chercheurs est ouverte (Partie 2)
  • authentification multifacteur lorsque possible ;
  • autorisation objet sur chaque lecture et écriture ;
  • séparation entre proposition, validation et publication ;
  • protection CSRF et contrôle strict des origines ;
  • historique et auteur des modifications ;
  • notification des actions sensibles ;
  • expiration des sessions et révocation ;
  • tests de rôle chercheur, valideur, administrateur et utilisateur externe.

Cette interface doit faire l’objet d’un modèle de menace distinct. Elle ne doit pas être introduite implicitement dans la première version publique.

Données personnelles

  • projection publique privée par défaut pour tout nouveau champ ;
  • absence de coordonnées personnelles non nécessaires ;
  • matrice champ × source × finalité × base légale × rétention ;
  • information des personnes et canal de rectification ;
  • propagation de la correction dans index, cache, export, analytics et sauvegardes ;
  • logs et traces expurgés ;
  • screening AIPD avec le DPO ;
  • exclusion des unités ZRR/PPST par liste blanche à l’export, validée par le FSD ;
  • localisation, sous-traitants et transferts documentés.

Tests attendus

  • Analyse statique, dépendances et secret scanning dans la CI.
  • Inspection du bundle et des source maps.
  • Tests d’autorisation négatifs sur toutes les routes.
  • Tests IDOR sur les actions non standard.
  • Tests CORS et CSRF depuis une origine non autorisée.
  • Tests XSS sur recherche, contenus riches et paramètres d’URL.
  • Tests SSRF sur les imports ou médias distants éventuels.
  • Tests des limites de débit, pagination, export et coût GraphQL.
  • Scan externe autorisé des domaines et ports exposés.
  • Pentest indépendant sur l’environnement représentatif.
  • Exercice de rotation d’un secret et de restauration.
  • Retest des findings critiques et élevés après déploiement du correctif.

Répartition des actions

Paris-Saclay peut réaliser sans LPI

  • définir le modèle de menace de la vitrine cible ;
  • définir la liste des champs publiables ;
  • choisir les headers, le CDN/WAF et les critères de pentest ;
  • construire un frontend public sans secret ni authentification ;
  • préparer les tests de non-divulgation ;
  • définir le processus incident, DPO et RSSI ;
  • exiger une API ou un export en lecture seule.

Preuves à obtenir de LPI

Voir le registre des questions (Q1, Q5, Q8, Q12, Q13).

Gate de sécurité

Le go public est refusé si :

  • un secret actif reste livré au navigateur ;
  • une écriture non autorisée reste reproductible ;
  • la séparation public/privé n’est pas démontrée ;
  • un finding critique ou élevé reste sans correction ou acceptation formelle ;
  • les données publiques ne reposent pas sur une liste blanche ;
  • une unité ZRR ou un champ non publiable apparaît dans les pages générées ;
  • aucune preuve n’est rattachée à la version réellement déployée.
Last modified on