Mobile Security
Version : 1.0
Statut : Architecture cible
ADR : MOBILE-010
1. Objectif
La sécurité de DMV Mobile ne consiste pas à protéger uniquement l'application.
Elle consiste à protéger :
- les utilisateurs ;
- les données personnelles ;
- les comptes ;
- les acteurs ;
- les communes ;
- la plateforme DMV.
La sécurité est donc une responsabilité transversale de toute l'architecture mobile.
Elle doit être pensée dès la conception ("Security by Design") et non ajoutée après le développement.
2. Principes fondateurs
La sécurité mobile repose sur plusieurs principes considérés comme non négociables.
Le téléphone est considéré comme non fiable
Un smartphone appartient à l'utilisateur.
Il peut être :
- perdu ;
- volé ;
- rooté ;
- jailbreaké ;
- compromis.
L'architecture ne doit donc jamais lui faire confiance.
Le serveur reste la référence
Toutes les décisions de sécurité sont prises côté serveur.
Exemples :
- authentification
- permissions
- rôles
- droits
- validation métier
Le téléphone ne décide jamais.
Zero Trust
Chaque requête est considérée comme potentiellement malveillante.
Chaque appel API est donc :
- authentifié ;
- autorisé ;
- validé.
Aucune confiance implicite n'existe.
Least Privilege
Chaque composant possède uniquement les droits nécessaires.
Exemples :
Une caméra ne peut pas accéder aux contacts.
Une notification ne peut pas accéder au stockage.
Une publication ne peut pas modifier un acteur.
3. Architecture de sécurité
Utilisateur
↓
Application
↓
Authentification
↓
API Laravel
↓
Autorisation
↓
Métier
↓
Base PostgreSQL
Toutes les décisions de sécurité sont centralisées.
État actuel
Le backend Laravel contient déjà le mécanisme d'échange supabase_token vers token Sanctum. Le projet utilise firebase/php-jwt, laravel/sanctum et une configuration Supabase JWT.
Côté applications web, des tokens sont encore stockés dans les mécanismes web disponibles. Pour DMV Mobile, cette pratique ne constitue pas la cible : les tokens mobiles doivent être stockés dans Secure Storage via la couche native.
Architecture cible
La sécurité mobile applique Security by Design : Auth Supabase, validation JWT Laravel, token Sanctum pour les APIs métier, stockage sécurisé natif, permissions métier côté serveur et absence de secrets dans le shell mobile.
Migration
La migration consiste à :
- conserver Supabase Auth comme fournisseur d'identité ;
- stabiliser l'échange JWT Supabase → token Sanctum ;
- déplacer le stockage token mobile vers Secure Storage ;
- centraliser l'expiration, le renouvellement et le logout dans la couche session mobile ;
- auditer les appels directs Supabase pour vérifier RLS, scopes et absence de secrets.
4. Authentification
L'authentification DMV repose sur une chaîne explicite :
Supabase Auth
↓
JWT Supabase
↓
Laravel
↓
Sanctum
↓
Business API
Responsabilités :
- Supabase Auth gère l'identité primaire, la connexion et l'émission du JWT.
- Le JWT Supabase transporte la preuve d'identité vers Laravel.
- Laravel valide le JWT, rattache ou crée le profil applicatif et applique les règles métier.
- Sanctum émet et vérifie le token applicatif utilisé par les routes API métier.
- Secure Storage conserve les tokens côté mobile, jamais
localStorage. - Le mobile orchestre la session et renouvelle l'accès sans connaître les rôles ou permissions métier.
- L'API expose uniquement les opérations autorisées après validation Laravel/Sanctum.
La cible ne consiste pas à remplacer Supabase Auth par Laravel. La cible consiste à rendre la frontière Supabase Auth → Laravel → Sanctum explicite, sécurisée et stable.
5. Cycle de vie du token
Connexion
↓
Création token
↓
Stockage sécurisé
↓
Utilisation
↓
Expiration
↓
Renouvellement
↓
Déconnexion
Le token ne doit jamais être stocké en clair.
6. Stockage sécurisé
Toutes les informations sensibles utilisent le stockage sécurisé du système.
Android :
Keystore
iOS :
Keychain
Jamais :
- LocalStorage
- fichiers JSON
- SQLite non chiffré
7. Données stockées
Peuvent être stockés :
- préférences ;
- cache ;
- brouillons ;
- thème.
Ne doivent jamais être stockés en clair :
- token ;
- informations sensibles ;
- secrets ;
- clés.
8. Chiffrement
Toutes les communications utilisent TLS.
Aucune communication HTTP n'est autorisée.
Les données sensibles présentes sur le téléphone peuvent être chiffrées avant stockage.
9. Biométrie
La biométrie constitue un confort utilisateur.
Jamais une méthode de sécurité indépendante.
Le schéma est le suivant :
Face ID
↓
Déverrouille le token
↓
Token valide
↓
Connexion
La biométrie ne remplace jamais l'authentification serveur.
10. Déconnexion
Lors d'une déconnexion :
La plateforme doit supprimer :
- token ;
- cache sécurisé ;
- session ;
- données sensibles.
Les brouillons peuvent être conservés selon leur nature.
11. Root / Jailbreak
La plateforme doit être capable de détecter un environnement compromis.
Exemples :
- appareil rooté ;
- jailbreak ;
- debugger ;
- hook système.
Cette détection ne bloque pas obligatoirement l'application.
Elle permet :
- d'adapter certaines fonctions ;
- de renforcer les contrôles ;
- de produire des alertes.
12. Reverse Engineering
L'application doit limiter :
- la rétro-ingénierie ;
- le patching ;
- la modification du code.
Exemples :
- obfuscation ;
- suppression des logs sensibles ;
- builds Release sécurisés.
13. Logs
Les journaux ne doivent jamais contenir :
- mot de passe ;
- token ;
- données médicales ;
- données personnelles.
Les logs servent uniquement au diagnostic technique.
14. Permissions
Les permissions sont accordées selon le principe :
Need to Know.
Exemple :
Une publication photo demande :
Caméra.
Elle ne demande pas :
- GPS
- Contacts
- Bluetooth
15. Protection réseau
Toutes les communications utilisent :
HTTPS
TLS récent
HSTS
Les certificats doivent être validés.
Le Certificate Pinning pourra être étudié si le niveau de menace le justifie.
16. Notifications Push
Une notification ne contient jamais d'information sensible.
Exemple :
✔ Nouvelle publication disponible.
✘ Votre facture n°1254 est impayée.
Le contenu détaillé est récupéré uniquement après authentification.
17. Données personnelles
DMV applique le principe :
Privacy by Design.
Le téléphone ne conserve que les données strictement nécessaires.
Les informations sensibles restent sur le serveur.
18. Conformité
L'architecture mobile devra respecter :
- RGPD
- recommandations Apple
- recommandations Google
- OWASP Mobile Top 10
Ces référentiels devront être intégrés au processus qualité.
19. Incident de sécurité
En cas de compromission :
Le serveur doit pouvoir :
- révoquer un token ;
- forcer une reconnexion ;
- invalider une session ;
- désactiver un appareil.
Aucune intervention sur le téléphone ne doit être nécessaire.
20. Audit
Chaque version majeure de DMV Mobile devra faire l'objet :
- d'un audit sécurité ;
- d'une revue OWASP Mobile ;
- d'un contrôle des dépendances ;
- d'une revue des permissions.
21. ADR
Alternatives étudiées
Authentification locale
Rejetée.
Le serveur doit rester la référence.
Token stocké en LocalStorage
Rejeté.
Insuffisamment sécurisé.
Secure Storage + Supabase JWT + Sanctum
Retenu.
Compatible avec l'architecture DMV.
Supabase Auth reste responsable de l'identité, Laravel valide le JWT et Sanctum protège les routes métier.
Éprouvé.
22. Décisions figées
✅ Le serveur reste responsable de la sécurité.
✅ Les tokens sont stockés dans le Secure Storage.
✅ Aucune donnée sensible en clair.
✅ Toutes les communications utilisent TLS.
✅ Le téléphone est considéré comme non fiable.
✅ Zero Trust.
✅ Least Privilege.
✅ Privacy by Design.
Conclusion
La sécurité de DMV Mobile ne repose pas sur une accumulation de protections techniques.
Elle repose sur une architecture où le téléphone est considéré comme un client potentiellement compromis, tandis que le serveur conserve l'ensemble des responsabilités de sécurité.
Cette approche permet de limiter les risques, de simplifier les évolutions futures et de garantir un niveau de protection cohérent sur Android comme sur iOS.