La sécurité au cœur de chaque projet

Ce que « sécuriser » veut dire, et ce que cela ne dit pas

En résumé : La sécurité est une propriété du système entier, pas une fonctionnalité qu'on active. Un site peut satisfaire toutes les cases techniques et rester vulnérable par son organisation.

Le mot recouvre trois questions distinctes qu'on gagne à séparer. Qui peut accéder à quoi : c'est l'authentification et les autorisations. Ce qui se passe si quelqu'un accède quand même : c'est le chiffrement, la journalisation et la capacité à restaurer. Et ce qui se passe si personne n'accède mais que le service s'arrête : c'est la disponibilité, souvent oubliée dans les discussions de sécurité alors qu'elle en fait partie.

Une confusion fréquente consiste à traiter la sécurité comme une couche ajoutée en fin de projet. Elle se décide surtout au moment de la conception : quelles données sont collectées, où elles vivent, qui les voit, combien de temps elles sont conservées. Ces choix-là déterminent la surface à défendre. Les mesures techniques qui viennent après ne font que protéger ce qui a déjà été décidé.

Aucune de ces mesures ne rend un système inviolable, et une page qui le laisserait entendre mentirait. Elles rendent une attaque plus coûteuse, plus lente et plus visible. C'est l'objectif réel : déplacer le rapport entre l'effort d'un attaquant et ce qu'il obtient.

Chiffrement : en transit et au repos

En résumé : Le chiffrement de transport protège ce qui circule ; le chiffrement au repos protège ce qui est stocké. Les deux répondent à des menaces différentes et aucun ne remplace l'autre.

HTTPS chiffre la communication entre le navigateur et le serveur : sans lui, tout ce qui transite sur un réseau partagé est lisible. C'est aujourd'hui un prérequis, pas une option, et les certificats se renouvellent automatiquement, ce qui a supprimé l'excuse du coût et de l'oubli d'échéance.

Le chiffrement au repos protège autre chose : ce qui reste sur un disque, une sauvegarde ou un instantané de base. Il vise le cas où quelqu'un obtient le support physique ou une copie du stockage. Il ne protège en revanche pas contre un compte compromis qui a le droit de lire ces données — c'est le rôle du contrôle d'accès, pas du chiffrement.

Accès : prouver qui l'on est, et n'obtenir que ce qui suit

En résumé : L'authentification établit une identité ; l'autorisation décide ce que cette identité peut faire. La seconde est plus souvent négligée que la première, et ses défauts sont plus coûteux.

Un mot de passe seul est un facteur unique : quiconque l'obtient devient l'utilisateur. L'authentification à plusieurs facteurs ajoute un élément que l'attaquant doit obtenir séparément, ce qui rend l'hameçonnage nettement moins rentable. Sur les comptes qui administrent un site, c'est la mesure au meilleur rapport entre effort et effet.

L'autorisation pose une question différente : une fois connecté, que peut faire chaque compte ? Le principe utile est celui du moindre privilège — un compte ne reçoit que les droits nécessaires à sa tâche, et les perd quand la tâche s'arrête. Les incidents les plus longs à contenir viennent souvent de comptes qui pouvaient plus que ce que leur usage réel demandait.

Les jetons de session méritent la même attention que les mots de passe : durée de validité courte, révocation possible, et rotation. Un jeton qui ne périme jamais est un mot de passe permanent que son porteur ne peut pas changer.

La surface exposée : formulaires, API et en-têtes

En résumé : Tout ce qu'un visiteur peut envoyer est une entrée non fiable. La règle tient en une phrase : valider côté serveur, échapper à l'affichage, limiter le débit.

Une validation faite uniquement dans le navigateur ne protège de rien : elle améliore le confort de saisie, mais un attaquant n'utilise pas le navigateur. La validation qui compte est celle du serveur, exprimée par un schéma explicite qui décrit ce qui est accepté plutôt que ce qui est refusé — une liste de refus oublie toujours un cas.

L'échappement protège d'un autre problème : du contenu envoyé par un visiteur et réaffiché tel quel peut exécuter du code chez le suivant. La règle est d'échapper au moment de l'affichage, en fonction du contexte, et jamais de faire confiance à un nettoyage effectué à l'entrée.

La limitation de débit et les champs pièges répondent aux envois automatisés. Ils ne bloquent pas un attaquant déterminé, et il faut le savoir : ils écartent le bruit de fond, ce qui suffit pour un formulaire de contact et ne suffit pas pour une page de connexion, qui demande en plus un verrouillage progressif.

Les en-têtes HTTP de sécurité complètent l'ensemble en indiquant au navigateur ce qu'il doit refuser : quelles sources de scripts accepter, qui a le droit d'afficher le site dans un cadre, s'il faut deviner le type d'un fichier. Ils se vérifient sur la réponse réelle du serveur, jamais sur la configuration.

Données : conservation, sauvegardes et obligations

En résumé : La donnée la mieux protégée est celle qu'on n'a pas collectée. Ensuite viennent la durée de conservation, la restauration testée, et les obligations propres au cadre applicable.

La minimisation est la mesure la plus efficace et la moins coûteuse : chaque champ collecté est un champ à protéger, à conserver, à supprimer et à justifier. Avant de sécuriser une donnée, il vaut la peine de vérifier qu'elle sert réellement à quelque chose.

Une sauvegarde qui n'a jamais été restaurée est une hypothèse, pas une garantie. Ce qui se vérifie, c'est la restauration : combien de temps elle prend, ce qu'elle perd, et qui sait l'exécuter. Une sauvegarde accessible depuis le système qu'elle protège offre par ailleurs peu de secours en cas de rançongiciel.

Des obligations existent en matière de données personnelles — information des personnes, durée de conservation, droit d'accès et de suppression. Leur contenu exact dépend du cadre applicable à l'organisation et se fait préciser par un professionnel habilité ; ce qui relève du projet, c'est de rendre ces obligations techniquement réalisables plutôt que de les découvrir après coup.

Ce que la sécurité technique ne résout pas

En résumé : Les mesures décrites ici protègent un système. Elles ne protègent ni contre une organisation qui les contourne, ni contre un fournisseur compromis, ni contre une erreur de conception.

La plupart des intrusions n'exploitent pas une faille logicielle : elles empruntent un accès légitime obtenu par hameçonnage ou par réutilisation d'un mot de passe. Aucun en-tête HTTP n'empêche cela. Ce qui l'empêche est un second facteur, et des personnes qui savent à quoi ressemble une tentative.

Un projet dépend de bibliothèques qu'il n'écrit pas et de services qu'il n'héberge pas. Surveiller ces dépendances et savoir les mettre à jour fait partie du travail ; croire que la surface s'arrête au code écrit sur mesure est une erreur d'appréciation.

Enfin, la sécurité ne rattrape pas une erreur de conception. Si une donnée n'aurait pas dû être collectée, la chiffrer ne fait que déplacer le problème. La question à poser en premier n'est pas comment protéger cette donnée, mais si elle doit exister.