Sécurité : les vérifications à la portée de tout testeur

Pas besoin d’être un pirate pour découvrir une faille. Parfois, il suffit de se déconnecter, de toucher le bouton Retour… et de retrouver son solde, son historique et le bouton « Envoyer de l’argent », parfaitement fonctionnels.

Beaucoup de défauts de sécurité sérieux se voient en utilisant l’app normalement, avec un œil attentif : une session qui survit à la déconnexion, un message d’erreur qui révèle qu’un numéro possède un compte, un lien de reçu qui s’ouvre chez n’importe qui. Ces défauts-là, un testeur non spécialiste peut et doit les repérer.

Cet article vous donne les vérifications à votre portée, sans rien casser ni attaquer, la frontière à ne jamais franchir, et la bonne façon de signaler une faille sans mettre personne en danger, vous compris.

Ce qu’un testeur peut vérifier, et où s’arrête son rôle

Votre rôle consiste à observer comment l’app se comporte quand on l’utilise normalement, ou maladroitement, avec vos propres comptes de test. Le rôle de l’expert consiste à attaquer volontairement le système pour mesurer sa résistance. Le tableau suivant trace la frontière.

Mots de passe et connexion : ce que vous pouvez contrôler

La référence la plus citée est la publication SP 800-63B-4 du NIST, l’institut national américain des normes et de la technologie, publiée en juillet 2025. Elle s’adresse d’abord aux administrations américaines, mais sert de point de repère bien au-delà. Ses principales règles pour les mots de passe :

• au moins 15 caractères quand le mot de passe est le seul moyen de connexion, au moins 8 s’il s’accompagne d’un second facteur, comme un code OTP ;
• au moins 64 caractères acceptés ;
• pas de règles de composition imposées (une majuscule, un chiffre, un symbole) ni de changement périodique obligatoire ;
• refus des mots de passe courants ou déjà compromis ;
• coller et gestionnaires de mots de passe autorisés, avec une option pour afficher le mot de passe saisi ;
• un nombre limité de tentatives échouées.

Votre projet peut avoir sa propre politique : c’est elle qui fait foi, le NIST sert à la discuter. Avec vos comptes de test, vérifiez ensuite :

1. Les mots de passe faibles. Essayez « 123456 » ou « azerty ». Sont-ils refusés, avec une explication ?
2. Les mots de passe longs. Collez un mot de passe de 64 caractères. Est-il accepté en entier, ou tronqué en silence, ce qui empêche ensuite de se reconnecter ?
3. Les erreurs répétées. Faites une dizaine d’erreurs, à la main, jamais avec un script. L’app impose-t-elle un délai ou un blocage temporaire ?
4. Le message d’échec. « Identifiant ou mot de passe incorrect » est correct. « Aucun compte n’existe avec ce numéro » révèle qui est client.
5. Le mot de passe oublié. Le lien ou le code de réinitialisation sert-il une seule fois ? Expire-t-il ? L’ancien mot de passe cesse-t-il de fonctionner ?
6. Le mot de passe en clair. Il ne doit jamais apparaître dans un SMS, un e-mail de bienvenue ou une adresse web.

Sessions et déconnexion : les tests qui révèlent le plus

Ces six tests prennent dix minutes et trouvent souvent des défauts sérieux :

1. Déconnexion puis Retour. Touchez Retour, ou le bouton « précédent » du navigateur. Les écrans privés doivent rester inaccessibles et aucune action ne doit fonctionner.
2. L’adresse copiée. Sur le web, copiez l’adresse d’une page privée, déconnectez-vous, puis collez-la dans une fenêtre de navigation privée. Vous devez arriver sur l’écran de connexion.
3. Deux appareils. Connectez le même compte de test sur deux téléphones, puis changez le mot de passe sur l’un. Que devient la session de l’autre ? Comparez avec ce que prévoit le cahier des charges.
4. L’inactivité. Laissez une app sensible, de banque ou de santé, ouverte sans y toucher. Redemande-t-elle une identification après le délai décidé par l’équipe ?
5. Les apps récentes. Ouvrez la liste des apps récentes : l’aperçu affiche-t-il votre solde ou un code ?
6. La réinstallation. Désinstallez puis réinstallez l’app. Vos données ou votre session réapparaissent-elles sans connexion ?

Données visibles, erreurs bavardes et liens partagés

Les données affichées. Un numéro de carte ne devrait montrer que ses derniers chiffres. Vérifiez aussi ce qu’affichent les notifications sur l’écran verrouillé : un code ou un montant y est-il lisible sans déverrouiller ? Sur le web, regardez l’adresse : un e-mail, un numéro de téléphone ou un jeton n’ont rien à y faire, car l’adresse se retrouve dans l’historique et dans les liens partagés.

Les messages d’erreur bavards. Un message qui affiche une trace technique (« NullPointerException at com.app… »), une requête de base de données, un chemin de fichier ou une version de serveur donne des indices précieux à un attaquant. Provoquez des erreurs ordinaires : champ vide, format invalide, réseau coupé. L’utilisateur doit lire un message simple, et rien d’autre.

