Surface d'attaque : pourquoi un site statique est le comble du bonheur

On demande rarement à un prestataire par où l’on peut entrer dans le site qu’il vient de livrer. C’est pourtant la question qui décide de tout le reste : des mises à jour, du coût de maintenance, du risque, et de ce qui se passera un dimanche soir de janvier quand une faille sera rendue publique.

Ce que les spécialistes appellent la surface d’attaque, c’est exactement cela : l’ensemble des points par lesquels quelqu’un peut tenter d’entrer.

Ce qu’un site classique expose#

Prenez un site de gestion de contenu ordinaire, du type de ceux qui équipent la majorité des sites d’entreprise. Voici, sans exagération, ce qui tourne derrière la page d’accueil :

• un interpréteur qui exécute du code à chaque visite ;
• une base de données, avec ses identifiants ;
• une interface d’administration accessible depuis internet, avec une page de connexion ;
• une dizaine d’extensions, chacune écrite par une équipe différente, avec ses propres dépendances ;
• un module de mise en page, souvent le plus gros morceau de code du site ;
• des formulaires qui écrivent en base ;
• parfois un espace de dépôt de fichiers ;
• et autant de comptes que de personnes ayant un jour eu besoin d’accéder à quelque chose.

Chacun de ces éléments est une porte. Aucune n’est fautive en soi. Mais elles ne se mettent pas à jour toutes seules, elles ne vieillissent pas au même rythme, et il suffit qu’une seule cède pour que tout le reste soit accessible.

Un point mérite d’être souligné, parce qu’il est contre-intuitif : dans l’immense majorité des incidents que nous constatons, la faille n’est pas dans le cœur du logiciel, qui est corrigé vite et bien. Elle est dans une extension installée trois ans plus tôt pour un besoin ponctuel, dont l’auteur a cessé la maintenance, et que plus personne ne se rappelle avoir activée.

Ce qu’un site statique expose#

Des fichiers.

C’est tout, et c’est le point entier de la démarche. Un site statique est construit une fois, sur la machine du développeur ou dans une chaîne d’intégration, puis déposé sous forme de pages déjà écrites. Le serveur qui les distribue ne fait rien d’autre que les envoyer : il n’interprète aucun code, n’interroge aucune base, n’expose aucune page de connexion.

Les conséquences sont directes :

• Aucune injection possible dans une base qui n’existe pas.
• Aucune administration à forcer : il n’y a pas de porte, donc pas de serrure à crocheter ni de mot de passe à deviner.
• Aucun correctif urgent : pas de faille activement exploitée à colmater dans la nuit.
• Aucune dégradation silencieuse : un site statique laissé tel quel deux ans fonctionne exactement comme au premier jour. Un site dynamique laissé tel quel deux ans est une vulnérabilité qui attend son tour.

Ce site-ci est construit ainsi. Il est produit à chaque publication, déposé sur un espace de stockage, et distribué tel quel. Nous en détaillons le fonctionnement et le coût dans notre méthode dédiée aux sites statiques.

Ce que le statique ne protège pas#

Un article qui s’arrêterait là serait malhonnête. Le statique déplace la surface d’attaque, il ne la supprime pas. Voici ce qui reste, et qu’il faut traiter :

Le nom de domaine. C’est aujourd’hui le point le plus exposé de beaucoup de projets, et le moins surveillé. Quelqu’un qui prend la main sur votre compte chez le bureau d’enregistrement redirige votre domaine où il veut, en quelques minutes, sans avoir touché à une seule ligne de votre site. Double authentification obligatoire, verrou de transfert activé, et surveillance de la date d’expiration : nous avons vu ce qui arrive quand ces trois points sont négligés en écrivant sur le prestataire injoignable.

La configuration de l’hébergement. Un espace de stockage ouvert en écriture au monde entier annule tout le bénéfice : n’importe qui remplace vos fichiers. Cette erreur de configuration est l’une des plus répandues, et elle ne produit aucun symptôme visible avant l’incident.

La chaîne de construction. C’est là que se déplace le risque : les dépendances utilisées pour fabriquer le site, les jetons d’accès stockés dans l’outil d’intégration, les droits de publication. Une dépendance compromise injecte du code dans les pages générées, et personne ne le remarque au premier coup d’œil. C’est un risque réel, mais il a une qualité : il s’exerce avant la mise en ligne, dans un périmètre restreint et vérifiable, pas en continu sur un serveur exposé.

Les scripts tiers. Un site statique dans lequel on colle cinq balises de suivi et une bibliothèque chargée depuis un domaine inconnu redevient un site qui exécute du code étranger chez vos visiteurs. Le format ne protège de rien si l’on rouvre soi-même la porte.

Quand ça ne suffit pas#

Le statique n’est pas une religion, et il y a des cas où il ne convient pas seul :

• un espace personnel avec authentification ;
• un paiement et un panier ;
• un stock ou une disponibilité qui doivent être justes à la seconde ;
• un contenu personnalisé par visiteur ;
• des volumes de contenu modifiés en permanence par plusieurs équipes.

Dans ces situations, la bonne réponse n’est presque jamais « il faut donc un site dynamique complet ». Elle est de combiner : des pages statiques pour tout ce qui ne bouge pas — c’est-à-dire l’écrasante majorité d’un site — et un point d’entrée dynamique isolé, réduit à sa fonction, pour ce qui l’exige réellement.

Nous appliquons cette règle à notre propre site. Il est intégralement statique, à une exception près : l’assistant de recherche, qui a besoin d’un traitement en ligne. Cette exception ne s’exécute pas dans le site : c’est un service séparé, avec sa propre origine autorisée, sa limitation de débit, son quota journalier et son plafond de consommation. S’il tombe, ou s’il est attaqué, le site continue de fonctionner — parce qu’il n’en dépend pas.

Ce que ça change au quotidien#

L’argument de sécurité est le plus solide, mais ce n’est pas celui que les dirigeants retiennent. Ce qu’ils retiennent, c’est ceci :

La dernière ligne est celle qui compte. Ce n’est pas le coût d’un site statique qui séduit, c’est l’absence d’urgences.

Le comble du bonheur, vraiment ?#

Pour un site vitrine, un site d’artisan, un site institutionnel, un blog d’entreprise, une plaquette de services : oui, sans réserve. Ce sont des sites dont le contenu change quelques fois par mois, qui n’ont aucune donnée personnelle à stocker, et qui n’ont jamais eu besoin d’autre chose.

Ils sont pourtant, aujourd’hui encore, construits par défaut sur des architectures conçues pour des besoins qu’ils n’ont pas — et ils en supportent tous les inconvénients : les mises à jour, le risque, le coût, et l’angoisse discrète de ne pas savoir si la dernière faille les concerne.

La question à poser à votre prestataire n’est donc pas « est-ce que mon site est sécurisé ? », à laquelle il répondra oui. C’est : « qu’est-ce qui, dans mon site, exécute du code ? » La réponse vous dira tout le reste.