En bref : un site statique se compose de fichiers HTML, CSS et d'images finis que le serveur web ne fait que diffuser. Comme ni PHP ni base de données ne tournent sur le serveur, des failles comme PHP2Shell, l'injection SQL ou des webshells introduits disparaissent en grande partie comme risque. Pour la sécurité d'un site statique, d'autres choses comptent en revanche : des accès protégés à l'hébergement, au domaine et aux outils de build, des dépendances entretenues et des services tiers soigneusement choisis. Il convient surtout aux sites rarement modifiés et sans comptes clients.
Pourquoi la question se pose en ce moment
PHP2Shell a montré à de nombreuses entreprises combien de choses dépendent d'un seul composant. Un site d'entreprise de dix pages, mis à jour une fois par trimestre, tournait sur le même PHP qu'une grande boutique en ligne et était ainsi exposé à la même faille critique. Selon des articles de presse, même des autorités et des communes ont mis des sites hors ligne par précaution.
La question vient naturellement : avons-nous seulement besoin de PHP sur le serveur pour notre site ? Pour de nombreuses petites et moyennes entreprises, la réponse honnête est : pour la diffusion, souvent non. PHP génère la page à chaque appel, alors que le contenu n'a pas changé depuis des semaines. Le fonctionnement technique est décrit dans Comment PHP génère une page web. Ce que signifie la faille elle-même est expliqué dans Qu'est-ce que PHP2Shell ?.
Comment fonctionne un site statique
Avec un site statique, la page n'est pas générée lors de la visite, mais avant. Un générateur de pages statiques, par exemple Hugo, Jekyll ou Eleventy, prend textes, images et modèles et en construit des fichiers finis. Ces fichiers sont chargés sur un simple serveur web ou un réseau de diffusion de contenu (CDN), un réseau de diffusion distribué.
Pour les rédacteurs, un outil d'édition peut se placer en amont, qui reçoit les modifications et déclenche la reconstruction. On utilise parfois pour cela un CMS dit headless, qui ne gère que les contenus et n'a pas besoin d'être accessible publiquement. Le visiteur n'en voit rien ; il ne reçoit que les fichiers finis.
Site statique et sécurité : la comparaison
| Critère | CMS PHP dynamique | Site statique |
|---|---|---|
| Logique de programme sur le serveur public | Oui, à chaque appel | Non |
| Risque dû aux failles de l'interpréteur PHP | Oui, comme avec PHP2Shell | Disparaît sur le serveur de diffusion |
| Base de données connectée publiquement | Oui | Non |
| Portes d'entrée typiques | Extensions, connexion admin, téléversements, serveur | Accès à l'hébergement, au domaine, au système de build, services tiers |
| Formulaires, recherche, compte client | Intégrés | Uniquement via des services externes ou des fonctions séparées |
| Effort d'entretien pour les rédacteurs | Faible, interface habituelle | Dépend de l'outil de rédaction |
| Maintenance | Mises à jour régulières du CMS, des extensions et de PHP | Mises à jour des outils de build et des dépendances |
| Adéquation | Boutiques, portails, nombreux rédacteurs, modifications fréquentes | Sites d'entreprise, pages d'atterrissage, documentation |
Le tableau montre : la surface d'attaque se déplace, elle ne disparaît pas. Au lieu d'un serveur PHP accessible publiquement, vous devez protéger le compte chez l'hébergeur, le domaine, le pipeline de build et le cas échéant l'outil de rédaction.
Quels risques demeurent avec les sites statiques
Premièrement, les accès. Celui qui prend le contrôle du compte d'hébergement, de l'accès au domaine ou du dépôt de code peut modifier le site, sans aucun PHP. L'authentification à deux facteurs et les comptes personnels sont donc obligatoires.
Deuxièmement, les dépendances. Les générateurs et les modèles apportent souvent de nombreux paquets, par exemple de npm. Ceux-ci doivent être tenus à jour, car une dépendance compromise peut écrire du code malveillant dans les fichiers finis lors du build. La manière de l'organiser est décrite dans Garder les dépendances à jour.
Troisièmement, les services tiers. Les services de formulaires, les fonctions de recherche, les outils d'analyse et les scripts intégrés s'exécutent dans le navigateur des visiteurs ou sur des serveurs étrangers. Chacun de ces services est une relation de confiance, y compris du point de vue de la protection des données.
Quatrièmement, le côté navigateur. Même une page statique devrait définir des en-têtes de sécurité, par exemple une Content-Security-Policy qui fixe quels scripts peuvent être chargés. Les bases figurent dans En-têtes de sécurité pour les sites web.
Avant de passer, vérifiez quelles fonctions votre site utilise réellement. Ce sont souvent moins que prévu : des pages, des images, un formulaire de contact. Le chemin vers le site statique est alors plus court qu'il n'y paraît d'abord.
Pour qui le passage vaut la peine, et pour qui non
Un site statique convient bien aux pages d'entreprise d'ampleur modeste, aux pages d'atterrissage de campagnes, aux documentations de produits et aux pages carrières. Le passage vaut surtout la peine si le site actuel tourne sur une ancienne version de PHP et qu'une mise à niveau s'imposait de toute façon.
Il convient moins aux boutiques en ligne, aux portails clients, aux systèmes de réservation et aux sites avec de nombreux rédacteurs qui publient chaque jour. Un système dynamique reste alors judicieux. Une forme mixte peut aider : la boutique reste dynamique et bien durcie, les guides et les pages d'entreprise sont diffusés en statique.
Un avantage souvent sous-estimé apparaît en situation de crise. Comme les fichiers finis peuvent être reconstruits à tout moment à partir de modèles et de contenus, un site manipulé peut rapidement être ramené à un état connu et propre. La condition est que contenus et modèles se trouvent dans un dépôt protégé, que les modifications soient journalisées de façon traçable et que personne ne modifie directement les fichiers sur le serveur.
Vous n'avez pas forcément besoin d'un prestataire de sécurité pour le passage ; une agence ou un développeur peut s'en charger. Si le site actuel a été compromis, les contenus devraient toutefois être vérifiés avant d'être repris. Changer de CMS après le piratage ? y revient.
Comment PHP SOS aide-t-il concrètement ?
- Nous vérifions quelles fonctions votre site nécessite réellement et disons ouvertement si une solution statique convient.
- Lors d'un passage, nous sécurisons les accès à l'hébergement, au domaine et au système de build avec l'authentification à deux facteurs et des comptes personnels.
- Nous examinons les services tiers et définissons des en-têtes de sécurité, pour que le nouveau site soit aussi bien protégé dans le navigateur.
- Pour les systèmes PHP qui restent, nous assurons mises à jour et surveillance dans le contrat de maintenance de sécurité.
Conclusion
Un site statique n'est pas un remède universel, mais pour de nombreux sites d'entreprise, c'est la façon la plus simple de se débarrasser d'une classe entière de risques. Là où PHP ne tourne pas, PHP2Shell ne peut rien. La sécurité gagnée ne tient toutefois que si les accès, les dépendances et les services tiers sont pris aussi au sérieux que l'était auparavant le serveur.
Questions fréquentes
Peut-on quand même pirater un site statique ?
Oui. La logique de programme côté serveur disparaît, et avec elle une grande classe d'attaques. Mais les accès à l'hébergement, au domaine et au système de build, les services tiers intégrés et les outils qui génèrent le site restent attaquables.
Un site statique peut-il avoir des formulaires de contact ?
Oui, via un service de formulaires externe ou une petite fonction exploitée séparément. Le traitement des données relève alors de ce service. Clarifiez la protection des données et la sous-traitance avant de l'intégrer.
Les rédacteurs peuvent-ils gérer eux-mêmes un site statique ?
Oui, avec un outil de rédaction adapté. De nombreuses solutions proposent une interface d'édition à partir de laquelle le site est ensuite régénéré. Pour les équipes qui modifient chaque jour de nombreux contenus, un CMS classique est toutefois souvent plus pratique.
Le passage vaut-il la peine pour une boutique en ligne ?
Le plus souvent pas entièrement. Panier, compte client et paiement exigent une logique côté serveur. Il est possible de diffuser en statique des parties comme les guides ou les pages d'entreprise et d'exploiter la boutique séparément.