Failles courantes, bonnes pratiques et conséquences réelles d'une application mal protégée, expliquées sans jargon.
Dire qu'on fait attention à la sécurité ne coûte rien et ne se vérifie pas. Cet article montre comment CodeQL transforme cette intention en artefact opposable : ce que l'analyse de flux repère quand une relecture passe à côté, trois alertes du catalogue officiel en JavaScript, en C# sur .NET 8 et dans un workflow GitHub Actions, le coût réel sur dépôt privé et les angles morts de l'outil.
Deux modèles d'authentification, deux endroits où vit l'état de connexion. Cet article compare le JWT et la session serveur sur les points qui coincent en production : la révocation immédiate, le rôle exact des refresh tokens, les situations où le JWT complique le travail, et l'endroit où ranger le token côté navigateur selon l'OWASP et la RFC 10017.
Trois failles, une application de démonstration en Flask, et les commandes exactes qui les déclenchent. Pour chacune : le code fautif, la sortie réelle de l'attaque, le correctif, et la contre-vérification qui prouve que la porte est refermée. La suite pratique de l'article sur les cinq failles des projets juniors.
Le règlement (UE) 2024/2847 impose des obligations de cybersécurité au produit lui-même, et il vise tout éditeur qui vend du logiciel dans l'Union. Cet article détaille le périmètre exact, les trois échéances du calendrier, l'obligation de signalement applicable au 11 septembre 2026, les exigences de l'annexe I traduites en Python et en Node.js, et les pièges qui coûtent cher.
Une application peut fonctionner parfaitement et laisser filer les données de tous ses utilisateurs, sans qu'aucun symptôme n'apparaisse. Cet article décrit ce qui rend une application vulnérable, les trois failles que je retrouve le plus souvent en correction de projets, et ce que leur exploitation déclenche : facture, obligations RGPD, réputation, personnes touchées.
