« On verra la sécurité après le lancement. » J'ai entendu cette phrase dans au moins six réunions de lancement. Deux fois, j'ai fini par céder. Sur l'une de ces deux applications, on a découvert huit mois après la mise en production qu'une clé d'API Stripe traînait en clair dans le dépôt Git depuis le premier commit. Personne ne l'avait vue. On l'a révoquée en urgence un samedi matin, et cette histoire m'a coûté bien plus que les trois jours de travail qu'aurait demandés sa mise au propre initiale.
Sécuriser le développement de son application mobile, ce n'est pas une couche qu'on ajoute à la fin. C'est une manière de travailler qui s'organise dès la conception, qui se vérifie à chaque commit, et qui laisse des traces défendables le jour où un client ou un auditeur vous demande des comptes. Voici comment je m'y prends aujourd'hui, avec ce qui marche, ce qui ne marche pas, et ce que j'ai appris en me plantant.
Points clés à retenir
- La sécurité mobile se joue à quatre endroits distincts : le code de l'app, les secrets, les flux réseau, et le contrat avec le prestataire.
- Une clé d'API ne se stocke jamais dans le code source. Ni en clair, ni « juste pour tester ».
- L'obfuscation et le chiffrement local ralentissent un attaquant, ils ne l'arrêtent pas. Ce sont des couches, pas des solutions.
- Le volet juridique (propriété intellectuelle, contrat) est aussi un sujet de sécurité : qui détient le code, qui peut le modifier, qui répond d'une faille.
- Une revue de code dédiée à la sécurité une fois par trimestre suffit à rattraper la majorité des erreurs grossières.
Pourquoi sécuriser une application mobile ne commence jamais par du code
La première chose que je vérifie sur un projet, ce n'est pas le code. C'est le contrat.
Quand vous confiez le développement de votre application à un prestataire — agence, freelance, studio — la question de la propriété intellectuelle et celle de la sécurité sont liées plus qu'on ne le croit. Si le code source ne vous appartient pas formellement, vous ne pouvez pas le faire auditer par un tiers. Si le contrat ne prévoit pas d'obligations de sécurité minimale, vous n'avez aucun levier le jour où une faille sort des tests de l'agence en production.
Que prévoir dans un contrat de développement d'application mobile ?
Un modèle de contrat correct couvre au minimum quatre points que je vois presque toujours absents :
- La cession des droits de propriété intellectuelle sur le code livré. Elle doit être explicite, sans condition de paiement futur, et couvrir les évolutions.
- L'obligation de moyens sur la sécurité, avec mention des standards suivis (par exemple les recommandations de l'ANSSI pour la sécurisation des API, ou les règles OWASP MASVS côté mobile).
- La gestion des secrets : qui gère les clés d'API, où elles sont stockées, comment elles sont révoquées en cas de départ d'un intervenant.
- La notification d'incident, avec un délai. J'ai déjà vu un prestataire apprendre une fuite par la presse. Ça ne se reproduit pas deux fois.
Le dépôt de marque ou de code à l'INPI, souvent évoqué, ne protège pas contre une faille. Mais il vous protège contre un autre risque, plus fréquent qu'on ne le pense : qu'un prestataire réutilise le même socle technique chez trois de vos concurrents, avec vos choix d'architecture et vos failles dedans.
Les secrets, ce faux ami qui plombe la moitié des apps
Sur les douze applications mobiles que j'ai inspectées ces dernières années, neuf contenaient au moins un secret mal placé. Clé Stripe, clé Firebase, token d'accès à une API interne. Toujours la même histoire : « on avait besoin que ça marche vite ».
Où stocker une clé d'API dans une application mobile ?
Réponse courte : jamais dans le code de l'application. Ce qui est dans le binaire de l'app est accessible à quiconque a le téléphone et dix minutes de patience. Le décompilage d'un APK est un exercice d'école, et les outils ont beaucoup progressé.
Ce qui fonctionne, concrètement :
- Le mobile n'appelle jamais directement un service tiers sensible. Il passe par votre backend, qui garde les clés côté serveur.
- Le backend authentifie l'appel avec un jeton délivré à l'appareil après authentification utilisateur, à durée de vie courte.
- Les secrets d'environnement de développement sont dans un coffre (Vault, Secrets Manager, ce que vous voulez) et jamais dans le dépôt.
- Un hook de pré-commit refuse tout push contenant une chaîne qui ressemble à une clé. J'en utilise un depuis 2024, et il m'a sauvé au moins deux fois.
Le problème de la clé Firebase exposée, c'est que si les règles de sécurité Firestore sont mal configurées, n'importe qui peut lire toute la base. J'ai vu cette configuration exacte chez une startup parisienne, en 2025. Les données clients étaient publiques depuis huit mois. Ils l'ont appris par un message d'un chercheur en sécurité. Commentaire du CTO : « la clé est publique, c'est normal ». Non. La clé est publique, c'est inévitable. Les règles doivent être la barrière, et elles ne l'étaient pas.
Verrouiller une application sur Android ou iOS : ce qui marche vraiment
Sur ce terrain, il y a un fossé énorme entre ce que les articles recommandent et ce qui tient en production. L'obfuscation par R8 ou ProGuard, par exemple, personne ne la configure correctement la première fois. Moi le premier.
| Mesure | Effet réel | Effort de mise en place |
|---|---|---|
| Chiffrement local (Keystore / Keychain) | Protège les données si le téléphone est volé | Faible, mais attention aux migrations de clés |
| Certificate pinning | Bloque les attaques de type homme-du-milieu sur le réseau | Moyen, casse à chaque rotation de certificat serveur |
| Obfuscation de code | Ralentit la rétro-ingénierie, sans l'empêcher | Faible, mais peut casser les réflexions si mal configurée |
| Détection de root / jailbreak | Signal faible, contournable en quelques minutes | Élevé pour zéro gain réel sur la plupart des apps |
| Authentification biométrique | Utile pour conditionner l'accès à une fonction sensible | Faible |
Le certificate pinning, je l'ai déployé sur une app de paiement. Trois semaines après, on a renouvelé le certificat côté serveur sans mettre à jour les empreintes dans l'app. Résultat : toutes les versions installées ont cessé de fonctionner. On a mis six heures à comprendre, deux jours à pousser un correctif, et on a perdu ce week-end-là un peu de crédibilité. Depuis, je documente la procédure de rotation dans le README. Une ligne. Qui aurait évité deux jours de panique.
La sécurisation des API, l'angle qu'on oublie
Votre application est un client. Le serveur qui répond derrière, c'est lui qui détient les vraies données. Et c'est souvent là que le bât blesse.
Les recommandations de l'ANSSI sur la sécurisation des API ne sont pas réservées aux grands comptes. Elles tiennent en quelques principes qu'une équipe de trois personnes peut appliquer sans se ruiner :
- Authentifier chaque appel, y compris ceux qui semblent « internes ».
- Limiter le débit par utilisateur et par endpoint. Une API mobile non throttlée se fait aspirer en une nuit.
- Valider côté serveur tout ce qui vient du client. Toujours. Le client est hostile par défaut, même si c'est votre propre app.
- Journaliser les accès sensibles, avec un identifiant utilisateur. Sans logs, un incident devient une devinette.
J'ai perdu deux semaines en 2024 sur une API qui renvoyait l'objet utilisateur complet à chaque requête — mot de passe haché inclus. Personne ne l'avait vu parce que personne ne lisait les réponses en clair, seulement les codes HTTP. Un `curl` suffisait à s'en rendre compte. Une seule fois. Avouons-le : ça m'a un peu vexé.
Faut-il faire auditer son application mobile ?
Si vous manipulez des données de santé, bancaires ou d'identité, oui, sans hésiter. Sinon, un audit externe annuel coûte cher pour un retour souvent limité. Je préfère, sur des apps plus modestes, faire une revue interne trimestrielle ciblée sur les zones à risque : authentification, paiement, stockage local. Trois heures, deux développeurs, une checklist. Ça rattrape la majorité des erreurs grossières, pour un coût dérisoire comparé à un audit complet.
Ce que j'ai testé et qui ne marche pas
La détection de root, j'y ai cru. Sur une app grand public, j'ai passé une semaine à l'intégrer finement, avec plusieurs couches de vérification. Elle a tenu deux jours avant qu'un utilisateur curieux ne me montre comment la contourner avec un simple module Magisk. J'ai arrêté. Le rapport bénéfice/effort est mauvais pour la plupart des applications.
Les frameworks de sécurité « tout-en-un » qui promettent de chiffrer, obfusquer, détecter les attaques et bloquer les émulateurs, j'en ai testé deux. Ils ajoutent 6 à 9 Mo au binaire, cassent régulièrement à chaque mise à jour d'Android, et le support répond en trois jours. Le coût caché dépasse largement ce qu'ils apportent.
Ce qui marche, à l'inverse, c'est ennuyeux : une politique de secrets propre, un hook de commit, une revue de code trimestrielle, une API bien configurée côté serveur. Aucune de ces mesures ne fera un bon titre de conférence. Toutes tiennent en production.
Par où commencer demain matin
Si je devais reprendre un projet de zéro demain, je ferais trois choses dans cet ordre :
- Vérifier que le contrat de développement me cède bien le code et prévoit des obligations de sécurité minimales.
- Purger tous les secrets du dépôt, révoquer ceux qui ont fuité, et installer un hook de pré-commit qui bloque les prochains.
- Définir une politique de stockage local et l'appliquer partout où des données sensibles sont concernées.
Le reste — pinning, obfuscation, détection de root — vient après, quand ces trois bases tiennent. Beaucoup d'équipes font l'inverse : elles optimisent les couches avancées pendant que la clé Stripe dort dans un fichier `.env` committé depuis six mois.
Une question me trotte encore, d'ailleurs : combien d'applications que vous utilisez tous les jours ont, en ce moment même, un secret exposé sur un dépôt privé qui n'est pas si privé que ça ? La réponse honnête, c'est qu'on n'en sait rien. Et que c'est précisément pour ça qu'un hook de pré-commit coûte moins cher qu'un communiqué de presse.
