Nous en sommes témoins depuis plusieurs années. Les problèmes de sécurité dans les applications web sont toujours présents et sont relativement toujours les mêmes. Leur caractère ne change pas. Nous voyons fréquemment les mêmes problèmes d'injection SQL, d'exécution de code ou de technique d'interruption de service qu'il y a dix ans.

Les applications Web sont souvent modulaires; votre navigateur effectue des opérations, ces dernières ont des effets sur plusieurs couches serveurs. De plus, plusieurs modules peuvent être greffés à votre navigateur. Depuis l'arrivée de la programmation modulaire, les applications sont de plus en plus difficiles à sécuriser [1]. Une faille effectuée par un navigateur sur une section de site peut facilement influencer plusieurs autres services en brimant le caractère privé des informations, l'intégrité ou même la continuité de l'ensemble des services du serveur.

La redondance des problèmes de sécurité sur le Web nous oblige à remettre en question les méthodes utilisées dans l'exécution d'un projet. Le coût relatif à une importante considération des facteurs de risque peut grossir considérablement les estimations du développement d'un logiciel. Par le fait même, la connaissance des risques et des vulnérabilités courantes au stade de conceptualisation donne une très grande valeur au produit informatique final.

Avec le temps, nous avons encouragé la programmation sécuritaire en fournissant aux programmeurs de l'information sur ces techniques. La recherche et la publication en sécurité de l'information est pour notre entreprise une activité régulière et primordiale. Une excellente connaissance de ces techniques ne suffit pas à garantir l'absence de vulnérabilités, c'est pourquoi le cycle de développement XP est très important.

La construction d'applications Web possédant plusieurs paliers de permissions complexifie beaucoup la structure d'un logiciel. Cette propriété combinée à l'augmentation exponentielle du nombre d'usagers crée une sorte de jungle incontrôlable. Une pression importante du marché et du client nous oblige trop souvent à minimiser l'importance du cycle de développement. Les facteurs exprimés plus haut sont proportionnellement liés à la chronologie d'exécution des étapes du développement.

"Ne pas porter un projet en production, c'est de l'argent dépensé sans bénéfice rapporté. Ce n'est peut-être que mon portefeuille, mais je trouve cet état très inconfortable du point de vue du client." [2]

Les étapes et l'ordre de production deviennent des facteurs importants sur la qualité du produit final.

Néanmoins, cette méthode de développement est inutile si la structure de choix et des décisions n'est pas clairement établie au départ. La prise de décision initiale est donc très importante dans le succès du projet.

L'ensemble des productions de chez Heptacube sont conformes à ces normes de sécurité tout en assurant la protection de la vie privée du consommateur. Elles représentent un effort énorme de recherche et de développement. Nous appliquons la même attention particulière dans les travaux effectués pour nos clients. Pour ces derniers, Heptacube fournit une excellente documentation dans son processus de prise de décision. Nous suivons des étapes structurées afin de toujours choisir la solution adéquate [3]:



L'utilisation des documents de conceptualisation reconnus en génie logiciel aide à la prise de décision. Des standards définis dans les années 90 sont toujours actuels.

En guise de conclusion, nous désirons mettre en évidence l'idée que les techniques inchangées de cyberattaque sont une réponse à des problèmes redondants. L'absence ou la mauvaise utilisation d'un cycle de développement augmente les risques de vulnérabilité des logiciels. Nous avons exposé les différentes étapes choisies par notre entreprise permettant de prendre des décisions éclairées lors de projets d'envergure. Nous croyons que ces méthodes utilisées comme guide aident beaucoup à mener des projets Web d'envergure et évitent ainsi d'inutiles pertes monétaires.

[1] Bruce Schneier, Secret and Lies, page 160.

[2] Kent Beck, Extreme Programming explained, page 131.

[3] Risk and Decision analysis in projects, John Schuyler, decision analysis process, page 23.