Incidents de sécurité en cascade : prévention des intrusions et minimisation des dégâts dans les systèmes Web

Depuis le début de 2026, et particulièrement ces derniers mois, les signalements d'accès non autorisés et de fuites de données visant les systèmes web d'entreprises nationales se multiplient.
Le 8 octobre, JPCERT/CC a publié un avertissement concernant les accès non autorisés répétés auprès d'organisations nationales, et le 9 octobre, l'IPA a également lancé un appel aux mesures d'urgence en réponse aux fuites de données dues à l'accès non autorisé.

Face à ces incidents, on tend à se concentrer sur les problèmes des anciens systèmes et des logiciels non mis à jour.
Bien sûr, ce sont des risques majeurs, mais il ne s'agit pas d'une simple affaire où la modernisation d'un système garantirait la sécurité.

Je pense qu'il est important d'appliquer rigoureusement des mesures pour prévenir les intrusions, et en cas de problème de sécurité malgré tout, d'avoir une conception de défense en profondeur capable de minimiser les dégâts.

Cette fois, en prenant pour exemples Cloudflare, Supabase et EmDash, officiellement lancé en septembre 2026, j'ai réfléchi à la sécurité web de demain.

Les accès non autorisés ne visent pas uniquement les grandes entreprises

Dans son avertissement, JPCERT/CC ne se limite pas aux attaques exploitant des vulnérabilités connues, mais mentionne aussi la recherche de fichiers de configuration et de sauvegarde, les requêtes illégales vers des API, l'abus de clés API dérobées, et la pénétration interne via des serveurs web publics comme point d'appui. Les méthodes d'attaque sont variées.

Ce qui me préoccupe particulièrement, c'est que non seulement les services pour les utilisateurs grand public, mais aussi les systèmes d'administration pour les employés et les outils BI sont devenus des cibles.
Avec l'évolution de l'IA, le concept d'autrefois selon lequel « tant que ce n'est pas indexé par Google, ça va ! » a disparu, et les systèmes publiés sur internet sont désormais constamment exposés à des explorations et attaques automatisées.

L'idée que « notre petit système ne sera pas visé ! » n'est plus valable.

La sécurité est-elle garantie par l'utilisation de technologies modernes ?

Les anciens PHP, les frameworks dont le support a pris fin et les CMS qui n'ont pas été mis à jour depuis des années présentent bien sûr des risques.
Mais est-ce vraiment sûr si nous construisons avec Next.js ou Astro et utilisons des services cloud?

Malheureusement, ce n'est pas nécessairement le cas. 😭

Des vulnérabilités sont découvertes même dans les derniers frameworks, et si le traitement d'autorisation de l'API est défectueux, il est possible que des données qui ne devraient normalement pas être accessibles soient récupérées.
Si la gestion des identifiants d'authentification ou des clés API est incorrecte, même un service cloud robuste peut entraîner des dommages. C'est pourquoi la nouveauté technologique et la sécurité du système sont deux questions distinctes.

Placer une défense devant l'application avec Cloudflare

Cloudflare est connu comme un CDN, mais joue également un rôle important dans la sécurité des applications web.
Par exemple, un WAF (Web Application Firewall) peut détecter et bloquer les requêtes suspectes, la limitation de débit peut réduire les accès massifs, et Cloudflare Access permet de limiter l'accès aux écrans d'administration interne à des utilisateurs spécifiques authentifiés.

Cela dit, c'est loin d'être parfait. 😭
Le risque réside avant tout dans le fait de laisser un écran d'administration qui n'a pas besoin d'être public accessible à tout le monde.

Un WAF ne peut pas prévenir toutes les attaques, et des mesures supplémentaires sont nécessaires pour les abus de requêtes de format normal et les défauts d'autorisation spécifiques à l'application.
Cloudflare est un mécanisme qui place une défense devant l'application, et ne garantit pas la sécurité de l'application elle-même.

Contrôler également l'accès du côté de la base de données avec Supabase

Ce que nous voulons considérer ici, c'est la RLS (Row Level Security) disponible avec Supabase.
La RLS est une fonctionnalité de PostgreSQL qui permet de contrôler la portée de l'accès au niveau des lignes de la base de données. Par exemple, dans un système d'entreprise utilisé par plusieurs entreprises, vous pouvez définir une règle côté base de données selon laquelle les utilisateurs de l'entreprise A ne peuvent consulter que les données de l'entreprise A.
Même en cas d'erreur dans le traitement d'autorisation côté application, une RLS correctement configurée fonctionne comme une défense supplémentaire.

Mais... la RLS non plus n'est pas une panacée une fois configurée. 😭

