La plupart des sites web d'établissements d'enseignement supérieur offrent un accès public à certaines données de leur annuaire interne.

Les annuaires contiennent des données à caractère personnel, pour lesquelles les établissements sont tenus de prendre les dispositions nécessaires à leur protection.
Cette page fournit de plus amples informations sur les obligations issues de la législation et que la CNIL se charge de faire respecter.

Ces interfaces publiques aux annuaires doivent garantir un bon niveau de protection des données pour être en conformité avec la législation en vigueur.

Garantir une bonne protection des données signifie mettre en oeuvre des mesures qui ont pour objectif de contourner les «failles» potentielles qui pourraient exister. Par «faille» il faut entendre tout comportement de l'interface web qui permet trop facilement d'obtenir de grandes quantités d'informations, par consultation manuelle et surtout par des consultations automatisées (robots).

Le texte ci-dessous, ne donne pas le détails précis des mesures techniques à mettre en oeuvre, tant les solutions logicielles des interfaces peuvent être différentes. Seules des recommandations “génériques” sont affichées.

L'objectif des recommandations ci-dessous est double: permettre de conserver un accès public à certaines données de l'annuaire (service utile) et assurer une protection de ces données, notamment éviter le “moissonnage” de ces données et éventuellement éviter que les résultats obtenus soit utilisables de façon automatisée.

Recommandations :

• Agir sur les catégories d'informations pouvant être consultées, la liste suivante : “Nom, Prénom, Email, Téléphone, Affectation” pourrait être considérée comme suffisante;
• L’utilisation des Wildcards peut permettre tous les abus suivant l'implémentation qui en est faite. Dans certains cas, il suffit d'un simple script pour pouvoir récupérer quantité d'information.! Solutions pour éviter cela:
  • soit interdire les wild-card, mais il faut admettre que l'interface de consultation perd de son intérêt;
  • permettre l'utilisation de wild-card, mais dans ce cas:
    • y rajouter un système type “test de Turing” (voir cette page ) pouvant empêcher les scripts de nuire. Ce genre de système peut d'ailleurs être utilisé wildcard ou pas, c'est encore mieux;
    • rajouter une contrainte: obligation de saisir au moins 3 lettres (en dehors des “whitespace” sinon plus dans le cas de wild-card;
• Limiter le nombre de résultats transmis (10 devraient bien suffire);
• Limiter le nombre de requêtes (dans une plage de temps) en provenance d'une adresse IP particulière.
• S'assurer de la robustesse de l'interface aux attaques telles qu'injection SQL.
  • voir cet avis CERTA concernant la sécurité des sites web et l'injection de données
  • certains sites ne filtrent pas les messages d’erreur, et dans ce cas il devient possible de voir partiellement les requêtes initiales, et d’y introduire des expressions qui retourneront toujours «vrai» (tout bêtement « 1 = 1 ») et dans certains cas toute une liste d'entrées annuaire est retournée!

Certains logiciels commerciaux de gestion des sites web éprouvent quelques difficultés (pour ne pas être trop dur) à appliquer certaines des recommandations ci-dessus. A vous de bien vérifier leurs capacités de filtrage des requêtes.

Les logiciels, dits “maison”, développés en PHP notamment (mais il n'y a pas que PHP) doivent faire l'objet d'attentions particulières au vu de l'avis CERTA ci-dessus.