Après les tests fonctionnels, de performance, de compatibilité et d’utilisabilité au sens ISO – 25 010, je m’attaque dans cet article à la famille des tests de sécurité afin de savoir exactement à quoi correspond la « sécurité » dans le cadre de la qualité logicielle.
Pour avoir plus d’informations sur la norme ISO – 25 010, je vous invite à lire ou relire mes autres articles sur le sujet.
Les tests de sécurité sont une famille de tests qui est devenu très connue et qui est également devenue très importante pour le grand public, notamment vis à vis de la protection des données (la RGPD).
Ici le problème n’est pas dans le fait d’apprécier l’utilisation d’une application à travers son ergonomie, ses fonctionnalités ou performances… il n’est pas non plus question de savoir si cette application peut s’adapter à n’importe quel environnement ou si l’application est perenne. Ici le problème est moins visible directement… mais les conséquences peuvent être beaucoup plus problématique qu’un simple crash ou un lag applicatif.
Ici il est question de sécurité, et par sécurité il faut bien sûr entendre sécurité pour l’application et son environnement, mais aussi sécurité pour les utilisateurs de l’application.
Qui mettrait des informations confidentielles et importantes comme son numéro de carte bancaire ou ses accès à sa boîte mail s’il sait que l’application dans laquelle il va entrer ces données n’est pas sécurisée correctement?
Ce n’est pas pour rien que de nombreux scandales nt éclatés car des grandes entreprises comme Yahoo ou Sony ont été piratées, laissant les hacker partir avec des informations des utilisateurs.
De même, toute personne avertie refuserait d’effectuer un paiement ou rentrer des données confidentielles sur une URL qui n’est pas en https (mais en http).
Les tests de sécurité sont justement là pour s’assurer que les règles à mettre en place afin de garantir une sécurité acceptable (en fonction de la criticité des données ou informations à protéger) sont bien mis en place.
Si la sécurité vous intéresse, pensez à regarder ce qui est proposé par OWASP.
Comme vous pouvez le voir avec l’image ci-dessus, la famille des tests de sécurité contient, d’après la norme ISO – 25 010, 5 types de tests spécifiques, chacun ayant un rôle bien définit :
- Les tests de confidentialité
Ces tests ont pour but de s’assurer que seules les personnes autorisées à avoir accès à des données y ont accès.
En d’autres terme c’est vérifier qu’un simple utilisateur n’aura pas accès aux informations d’autres utilisateurs, que son conseiller de banque n’aura pas accès à notre mot de passe, qu’un testeur d’une application utilisant le paiement n’aura pas accès à des cartes de crédit ou des comptes Paypal réels…
Bref les tests de confidentialité sont là pour s’assurer que seuls les personnes voulues ont accès aux données. Cette confidentialité est essentielle afin d’avoir la confiance des potentiels utilisateurs. Sans cette dernière personne n’utiliserai l’application (dès lors ou le problème est connu).
- Les tests d’intégrité
Les tests d’intégrité ont, quant à eux, un but différent. Ils visent à assurer que les personnes non autorisées n’ont pas accès à l’application, aux données de cette dernière, ou même à l’environnement sur lequel est hébergé l’application.
L’intégrité est essentielle. A quoi bon avoir une bonne confidentialité si n’importe qui peut se faire passer pour un administrateur? une application ne doit pas permettre d’accéder à l’ensemble de l’environnement sur lequel elle est installée. Si c’est le cas cela peut revenir à avoir accès à tout l’ordinateur d’un utilisateur en réussissant uniquement à accéder à une application.
- Les tests de rejet (et non rejet)
Les tests de rejet ou de non-répudiation sont des tests plus techniques. Ils visent à s’assurer que les informations et actions faites ont bien été faites et validées par les parties concernées. Cela permet, entre autre, d’empêcher tout retour en arrière. Ces tests sont particulièrement importants pour tout ce qui est contractuel (ex: CGU, contrat de vente, vente d’actions, virement bancaire…).
Une technologie fréquemment utilisée pour assurer une bonne sécurité pour les tests de rejet est l’utilisation de certificat numérique ou de clé privé. On peut notamment le voir avec les mails signés qui sont de plus en plus courant dans le cadre professionnel.
- Les tests de responsabilité
Ces tests ont pour but de s’assurer qu’il est possible de savoir que les actions effectuées par un utilisateur sont bien liées de façon unique à cet utilisateur. C’est un peu le principe du logbook applicatif permettant de suivre les changements. Un logbook n’a de sens que s’il est possible de savoir qui a fait telle action et quand cette dernière a été effectuée.
- Les tests d’authenticité
Les tests d’authenticité sont là pour s’assurer que la personne (ou utilisateur ou entité…) qui a été identifiée comme ayant fait une action est bien celle-ci. On pense évidemment au couple login / mot de passe qui est censé être un identifiant unique permettant de s’assurer cette authenticité.
Malheureusement ce n’est pas toujours suffisant, en effet, un login / mot de passe peut être partagé, un utilisateur peut être usurpé par un administrateur…
Dans cet article je n’aurai pas parlé de tests boîte noire avec la vérification que les informations fournies par l’application ne sont pas problématiques (ex: mot de passe non crypté, version précise de langage utilisé…) ni de test boîte blanche dans lesquels le code est vérifié afin de détecter la présence de failles, ni même de test boîte grise ou de tentatives d’intrusion. La raison est simple, ces tests peuvent être appliqués à différents types de tests de sécurité et donc pas 1 type de test spécifique. Ces techniques de tests sont d’ailleurs des techniques et non des types de test.
Source ISO – 25 010
Syllabus ISTQB fondation 2018 Lien anglais car non disponible en français à la date d’écriture
Pensez à rejoindre le groupe Le métier du test si le test vous intéresse !
N’hésitez pas à me suivre et lire mes autres articles si vous voulez en apprendre plus sur le test ou venir partager vos connaissances
Merci à tous ceux qui mettent « j’aime », partagent ou commentent mes articles
La taverne du testeur 
[…] Les tests dépendent toujours du contexte. Le testeur agile doit donc, de préférence pour chaque User Story, construire avec les membres de l’équipe de développement un plan de test permettant de mettre en place une stratégie spécifique à cette fonctionnalité afin d’être le plus efficace possible par rapport au contexte. L’exemple du point précédent est un exemple d’adaptation au contexte. Il existe néanmoins de nombreux autres contextes que les simples contexte fonctionnels. On peut notamment penser à un contexte de sortie obligatoire avant les fêtes de fin d’année ou des contexte d’image de la société qui préfère avoir une très bonne qualité, un contexte lié aux utilisateurs, la concurrence ou encore des contextes non fonctionnels (comme les performances, la fiabilité ou la sécurité…). […]
J’aimeJ’aime
[…] Les tests de sécurité […]
J’aimeJ’aime