Ce tutoriel explique comment intégrer CrowdSec, une solution open source de cybersécurité, avec le reverse proxy Traefik pour détecter et bloquer les attaques web. Il détaille les étapes pour configurer Traefik afin de générer des logs d'accès, installer CrowdSec via Docker, et intégrer le bouncer CrowdSec à Traefik. Le guide aborde également la protection de l'hôte Docker et l'utilisation du module AppSec de CrowdSec comme WAF. Une ressource utile pour renforcer la sécurité des applications web.

Il s'agit du site référençant toutes les fuites de données connues... ça fait peur :

Ce guide pratique de l'OWASP Top 10, destiné aux développeurs web, détaille dix erreurs courantes et comment les éviter. Il aborde des sujets comme le contrôle d'accès brisé (A01), les échecs cryptographiques (A02), et les injections (A03), avec des exemples concrets et des solutions pour les prévenir dès l'écriture du code. Un outil précieux pour améliorer la sécurité des applications web.

Ce billet de blog explique comment sécuriser une fonctionnalité d'import de fichiers en corrigeant les failles SSRF (Server Side Request Forgery) et XXE (XML External Entity). L'auteur décrit comment une vulnérabilité a été découverte dans son application Writizzy, permettant à un utilisateur malveillant d'accéder à des fichiers sensibles du serveur via des requêtes internes ou des protocoles non sécurisés. Des solutions sont proposées pour vérifier les protocoles utilisés et bloquer les accès aux URLs privées ou locales.

Le protocole ARP — souvent invisible mais absolument essentiel — joue le rôle de “traducteur” entre les adresses IP (utilisées par les protocoles réseau) et les adresses MAC (adresses physiques des interfaces réseau). Dans cet article, IT-Connect explique comment ARP fonctionne dans un réseau local : requêtes, réponses, cache ARP, et montre pourquoi sans lui aucun paquet Ethernet ne pourrait atteindre sa destination. Vous y découvrirez aussi les commandes utiles pour gérer le cache, ainsi que les risques de sécurité liés à des attaques comme l’ARP-spoofing, et les bonnes pratiques pour s’en prémunir.

Ce guide compare SSHGuard et Fail2ban pour la protection SSH sur Debian/Ubuntu. SSHGuard, écrit en C, est plus léger (1-2 Mo) et utilise un parseur lexical natif, tandis que Fail2ban, en Python, consomme plus de ressources (9 Mo à 2.5 Go) et repose sur des expressions régulières. SSHGuard est idéal pour les serveurs avec ressources limitées et une protection SSH prioritaire, tandis que Fail2ban convient pour protéger plusieurs services avec des règles personnalisées. Le guide explique aussi l'installation, la configuration de base et le système de scoring de SSHGuard.

L'article explique comment utiliser des modèles de langage locaux (LLM) pour des tests de sécurité informatique, en insistant sur l'importance d'avoir une autorisation écrite. Il décrit l'installation d'Ollama pour exécuter des LLM localement, puis l'utilisation de Cybersecurity AI (CAI), un framework open source pour des analyses offensives et défensives. L'auteur partage son expérience avec une configuration spécifique et des commandes pour sélectionner un LLM et un profil d'agent, comme le "Red Team Agent" pour des tests de pénétration.

Warpgate est un bastion open source écrit en Rust, conçu pour implémenter une approche Zero Trust en sécurisant l’accès à vos infrastructures (SSH, HTTP/HTTPS, MySQL, PostgreSQL). Contrairement à des solutions comme Teleport ou Boundary, il ne nécessite aucun agent sur les machines cibles et s’installe en quelques minutes. Ses atouts : traçabilité totale des sessions, intégration avec OpenID Connect, et simplicité de déploiement (y compris sur Kubernetes). Cependant, il présente des limites : pas de haute disponibilité native (sessions perdues en cas de crash), protocoles limités (pas de RDP/VNC/Kubernetes), et une API non documentée. Malgré ces compromis, Warpgate séduit par sa transparence, sa robustesse, et son modèle open source sans lock-in. Idéal pour les équipes cherchant une solution légère et auditable, à condition d’accepter ses contraintes.

L'article présente un outil qui vérifie la sécurité d'un paquet npm avant de l'installer : NPQ. Cet outil fonctionne avec les autres gestionnaires de paquet (via une variable d'environnement)

Il s'agit d'une alternative à Adguard ou Pi-hole, un intercepteur DNS pour bloquer les requêtes vers les domaines indésirables.

