Sécurité d'une application : comptes, connexion et données

Quand on pense à la sécurité d’une application, on pense au mot de passe qu’un pirate devinerait. C’est rarement par là que les données fuient. Le plus souvent, l’application laisse simplement un utilisateur connecté lire ce qui ne lui appartient pas, parce qu’une règle d’accès manque quelque part. Pour un dirigeant, la bonne question n’est donc pas « nos mots de passe sont-ils assez compliqués ? », mais « qui vérifie, à chaque demande, que cette personne a le droit de voir cette donnée ? ».

La première faille : qui a le droit de voir quoi

Le classement de référence des risques des applications web, le Top 10 de l’OWASP, place en tête de son édition 2025 le contrôle d’accès défaillant, devant les erreurs de configuration. Les défaillances d’authentification, elles, n’arrivent qu’en septième position.

Le piège est de faire porter ces règles par l’écran. Masquer un bouton ne protège rien : quiconque connaît l’adresse de la donnée peut la demander directement au serveur. La règle doit vivre côté serveur, au plus près de la base. Avec Supabase, par exemple, ce sont les règles d’accès ligne à ligne : sa documentation demande de les activer sur chaque table exposée, et précise qu’une fois activées, aucune donnée n’est accessible par la clé publique tant qu’aucune règle ne l’autorise.

C’est aussi l’un des arguments de fond du choix entre Supabase, Firebase ou un serveur à soi : chacun exprime ces règles à sa façon, et aucun ne les écrit à votre place.

Une connexion à la mesure de l’usage

La connexion est la porte d’entrée de l’application, et chaque marche en trop fait perdre des utilisateurs. La bonne connexion dépend de ce que l’application protège.

• Sans compte, quand c’est possible. Apple le demande dans la règle 5.1.1 de ses consignes de revue : si l’application n’a pas de fonctions qui dépendent vraiment d’un compte, elle doit pouvoir s’utiliser sans connexion.
• Un lien ou un code par e-mail. Pas de mot de passe à retenir : l’utilisateur reçoit un lien à usage unique ou un code à six chiffres. Chez Supabase, ils expirent par défaut au bout d’une heure, selon sa documentation sur la connexion sans mot de passe.
• Les clés d’accès (passkeys). La connexion se fait avec le déverrouillage du téléphone, sans secret à taper ni à voler. La version 4 des lignes directrices d’identité numérique du NIST, publiée en juillet 2025, intègre les clés d’accès synchronisées, selon sa présentation.
• Un mot de passe, quand il le faut, mais selon les règles actuelles, qui ont beaucoup changé.

Le même texte interdit d’exiger un changement périodique du mot de passe, sauf signe de compromission, et demande de refuser les mots de passe courants ou déjà apparus dans des fuites.

Les secrets ne vivent pas sur le téléphone

Tout ce qui est livré dans l’application (le code de l’écran, ses fichiers) peut être lu par un curieux. Une clé d’API payante, une clé d’administration de la base ou un identifiant de service n’y ont donc pas leur place. Supabase le dit sans détour : sa clé secrète contourne les règles d’accès et ne doit jamais se trouver dans le navigateur ni chez un client.

Ce qui demande un secret passe par une fonction côté serveur, qui fait l’appel et ne renvoie que le résultat. C’est vrai pour un paiement, pour un envoi d’e-mail, pour un appel à un modèle d’IA. Le sujet dépasse les applications : notre article sur les coffres-forts de secrets montre comment des outils s’en servent sans jamais les voir.

Ce que les données de vos utilisateurs exigent

Une application qui crée des comptes traite des données personnelles, avec des obligations précises.

• La suppression du compte dans l’application. Apple l’exige de toute application qui permet d’en créer un, dans la même règle 5.1.1. Supprimer veut dire effacer les données, pas seulement masquer le profil.
• Ne demander que l’utile. Toujours selon Apple, une application ne peut exiger des informations personnelles que si elles servent sa fonction principale ou si la loi l’impose. Le RGPD dit la même chose sous le nom de minimisation.
• Un plan en cas de fuite. L’article 33 du RGPD impose de notifier une violation de données à l’autorité de contrôle dans les 72 heures après en avoir pris connaissance, sauf si elle ne présente pas de risque pour les personnes. Savoir qui prévient qui, avec quels journaux, se décide avant.
• Des sauvegardes restaurables. Une base perdue est aussi un incident de sécurité. Une sauvegarde qu’on n’a jamais restaurée ne protège de rien, comme le montre ce qui casse vraiment dans les sauvegardes.

Ce qu’il faut demander à votre prestataire

1. 01La carte des accès.

   Pour chaque type d’utilisateur, ce qu’il voit, modifie et supprime, écrit avant le développement.

2. 02Des tests de ces règles.

   Un test qui se connecte en client A et vérifie qu’il ne lit rien du client B, rejoué à chaque version.

3. 03L’inventaire des secrets.

   Où vit chaque clé, qui y a accès, comment on la change si elle fuit.

4. 04Le parcours de suppression et de fuite.

   Comment un utilisateur supprime son compte, comment l’équipe réagit à une violation.

Ces points se décident au cadrage, et c’est là qu’ils coûtent le moins : une règle d’accès oubliée se corrige en une ligne avant le lancement, et en notification à l’autorité après. Ils font partie de ce qui fait varier le prix d’une application, surtout quand plusieurs rôles cohabitent, comme dans un portail client ou une application pour les équipes terrain. Et ils se suivent dans le temps, avec les mises à jour des bibliothèques comptées dans le budget de maintenance.

Notre développement d’applications fait tenir les droits d’accès par le serveur, et non par l’écran : ce qui doit être juste, comme un compteur, une date ou un droit d’accès, ne dépend pas du téléphone.

Questions fréquentes

Sources

1. OWASP Top 10:2025 (nouvel onglet)top10.owasp.org
2. Documentation Supabase, Row Level Security (nouvel onglet)supabase.com
3. Matt Palmer, CVE-2025-48757 (nouvel onglet)mattpalmer.io
4. Apple, consignes de revue de l’App Store (nouvel onglet)developer.apple.com
5. Documentation Supabase, connexion sans mot de passe (nouvel onglet)supabase.com
6. NIST SP 800-63, révision 4 (nouvel onglet)pages.nist.gov
7. Règlement général sur la protection des données, EUR-Lex (nouvel onglet)eur-lex.europa.eu