Les liens partagés. Reçus, factures, ordonnances, bulletins de notes : ouvrez le lien avec un second compte de test, ou dans une fenêtre de navigation privée. L’accès doit être refusé, sauf si le lien a été voulu public ; il doit alors être impossible à deviner et, idéalement, expirer.

Ne modifiez jamais un numéro dans une adresse pour tomber sur les données d’un vrai client. Ce test se fait uniquement entre vos propres comptes de test, dans un environnement de test, et seulement si votre mission le prévoit.

Les captures d’écran. Code secret, numéro de carte, code OTP : demandez à l’équipe ce qui a été décidé pour ces écrans. Sur Android, une app peut empêcher les captures et les enregistrements de certains écrans. Vérifiez que le comportement réel correspond à la décision, y compris pendant un partage d’écran en appel vidéo.

Permissions et codes OTP : deux zones à surveiller

Les permissions

Chaque permission doit avoir une raison visible. Une app de lampe torche qui veut lire vos contacts doit vous alerter. Android recommande de demander une permission au moment où l’utilisateur lance la fonction qui en a besoin, d’expliquer pourquoi, et de laisser l’app fonctionner si la réponse est non, en désactivant seulement la fonction concernée.

Pour le tester, installez l’app sur un téléphone propre et comptez les demandes au premier lancement. Refusez tout, puis utilisez l’app : plante-t-elle ? Vous harcèle-t-elle ? Retirez ensuite une permission dans les réglages en cours d’usage, et revenez dans l’app.

Les codes OTP

Vérifiez quatre comportements :

• Usage unique : un code déjà utilisé doit être refusé.
• Expiration : le NIST exige que la vérification par un code envoyé sur un autre canal, comme un SMS, soit terminée en 10 minutes au plus.
• Tentatives limitées : après quelques codes faux saisis à la main, l’app doit ralentir ou bloquer.
• Renvoi : un délai sépare-t-il deux envois ? L’ancien code reste-t-il valable ? Comparez avec la règle prévue.

Les référentiels OWASP pour parler le langage des experts

Citer la bonne catégorie aide l’équipe à comprendre et à prioriser. Le tableau suivant relie ce que vous pouvez observer aux catégories des deux classements.

Pour aller plus loin sur mobile, l’OWASP publie aussi le MASVS, un standard d’exigences de sécurité, et le MASTG, un guide de test détaillé. Ce sont les outils des experts : les connaître vous aide à dialoguer avec eux.

Comment signaler une faille sans mettre personne en danger

Une faille se signale autrement qu’un bouton mal aligné :

• Canal privé : écrivez à la personne désignée par votre mission, jamais dans un groupe WhatsApp, un ticket public ou sur les réseaux sociaux.
• Minimum de données : masquez toute donnée personnelle sur vos captures et n’utilisez que des comptes de test.
• Arrêtez-vous : une fois le problème constaté, ne cherchez pas à récupérer davantage de données pour « prouver » la gravité.
• Discrétion : n’en parlez à personne d’autre tant que la faille n’est pas corrigée.

Titre : session toujours active après déconnexion (bouton Retour)
Gravité proposée : élevée (données personnelles et paiement accessibles)
Environnement : Android 14, app 3.2.0, environnement de test, comptes de test A et B
Étapes : 1. Se connecter avec A  2. Se déconnecter  3. Toucher Retour
Résultat : l'historique s'affiche et le bouton « Envoyer » fonctionne
Attendu : retour à l'écran de connexion, aucune action possible
Catégorie : OWASP A07:2025 Authentication Failures
Pièces jointes : vidéo, données personnelles masquées

Pour le reste de la rédaction, suivez le guide du rapport de bug efficace. Et gardez ces tests dans vos séances de test exploratoire : c’est souvent en sortant du chemin prévu que les failles apparaissent.

Votre liste de contrôle sécurité

Déroulez cette liste à chaque nouvelle version, avec vos comptes de test.

Ces vérifications font partie de ce qu’on attend d’un testeur complet. Si vous voulez en faire votre métier, découvrez comment devenir testeur d’applications, puis rejoignez les testeurs GeekTest.

Pour aller plus loin

• OWASP Top 10:2025 (nouvel onglet) (en anglais) : les dix risques les plus critiques des applications web, dans leur dernière version.
• OWASP Mobile Top 10 (nouvel onglet) (en anglais) : les dix risques principaux des applications mobiles, version 2024.
• OWASP MAS, MASVS et MASTG (nouvel onglet) (en anglais) : le standard et le guide de test de sécurité mobile utilisés par les experts.
• NIST SP 800-63B-4 (nouvel onglet) (en anglais) : les exigences sur les mots de passe, les tentatives échouées et les codes à usage unique.
• Demander des autorisations d’exécution, Android Developers (nouvel onglet) : quand et comment demander une permission, et que faire en cas de refus.
• Loi n° 2010/012 du 21 décembre 2010 relative à la cybersécurité et à la cybercriminalité au Cameroun, base CYRILLA (nouvel onglet) : la fiche et le texte de la loi, dont l’article 65 sur l’accès non autorisé.