Ce guide pratique détaille 5 étapes essentielles pour sécuriser un serveur Ubuntu : création d’un utilisateur dédié avec droits sudo, configuration de l’authentification SSH par clé (et désactivation de l’accès root et des mots de passe), verrouillage du compte root, personnalisation du hostname et du message d’accueil (MOTD). Il explique aussi comment désactiver les messages système indésirables et propose des bonnes pratiques supplémentaires comme l’utilisation d’un firewall (ufw), l’installation de fail2ban, et la surveillance des logs. L’objectif est de réduire les risques d’intrusion en adoptant une configuration robuste dès l’installation. Idéal pour les administrateurs système souhaitant renforcer la sécurité de base de leur serveur.

Paris Web 2025 a marqué les esprits avec une édition placée sous le signe de l’inclusivité, de l’accessibilité, de la diversité et de l’écoconception. Organisée à l’Institut Louis Pasteur, la conférence a proposé des présentations variées, accessibles (LSF, vélotypie) et engagées, mêlant technique, retours d’expérience et réflexion sur les bonnes pratiques du web.

Parmi les temps forts, on retient notamment la conférence d’Agnès Haasser sur le HTTPS et ses enjeux de sécurité, un retour d’expérience percutant d’Anne Faubry et Chloé Corfmat sur l’accessibilité pour les personnes déficientes visuelles (au-delà du RGAA), et une démonstration convaincante des Passkeys par Daniel Garnier-Moiroux. D’autres sujets comme le design validiste, l’Unicode, les Web Components, ou encore l’impact psychosocial de l’IA ont aussi rythmé ces deux jours. L’événement a confirmé son rôle de bulle inspirante et bienveillante pour les passionné·e·s du web, avec des interventions de qualité et une approche résolument humaine et pratique.

Rodolphe Breard propose une configuration sécurisée pour OpenSSH, en insistant sur l’utilisation exclusive de l’algorithme Ed25519 pour les clés (serveur et client) et en désactivant RSA et ECDSA, jugés moins sûrs. Pour l’échange de clés, il recommande l’algorithme post-quantique hybride mlkem768x25519-sha256 (basé sur ML-KEM et X25519), disponible depuis OpenSSH 9.9, et suggère de bannir les anciennes versions ne supportant pas ces algorithmes. Côté chiffrement, seuls les algorithmes AEAD (comme chacha20-poly1305@openssh.com ou aes256-gcm@openssh.com) sont conservés, avec des MAC en mode encrypt-then-mac. L’authentification par mot de passe est désactivée, ainsi que les options comme UsePAM, AllowTcpForwarding ou X11Forwarding, tout en limitant les tentatives de connexion et en renforçant les permissions. La configuration est modulaire, avec des fichiers séparés pour les paramètres génériques et les utilisateurs autorisés. Enfin, l’outil ssh-audit est conseillé pour vérifier la robustesse de la configuration. Une approche pragmatique pour se prémunir contre les attaques, y compris celles liées à l’informatique quantique future.

Obsidian explique comment ils minimisent les risques d’attaques par la chaîne d’approvisionnement (supply chain attacks) en limitant au maximum ses dépendances externes. L’application privilégie le développement en interne (comme pour les fonctionnalités Bases et Canvas), évite les bibliothèques tierces quand c’est possible, et utilise des versions figées et vérifiées pour les dépendances inévitables (comme Electron ou CodeMirror). Les mises à jour sont rares, méticuleusement testées et espacées dans le temps, avec une revue approfondie des changements et des sous-dépendances. Cette approche réduit la surface d’attaque et permet de détecter rapidement d’éventuels problèmes avant qu’ils n’affectent les utilisateurs. Une stratégie qui combine minimalisme, contrôle strict et prudence pour garantir un environnement sécurisé et privé.

L’article présente Warpgate, un outil open source qui simplifie la gestion des accès sécurisés (SSH, PostgreSQL, MySQL, HTTP) en agissant comme un bastion moderne. Facile à déployer (binaire ou Docker), il centralise l’authentification (avec support SSO), offre une connexion transparente et un audit en temps réel des sessions. L’auteur souligne sa simplicité, sa sécurité renforcée et son interface intuitive, idéale pour remplacer les solutions complexes de machines de rebond. Un exemple de déploiement avec Docker Compose est fourni, illustrant la rapidité de mise en place. Une pépite pour les administrateurs système en quête d’efficacité et de traçabilité.

Cet article explique pourquoi l’utilisation de Math.random() pour générer des mots de passe est dangereuse (prédictibilité, absence de sécurité cryptographique) et propose une solution robuste via l’API Web Crypto et sa méthode crypto.getRandomValues(). Cette dernière utilise des sources d’entropie cryptographiquement sécurisées, évitant les biais de distribution grâce au rejection sampling.

L’article fournit un exemple d’implémentation complète, incluant :

