Pourquoi un site statique est plus sûr qu'un site WordPress

La sécurité est rarement la première question pour un nouveau site web, jusqu’à ce que quelque chose tourne mal. Un site piraté vous coûte de la confiance, de la visibilité et souvent un nettoyage coûteux. Pour les sites axés sur le contenu, il existe une différence structurelle entre une approche WordPress et un site Astro statique ou rendu à la périphérie. Tout tourne autour de la surface d’attaque : le nombre d’endroits différents par lesquels quelqu’un peut entrer.

Où se trouvent réellement les risques ?

Le cœur de WordPress lui-même est relativement bien protégé. Le problème se situe dans l’écosystème qui l’entoure. Selon le rapport State of WordPress Security de Patchstack, 7 966 nouvelles vulnérabilités ont été trouvées dans l’écosystème WordPress en 2024. La répartition est parlante : 7 633 (96 %) se trouvaient dans des plugins tiers, 326 dans des thèmes et seulement 7 dans WordPress lui-même (via SecurityWeek). Le danger ne vient donc pas de WordPress, mais de ce que vous installez par-dessus.

C’est logique : chaque plugin est du code écrit par quelqu’un d’autre, avec sa propre qualité et son propre rythme de mise à jour. Un site WordPress moyen fait vite tourner dix à vingt plugins. Chacun d’eux est une porte d’entrée potentielle, et chacun d’eux doit rester entretenu.

Pourquoi les plugins sont-ils un point faible ?

Les plugins sont précisément ce qui rend WordPress si populaire, et en même temps son talon d’Achille. Quelques problèmes récurrents :

• Plugins abandonnés. Un développeur arrête la maintenance, mais le plugin continue de tourner sur des milliers de sites, vulnérabilités comprises.
• Mises à jour lentes. Une faille est corrigée, mais beaucoup de sites ne se mettent à jour que des semaines plus tard, ou jamais.
• Droits trop larges. Un plugin reçoit souvent plus d’accès que nécessaire, donc une faille dans un petit composant peut toucher tout le site.
• Accumulation. Plus il y a de plugins, plus la probabilité qu’au moins un soit vulnérable à un moment donné augmente.

Moins de pièces mobiles

Un site Astro statique se compose de HTML, de CSS et d’un peu de JavaScript prégénérés pour les îlots interactifs. Il n’y a pas de base de données publique, pas de connexion admin sur cette base de données, et pas de couche de plugins qui exécute du code à chaque visite.

Moins de pièces mobiles, c’est moins de choses qui peuvent casser ou être détournées. La différence de surface d’attaque est réelle :

	Site Astro statique	Site WordPress typique
Base de données publique	Aucune	Oui
Connexion admin sur le site	Aucune (ou sécurisée à part)	Oui, accessible publiquement
Plugins tiers	Aucune couche obligatoire	Souvent 10 à 20+
Code exécuté à chaque visite	Minimal	PHP et plugins
Cycles de correctifs obligatoires	Dépendances, limité	Cœur, thèmes et tous les plugins

Ce qu’un site statique n’élimine pas

Rester honnête fait partie du jeu. Une approche statique réduit le risque, mais ne résout pas tout. Ces points restent votre responsabilité :

• L’hébergement et le DNS doivent être configurés et sécurisés correctement.
• Les scripts externes (analytics, embeds, widgets de chat) apportent leur propre risque.
• Vos dépendances peuvent contenir des vulnérabilités ; gardez-les à jour.
• Les formulaires et les endpoints doivent avoir une validation et une protection contre les abus.

L’avantage, c’est que vous n’avez tout simplement pas la catégorie la plus importante et la plus courante d’incidents WordPress : les plugins vulnérables. L’OWASP Top 10 reste une checklist utile pour ce qui subsiste.

Et si vous avez quand même besoin de dynamique ?

Un site est rarement entièrement statique. Un formulaire de contact, une fonction de recherche ou une touche personnelle en font souvent partie. L’approche diffère de celle d’une couche CMS toujours active :

• Les formulaires se traitent via un endpoint côté serveur (par exemple Astro Actions) avec validation, limitation de débit et un honeypot contre les bots.
• Les parties personnelles ou en direct se rendent via des server islands, séparément du contenu principal statique.
• Les secrets comme les clés d’API restent côté serveur, jamais dans le navigateur.

Ainsi, vous ajoutez la dynamique de manière ciblée, aux endroits où c’est nécessaire, plutôt que de laisser tourner en permanence une couche CMS complète.

L’entretien comme sécurité

Beaucoup d’incidents de sécurité ne viennent pas d’attaques sophistiquées, mais de mises à jour reportées. Un site WordPress avec des dizaines de plugins exige la discipline de patcher chaque semaine, et cette discipline manque souvent. Un site statique réduit cette charge : moins de dépendances qui tournent en public, moins de cycles de correctifs urgents, moins de risque qu’une mise à jour oubliée laisse une faille ouverte.

Une checklist pour un site Astro sécurisé

• Gardez vos dépendances à jour et supprimez ce que vous n’utilisez pas.
• Traitez les formulaires côté serveur, avec validation et limitation de débit.
• Conservez les secrets dans l’environnement serveur, jamais dans le code client.
• Limitez et contrôlez les scripts externes tiers.
• Configurez correctement les en-têtes de sécurité (comme une Content Security Policy).
• Utilisez HTTPS et une configuration d’hébergement et de DNS correcte.

Conclusion

La sécurité n’est pas une fonction que vous activez après coup, c’est une conséquence de l’architecture. En ne faisant tourner ni base de données publique ni couche de plugins permanente, un site Astro statique ou rendu à la périphérie évite une grande partie des risques qui touchent le plus souvent les sites WordPress. Aucun site n’est invulnérable à cent pour cent, mais pour un site marketing, un blog ou un site d’entreprise, une petite surface d’attaque est un argument fort et concret. Vous en lirez plus sur ce compromis dans Astro vs WordPress.