Ce tutoriel explique comment configurer Fail2ban pour sécuriser Nginx Proxy Manager (NPM) dans un environnement Docker. L'objectif est de bloquer les tentatives d'accès non autorisés, notamment les attaques par force brute sur l'authentification Basic Auth, sans modifier l'image Docker de NPM ni ajouter de conteneur supplémentaire.
La méthode préconisée repose sur l'analyse des logs d'accès de NPM, qui enregistrent les échecs d'authentification HTTP 401. Fail2ban, exécuté sur l'hôte Docker, surveille ces logs pour identifier les adresses IP suspectes et les bannir temporairement des ports 80 et 443. L'approche vise à rester simple (KISS) en utilisant les journaux natifs de NPM et en s'appuyant sur la configuration existante de Fail2ban sur l'hôte.
La procédure implique de localiser le fichier journal d'accès pertinent pour le Proxy Host ciblé, de créer un filtre Fail2ban spécifique pour reconnaître les échecs d'authentification 401 et d'inclure l'adresse IP du client (
Après plusieurs fuites de données touchant des services de l’État en 2026 (DGFiP, France Titres, Éducation nationale), il est recommandé de vérifier si son identité a déjà été utilisée frauduleusement : consulter l’historique de ses connexions FranceConnect, demander la liste des comptes bancaires ouverts à son nom via FICOBA, vérifier auprès de la Banque de France une éventuelle inscription aux fichiers FCC/FICP et rechercher les sociétés dont on apparaîtrait comme dirigeant via MonIdenum ou l’Annuaire des entreprises. En cas d’anomalie, il faut contacter l’organisme concerné et déposer plainte ; en prévention, l’article recommande notamment l’authentification multifacteur, des mots de passe uniques et l’utilisation de documents d’identité filigranés ou de justificatifs à usage unique via France Identité.
L’article explique comment fail2ban peut renforcer la sécurité d’un serveur web Apache en filtrant automatiquement les adresses IP suspectes. L’auteur, Da Scritch, détaille son utilisation pour bloquer les tentatives de brute-force et autres comportements abusifs, réduisant ainsi les risques d’exploitation tout en limitant l’impact sur les performances. Le logiciel s’appuie sur des expressions régulières pour analyser les logs et appliquer des règles de blocage via iptables ou nftables, sans perturber le fonctionnement des services surveillés.
L’auteur souligne que fail2ban est une solution légère, consommant peu de ressources (environ 30 Mo de RAM et moins de 6 % de CPU), tout en étant efficace contre les scans automatisés. Il précise que son serveur, hébergé par un FAI associatif, subit en moyenne 80 requêtes malveillantes par seconde, illustrant l’utilité de l’outil pour atténuer ces attaques répétées.
Enfin, Da Scritch insiste sur l’importance de sécuriser un serveur, même pour un usage personnel, afin de ne pas impacter d’autres utilisateurs du réseau. Il présente fail2ban comme une solution simple et peu intrusive, idéale pour compléter d’autres mesures de protection sans nécessiter de refonte majeure de l’infrastructure.
L’article explique comment la sécurité au niveau des lignes (RLS) dans PostgreSQL peut être contournée dans un projet Symfony en raison du rôle propriétaire des tables. Bien que les politiques RLS soient activées, le rôle qui exécute les migrations (et donc possède les tables) ignore ces restrictions par défaut, exposant toutes les données sans restriction. Un simple ALTER TABLE ... FORCE ROW LEVEL SECURITY est nécessaire pour appliquer correctement les politiques.
L’auteur souligne que cette faille est difficile à détecter en tests, car les connexions de test utilisent souvent un superutilisateur qui contourne aussi la RLS. La configuration par défaut de Symfony, où le même rôle gère à la fois les migrations et l’application, crée un risque de fuite de données. La documentation PostgreSQL mentionne ce comportement, mais il est souvent ignoré lors de la mise en place des politiques.
L’article analyse les hacks récents ayant ciblé des services publics français en 2026, soulignant que trois des quatre attaques ont exploité des comptes légitimes sans nécessiter de compétences techniques avancées. Il met en avant l’importance de la défense en profondeur : pare-feu, cloisonnement, double authentification et contrôle strict des droits d’accès, tout en rappelant que la minimisation des données (RGPD) limite les risques de fuite. L’exemple de la DGFIP illustre un retard de six semaines dans la détection de l’exfiltration de données, malgré une coupure immédiate des accès, soulignant l’importance de surveiller à la fois l’intrusion et la sortie des informations.
Les attaques se divisent en deux catégories : les cibles spécifiques (phishing, mots de passe volés, comptes obsolètes) et les scans automatisés exploitant des failles connues dans des logiciels populaires. L’article cite l’exemple d’une faille de conception (IDOR) sur le portail ANTS, où une simple modification d’URL permettait d’accéder à des dossiers non sécurisés. Les robots malveillants, eux, ciblent indistinctement les serveurs vulnérables, souvent en quelques secondes après l’enregistrement d’un nom de domaine.
Enfin, l’auteur insiste sur la nécessité d’une approche globale, combinant prévention (mises à jour, configuration par défaut restrictive) et détection rapide des intrusions ou fuites. Il rappelle que le RGPD impose une notification rapide des victimes, mais que certains organismes peinent à identifier une exfiltration de données, retardant ainsi les mesures correctives.
Cet article explique comment distinguer une revendication de fuite de données d’une fuite confirmée, en soulignant que les annonces non vérifiées sont souvent exagérées pour des raisons économiques. Il détaille les méthodes de vérification à appliquer avant de reprendre un chiffre, comme croiser les sources ou analyser les échantillons fournis, et met en garde contre la confusion entre une ligne de base de données et une personne réelle.
L’auteur illustre son propos avec des exemples récents de revendications non confirmées (Intermarché, Bureau Vallée, DGFiP) et souligne que seule une minorité de cas aboutissent à une confirmation officielle, parfois avec des écarts significatifs entre les chiffres annoncés et la réalité. Il insiste sur l’importance de ne pas relayer sans filtre ces affirmations, qui servent souvent de levier de communication pour leurs auteurs.
Enfin, l’article propose des critères pour évaluer la crédibilité d’une revendication et rappelle les actions attendues d’une organisation concernée, tout en clarifiant la signification du silence d’une entreprise dans ce contexte.
La page d'Alsacreations explique la vulnérabilité CSRF (Cross-Site Request Forgery), classée parmi les risques critiques par l'OWASP. Elle repose sur l'envoi automatique des cookies par le navigateur, permettant à un site tiers d'effectuer des actions au nom d'un utilisateur connecté sans son consentement. Par exemple, un lien malveillant ou un formulaire caché peut déclencher une requête vers un service bancaire, exploitant la session active de la victime.
Contrairement à une idée reçue, l'utilisation de requêtes POST ne suffit pas à se prémunir contre les CSRF, car un formulaire peut être soumis automatiquement via JavaScript. La méthode POST améliore la sécurité, mais une protection supplémentaire est nécessaire. La solution la plus efficace consiste à intégrer un token CSRF, une valeur aléatoire unique générée par le serveur et vérifiée à chaque soumission de formulaire, empêchant ainsi les requêtes non autorisées.
Ce billet de blog d’Evil Martians explique comment sécuriser la publication d’un package npm en 2026, face à la menace croissante des attaques par chaîne d’approvisionnement. L’auteur souligne l’importance de mesures comme les Trusted Publishers sur npmjs.com, la désactivation des tokens de publication et l’activation de la 2FA sur GitHub pour limiter les risques de vol de credentials. Ces pratiques améliorent aussi la visibilité et la crédibilité du projet.
L’article détaille des solutions techniques concrètes, comme l’utilisation de zizmor pour auditer les workflows CI, le pinning des actions GitHub par commit SHA, et la configuration d’un délai de 3 jours avant une nouvelle publication. Ces étapes visent à réduire les vulnérabilités tout en optimisant la maintenance des projets open source.
Enfin, il recommande de migrer vers des versions récentes de npm, pnpm, Yarn ou Bun pour éviter l’exécution automatique des scripts postinstall des dépendances, renforçant ainsi la sécurité globale. Ces bonnes pratiques s’inscrivent dans une tendance où la sécurité devient un critère différenciant pour les développeurs et les entreprises.
Cisco a révélé une faille critique (CVE-2026-20316) dans son outil Secure Firewall Management Center (FMC), utilisé pour administrer des pare-feux d'entreprise. Un compte intégré avec des identifiants codés en dur dans le code permet une exploitation à distance, même sans authentification, offrant un accès limité mais exploitable pour des attaques plus poussées. La vulnérabilité, déjà exploitée avant la publication du correctif, touche plusieurs versions du logiciel et nécessite une mise à jour immédiate, car aucun contournement n’est possible.
Le FMC, central dans la gestion des politiques de sécurité, expose un risque majeur si son interface d’administration est accessible depuis Internet, ce qui semble être le cas dans certaines configurations. Cisco souligne que le correctif doit être appliqué sans délai, tout en vérifiant les journaux pour détecter d’éventuelles intrusions. La faille illustre un problème récurrent : l’intégration de secrets dans le code, un défaut persistant depuis des années dans les équipements de sécurité.
L’article souligne aussi l’importance de sécuriser les interfaces d’administration et de ne pas exposer les outils critiques en ligne. Il rappelle que ce type de faille n’est pas réservé aux firmwares : des erreurs similaires peuvent survenir dans des projets web, soulignant la nécessité de bien gérer les identifiants sensibles.
La durée de vie maximale des certificats TLS publics sera progressivement réduite à 200 jours en 2026, puis à 47 jours en 2029, rendant le renouvellement manuel intenable. Cette décision, adoptée par le CA/Browser Forum, impose un calendrier strict sans dérogation, avec une validation de domaine (DCV) réutilisable seulement 10 jours à partir de 2029. Les autorités de certification, co-sponsors de cette mesure, privilégient désormais des modèles économiques basés sur des souscriptions et des plateformes de gestion automatisée.
Le renouvellement manuel, autrefois annuel, devient ingérable avec des échéances semestrielles dès 2026, trimestrielles en 2027, puis toutes les six semaines en 2029. Les infrastructures automatisées, comme ACM sur AWS ou ACME, deviennent indispensables pour éviter les interruptions de service. Un exemple concret illustre cette contrainte : un certificat wildcard hérité, géré manuellement, a nécessité une intervention urgente en raison de sa durée de vie désormais limitée.
Cette transition, motivée par des impératifs de sécurité (réduction des fenêtres d’exploitation des clés compromises), s’aligne aussi avec les intérêts commerciaux des autorités de certification. Leur modèle évolue vers des abonnements et des solutions de gestion centralisée, rendant les processus manuels obsolètes et coûteux.
L’auteur explique avoir migré son blog de WordPress vers EmDash après 12 ans d’utilisation, citant des raisons de maintenance et de sécurité. EmDash, un CMS inspiré de WordPress mais plus léger, permet d’importer facilement le contenu existant, y compris les images, tout en offrant une interface d’administration similaire.
Le nouveau système repose sur Cloudflare Workers, une plateforme serverless qui limite les risques de sécurité grâce à un runtime restreint. L’auteur souligne les avantages de cette solution, comme l’utilisation de services intégrés (D1, R2, KV) et une consommation de ressources optimisée, idéale pour un site à faible trafic.
EmDash adopte une approche plus sécurisée que WordPress en limitant les capacités des plugins, qui s’exécutent dans des environnements isolés. L’auteur souligne que la plupart des fonctionnalités nécessaires sont déjà intégrées ou facilement développables, réduisant ainsi le besoin de dépendre de modules externes.
L’article explique comment sécuriser les secrets Kubernetes en utilisant OVHcloud Secret Manager (un service managé compatible HashiCorp Vault KV v2) couplé à External Secrets Operator (ESO), une solution automatisée pour synchroniser les secrets entre le gestionnaire externe et le cluster. L’auteur souligne les avantages de cette approche, notamment la simplicité de déploiement et la réduction des coûts (environ 0,03 € par secret/mois), tout en évitant les pratiques risquées comme le stockage direct dans Git ou les Secrets Kubernetes non protégés.
Le tutoriel détaille les étapes techniques : installation de la CLI OVHcloud, configuration d’un compte de service IAM avec des droits minimaux, puis déploiement d’ESO via Helm. L’opérateur permet de synchroniser automatiquement les secrets depuis OVHcloud Secret Manager vers Kubernetes, avec un chiffrement au repos et une gestion centralisée des accès via des tokens IAM. L’auteur compare cette solution à des alternatives comme OpenBao, jugées plus complexes à maintenir pour des clusters légers.
Enfin, l’article aborde la question budgétaire, précisant que le coût reste très faible pour un usage modéré, et propose une méthode pour regrouper plusieurs valeurs sous un même secret afin d’optimiser la facturation. La démarche est présentée comme une alternative efficace aux solutions auto-hébergées, idéale pour les environnements éphémères ou les équipes cherchant à simplifier leur gestion des secrets.
Le Cyber Resilience Act (CRA) européen impose de nouvelles obligations de signalement à partir du 11 septembre 2026, notamment l’article 14, qui exige de notifier les vulnérabilités exploitées ou incidents graves sous 24h à 14 jours selon les cas. Contrairement à une idée reçue, cette date ne déclenche pas l’ensemble du règlement, qui s’appliquera pleinement en décembre 2027. Les signalements doivent être transmis via une plateforme unique (Single Reporting Platform) vers les autorités compétentes (CSIRT et ENISA).
La notion d’activité commerciale est déterminante pour savoir si un développeur est concerné. Un logiciel open source non monétisé par ses auteurs échappe aux obligations, même s’il est hébergé publiquement ou soutenu par des entreprises. En revanche, toute intention de profit, comme des dons excédant les coûts ou des services payants de support, peut basculer un projet dans le champ du CRA. Le texte distingue clairement la publication de la vente.
Trois profils se dégagent : le fabricant (celui qui met le logiciel sur le marché), le steward (mainteneur influent, souvent une organisation) et le passant (utilisateur ou contributeur occasionnel). Les obligations pèsent surtout sur les deux premiers, tandis que les simples contributeurs ou utilisateurs sont généralement exemptés, sauf si leur activité relève d’une commercialisation indirecte.
Ce billet explique comment sécuriser un back-office EasyAdmin sans utiliser setPermission(), en s'appuyant sur trois couches de sécurité natives à Symfony. L'approche combine access_control par host, l'attribut #[IsGranted] au niveau des contrôleurs et des gardes personnalisées dans les actions sensibles, offrant une sécurité robuste et indépendante d'EasyAdmin.
La première couche repose sur access_control dans la configuration Symfony, restreignant l'accès à l'admin via un sous-domaine dédié (ex: admin.lecodeestdanslepre.fr) avec le rôle ROLE_ADMIN. Cette méthode agit comme un premier filet de sécurité avant même l'arrivée de la requête au contrôleur. La deuxième couche utilise #[IsGranted('ROLE_ADMIN')] sur chaque contrôleur pour doubler la vérification côté Symfony, garantissant que seules les actions autorisées sont exécutées.
Enfin, une troisième couche de sécurité est implémentée directement dans les actions métier pour des contrôles plus fins, comme la validation CSRF ou la vérification de l'état d'une entité. Ces trois niveaux de sécurité, tous issus de Symfony, assurent une protection complète tout en restant modulaires et adaptables à d'autres solutions que EasyAdmin.
Cette page explique le processus de correction des vulnérabilités de sécurité dans Symfony UX, depuis la détection jusqu’à la publication. L’auteur, membre de l’équipe Symfony UX Core Team, détaille les étapes clés : développement des correctifs dans un dépôt privé pour éviter les exploits anticipés, triage des rapports pour distinguer les vulnérabilités critiques (CVE) des améliorations de sécurité mineures, et création de correctifs ciblant d’abord les branches maintenues en mode security-fixes-only.
Deux exemples concrets illustrent ce processus : CVE-2026-55877, une faille XSS dans symfony/ux-icons due à l’injection de SVG non échappés, corrigée via une usine centralisée de nettoyage des éléments dangereux ; et CVE-2026-55878, une traversée de chemin dans symfony/ux-toolkit permettant l’accès à des fichiers arbitraires, résolue par un rejet explicite des chemins contenant ...
L’auteur souligne l’utilisation d’outils automatisés (comme un assistant IA pour analyser les rapports ou générer des advisories GitHub) pour accélérer les tâches répétitives, tout en insistant sur la nécessité d’un examen humain pour valider les correctifs et les scores CVSS avant publication.
Ce mémo complet explique SELinux, un module de sécurité intégré au noyau Linux qui applique un contrôle d'accès obligatoire (MAC), plus strict que les permissions Unix classiques. Contrairement à AppArmor, souvent utilisé sur Debian/Ubuntu, SELinux est activé par défaut sur les distributions comme Red Hat, Fedora ou leurs dérivées. Son objectif principal est de limiter les actions des processus, même en tant que root, renforçant ainsi la protection contre les exploits et les compromissions.
L’article détaille les concepts clés comme les contextes de sécurité, les politiques SELinux et les booléens, essentiels pour configurer et diagnostiquer le système. Il aborde aussi des cas pratiques (Apache, SSH, Samba) et propose des outils comme audit2why ou audit2allow pour analyser et résoudre les blocages, ainsi que des commandes utiles pour gérer les modes Enforcing et Permissive.
shadcn/improve est un outil conçu pour optimiser l'audit d'un codebase en utilisant un modèle performant pour analyser le code et générer des plans d'action, puis en confiant l'exécution à des modèles moins coûteux. L'idée centrale est de séparer l'intelligence (spécification et priorisation) de l'exécution, afin de réduire les coûts tout en maintenant une qualité élevée.
L'outil propose plusieurs commandes pour adapter l'audit, comme une analyse rapide, exhaustive ou ciblée (sécurité, performances, etc.), et génère des plans détaillés en Markdown dans un dossier dédié. Ces plans peuvent être exécutés par d'autres agents ou revus manuellement avant validation.
Un exemple concret montre comment l'outil identifie des problèmes comme une duplication de configuration ou des inefficacités algorithmiques, puis produit des spécifications claires pour les corriger, tout en permettant de rejeter des faux positifs pour éviter leur retour lors des prochains audits.
Bagel est un outil en ligne de commande (CLI) open source développé par BoostSecurity, conçu pour inventorier les métadonnées pertinentes pour la sécurité sur les postes de travail des développeurs. Il analyse les configurations et outils (Git, SSH, npm, environnements cloud, etc.) ainsi que les emplacements potentiels de secrets, sans jamais exfiltrer les valeurs sensibles, se limitant aux métadonnées comme les chemins, permissions ou types de clés.
L’outil propose neuf sondes pour détecter des configurations risquées (comme des clés SSH sans phrase de passe ou des registres npm non sécurisés) et huit détecteurs de secrets, uniquement pour signaler leur présence sans les exposer. Les rapports, générés en JSON, sont locaux et respectueux de la vie privée, évitant toute opération intrusive ou injection de processus.
Bagel permet aux équipes de sécurité d’identifier des vulnérabilités dans la chaîne d’approvisionnement (mauvaise hygiène des clés, fuites de credentials) et d’appliquer des contrôles de posture via des flags comme --strict. Des binaires précompilés sont disponibles pour macOS, Linux et Windows.
Ce billet propose une méthode pour détecter et supprimer les secrets exposés sur les postes de travail des développeurs avant qu’ils ne soient exploités par des acteurs malveillants. L’auteur souligne que les gestionnaires de paquets (PyPI, npm, brew, etc.) et les outils comme VS Code élargissent la surface d’attaque, rendant les postes vulnérables aux vols de données d’identification. La plupart des entreprises se contentent de solutions passives, comme espérer que leurs outils de sécurité endpoint bloquent les menaces.
Pour améliorer cette situation, l’auteur recommande une combinaison d’outils open-source : Bagel, un scanner de secrets configuré pour repérer les clés SSH, les identifiants GitHub ou cloud, et Fleet, une plateforme de gestion et de télémétrie basée sur osquery. Ensemble, ils permettent de surveiller les postes en continu, d’évaluer la conformité via des politiques personnalisables et d’automatiser les notifications ou blocages (via Slack ou des fournisseurs d’identité) en cas de faille critique. L’intégration repose sur des scripts macOS (Fleebag) pour déployer Bagel et centraliser les résultats dans Fleet.
L’approche vise à remplacer les vérifications manuelles par un processus automatisé et scalable, adapté même aux petites structures. Les outils, écrits en Go et conçus pour une intégration fluide, offrent une alternative légère aux solutions commerciales, tout en s’appuyant sur des standards comme JSON pour l’interopérabilité.
Ce dépôt GitHub propose une implémentation de référence pour la détection et la correction autonome de vulnérabilités dans le code, basée sur les modèles Claude d'Anthropic. L'outil, non maintenu et sans contributions acceptées, permet de créer un pipeline personnalisable pour l'analyse de sécurité, incluant la modélisation des menaces, le scan, le triage et le patching. Il s'appuie sur des compétences interactives comme /threat-model ou /patch, ainsi qu'un harnais autonome pour automatiser le processus de recon → find → triage → report → patch.
Le système est conçu pour être sécurisé, avec des exécutions en bac à sable (gVisor) pour les opérations risquées, et des vérifications manuelles requises pour les modifications de code. Bien que fonctionnel pour des cas d'usage spécifiques (comme les vulnérabilités mémoire en C/C++), il nécessite une adaptation pour d'autres langages ou classes de vulnérabilités. Une documentation détaillée et des scripts d'installation sont fournis pour faciliter la configuration.
Anthropic propose en parallèle une solution managée payante, Claude Security, pour une approche plus robuste et scalable. Le dépôt sert ainsi de base technique ouverte pour expérimenter ou s'inspirer, sans garantie de support ou de compatibilité universelle.