• Une classe SecurePasswordGenerator personnalisable (longueur, types de caractères, exclusion des caractères ambigus).
• Une méthode pour calculer la force du mot de passe généré.
• Des bonnes pratiques : validation côté serveur, gestion mémoire, et compatibilité navigateur (HTTPS requis).

À retenir : Toujours privilégier crypto.getRandomValues() et éviter Math.random() pour toute application sensible. L’API est largement supportée (Chrome, Firefox, Safari) et garantit une sécurité optimale.

Ce tutoriel de ZoneTuto explique comment configurer le montage automatique d’un volume chiffré avec LUKS (Linux Unified Key Setup) au démarrage du système. Il détaille les étapes clés :

• Préparation du volume chiffré et création d’une clé de déchiffrement dédiée.
• Configuration de /etc/crypttab et /etc/fstab pour un montage automatique.
• Sécurisation de la clé et gestion des permissions.

Idéal pour ceux qui souhaitent allier sécurité et praticité sous Linux.

Lyra Rebane défend l’idée que beaucoup de sites n’ont pas besoin de JS ou de frameworks lourds pour offrir une expérience riche : modernes, HTML et CSS seuls suffisent souvent. L’article montre de nouveaux outils CSS (naming, nesting, pseudo-classes, color mixing, unités viewport dynamiques, etc.), des composants interactifs accessibles (via « \:checked », « \:has », « details/summary », etc.), et des effets visuels performants. L’auteur insiste aussi sur les bénéfices pour la performance, l’accessibilité, la vie privée, et le plaisir de coder léger, esthétique et fonctionnel.

L’article souligne l’importance d’une gestion rigoureuse des versions npm pour sécuriser ses projets JavaScript, surtout après des attaques comme celles sur chalk et debug. Il recommande d’utiliser des versions exactes pour les dépendances critiques (ex: "react": "18.2.0") plutôt que des ranges permissifs (^, ~, >=), et d’always commiter les lock files (package-lock.json ou yarn.lock) pour éviter les incohérences entre environnements. Une méthodologie sécurisée inclut : des audits réguliers (npm audit), des mises à jour contrôlées (via npm-check-updates), des tests complets après chaque modification, et l’intégration de vérifications automatiques dans le CI/CD. L’objectif est de minimiser les risques liés à la supply chain en privilégiant la sécurité à la commodité, notamment pour les packages critiques en production. Une checklist pratique résume les bonnes pratiques : versions exactes, lock files versionnés, audits automatiques, monitoring continu et backups des versions stables. La sécurité devient ainsi un investissement clé pour la stabilité des projets.

L'auteur explique qu’il n’existe pas de solution miracle pour empêcher les données sensibles (mots de passe, clés API, PII) d’apparaître dans les logs, mais une combinaison de "balles de plomb" — des mesures ciblées et complémentaires — permet de réduire significativement les risques. Il identifie d’abord les causes courantes : logs directs accidentels, objets "éviers de cuisine" (comme les erreurs HTTP contenant des configurations sensibles), changements de niveau de log, secrets intégrés dans des URLs ou des télémetries, ou encore les entrées utilisateurs imprévisibles.

Pour y remédier, il propose 10 pistes :

• Architecture des données : centraliser les flux de logs pour mieux les contrôler.
• Transformations : minimisation, rédactions, tokenisation ou masquage des données avant logging.
• Primitives de domaine : encapsuler les secrets dans des objets dédiés (ex. Secret) pour empêcher leur logging accidentel, avec des vérifications à la compilation ou à l’exécution.
• Objets à lecture unique : des wrappers qui bloquent l’accès au secret après sa première utilisation.
• Vérification de souillure (taint checking) : analyser statiquement les flux de données pour détecter les fuites vers les logs.
• Formatteurs de logs : filtrer ou redacter automatiquement les champs sensibles dans les pipelines de logging.
• Tests unitaires : faire échouer les tests si des secrets sont détectés dans les sorties.
• Scanners de données sensibles : outils comme TruffleHog pour détecter a posteriori les fuites, avec échantillonnage pour optimiser les coûts.
• Prétraitement des logs : nettoyer les flux avant stockage (ex. avec Vector).
• Sensibilisation des équipes : former les devs et leur donner les outils pour signaler et corriger les problèmes.

La stratégie globale repose sur 4 piliers :

1. Poser les bases (culture sécurité, définition des "secrets", logs structurés).
2. Cartographier les flux de données pour identifier les points critiques.
3. Protéger les goulots d’étranglement (ex. pipeline centralisé de logs) avec des contrôles en profondeur.
4. Prévoir la réponse aux incidents : isolation, nettoyage, analyse post-mortem.

En combinant ces approches — et en acceptant que le "zéro fuite" soit un idéal —, on limite efficacement les risques, tout en renforçant la résilience globale du système.