Programmez ! vous met régulièrement en garde contre les failles de sécurité, le code mal ficelé, les erreurs de programmation. Aujourd’hui, la situation n’est pas pire qu’il y a quelques années mais les effets n’en sont pas moins catastrophiques. Pourtant, pour sécuriser une application, le développeur n’a, finalement, que peu de choses à faire. Il y a des réflexes à systématiser pour éviter les failles les plus basiques. Combien de sites web, d’applications oublient encore de vérifier le bon format de saisie d’un champ, en entrée et en sortie ? Or, ce petit oubli peut mettre K.O. votre site et si le hacker est bon, c’est le serveur qui tombe… Nous verrons aussi pourquoi il peut être utile de hacker son propre code ! Rien de malicieux là-dedans, juste des techniques peu connues pour comprendre un bug dans son code que l’on n’arrive pas à résoudre… Il y a quelques semaines, un rapport sur les 25 erreurs de code les plus fréquentes a eu le mérite de rappeler à tous les développeurs les risques d’attaques, faute d’un code mal testé, mal sécurisé. Reste à savoir si ces préconisations seront suivies par les éditeurs, les entreprises, les développeurs. Mais au final, qui est responsable d’un mauvais code dans un logiciel vendu dans le commerce ou sur un site web commercial ? Cette question légale n’est pas anodine et personne ne souhaite réellement ouvrir un débat explosif pour tout le monde. Faut-il établir une norme ISO officielle ?

François Tonic