Les clés secrètes de Supabase et les clés service_role traditionnelles possèdent des permissions élevées qui peuvent contourner RLS selon leur mode d'utilisation. Une mauvaise gestion de ces clés signifie que la protection par RLS ne fonctionnera pas.
La configuration des permissions de table et les tests de politique sont également essentiels.

L'essentiel est de ne pas laisser le contrôle d'accès uniquement à l'application, mais de mettre en place un contrôle indépendant au niveau de la base de données.

Le modèle de sécurité d'EmDash : ne pas faire confiance aux plugins dès le départ

Le 28 septembre 2026,
EmDash 1.0, un CMS développé avec le soutien de Cloudflare, a été lancé, et le registre officiel des plugins a également été publié ! Nous l'avons suivi depuis son lancement et avons déjà implémenté des sites avec, ce qui est vraiment émouvant pour nous.

Créer un blog multilingue avec EmDash : comment réduire les coûts des API de traduction même avec SSR
Migrer de microCMS vers EmDash + Cloudflare

Ce qui est intéressant avec EmDash, c'est son modèle de sécurité des plugins.
Dans les CMS traditionnels, les plugins fonctionnent parfois avec des permissions proches de celles du noyau du CMS, et les vulnérabilités des plugins peuvent affecter l'ensemble du système. En revanche, les plugins introduits via le registre officiel d'EmDash s'exécutent dans un sandbox.
Cette conception limite les fonctionnalités et ressources accessibles aux plugins et rend explicites les permissions nécessaires, ce qui réduit la surface d'impact.

Bien sûr, EmDash dispose aussi de plugins natifs qui ne utilisent pas le sandbox, et cela ne signifie pas que tous les plugins sont sûrs. De plus, EmDash est un CMS relativement nouveau, et il est nécessaire d'observer son historique opérationnel futur et sa réactivité en matière de sécurité.

Néanmoins, la philosophie de conception qui consiste à ne pas faire confiance aux plugins dès le départ est un point remarquable à considérer lorsqu'on réfléchit aux CMS de demain.

Le point commun : une approche de « zéro confiance »

Cloudflare, Supabase et EmDash sont des services avec des rôles différents, mais du point de vue de la sécurité, une approche commune émerge.

• Cloudflare : contrôler les accès suspects avant qu'ils n'atteignent l'application
• Supabase : contrôler les permissions au niveau de la base de données, indépendamment des accès depuis l'application
• EmDash : isoler l'environnement d'exécution en accordant aux plugins uniquement les permissions nécessaires

Dans tous ces cas, l'idée est de ne pas confier la sécurité à un seul mécanisme, mais de limiter la portée de ce qu'on peut considérer comme fiable. N'est-ce pas une approche qui rejoint les principes de zéro confiance et du privilege minimum ?

• Même si l'authentification est compromise, toutes les opérations ne sont pas autorisées.
• Même si l'API présente des failles, toutes les données ne peuvent pas être récupérées.
• Même si un plugin contient une vulnérabilité, l'ensemble du système ne peut pas être compromis.

En établissant ces frontières, on réduit le risque qu'un problème isolé entraîne des dégâts sur l'ensemble du système.

Conclusion : prévenir les intrusions et minimiser les dégâts en cas de sinistre

On passe à React ! On migre vers Next.js ! On adopte le cloud !
Ces mises à jour technologiques ont du sens, certes (bien qu'elles semblent appartenir à une époque révolue), mais remplacer simplement un framework ou une infrastructure ne suffit pas pour une véritable modernisation. Ce qui importe vraiment, c'est d'organiser les responsabilités et les permissions entre l'authentification, l'autorisation, l'API, la base de données et les services externes, et de construire une architecture où un seul compromis ne peut pas se propager facilement d'un domaine à l'autre.

Il n'existe pas de sécurité absolue.
C'est pourquoi il est nécessaire de mettre en place des mesures pour prévenir les intrusions et de concevoir une défense multicouche capable de limiter les dégâts en cas de problème.

Cloudflare, Supabase et EmDash ne sont pas des solutions universelles, mais ces technologies intègrent des mécanismes permettant d'accorder uniquement les permissions nécessaires et d'établir des limites selon les rôles.

Chez Liberogic, lors de la construction de systèmes Web, nous accordons une importance particulière non seulement à l'adoption de nouvelles technologies, mais aussi à la séparation des responsabilités et à la défense multicouche.

À l'heure où les incidents de sécurité se multiplient, lors de la modernisation d'un système Web, il convient de porter attention non seulement à « quelles technologies utiliser », mais aussi à « jusqu'où s'étend la confiance dans l'architecture ».