Vue d'ensemble de la sécurité
Fondamentaux de la sécurité mobile — différences avec le web, signature d'app, stockage sécurisé et modèles de menaces.
Vue d'ensemble de la sécurité
La sécurité mobile diffère significativement de la sécurité web. Il n'y a pas de Content Security Policy ou CORS, mais vous gagnez la signature d'app, le stockage sécurisé matériel et un environnement sandboxé.
Sécurité web vs mobile
| Préoccupation | Web | Mobile |
|---|---|---|
| Visibilité du code | JavaScript lisible dans le navigateur | Binaire compilé mais décompilable |
| Stockage | Cookies, localStorage (accessible) | Keychain/Keystore (chiffré matériellement) |
| Réseau | CORS, en-têtes CSP | Certificate pinning |
| Distribution | URL directe | Processus de revue App Store |
| Identité | Cookies de session | Certificats de signature d'app |
| Permissions | Prompts du navigateur | Système de permissions de l'OS |
Modèle de menaces
Menaces spécifiques au mobile :
- Rétro-ingénierie — Les attaquants peuvent décompiler votre APK/IPA pour lire le code
- Homme du milieu — Le trafic réseau peut être intercepté sur un WiFi non sécurisé
- Vol d'appareil — Accès physique à un appareil déverrouillé
- Jailbreak/root — Un OS modifié contourne le sandboxing de sécurité
- Stockage non sécurisé — Données sensibles stockées en texte clair
Checklist de sécurité
Stockage
- Stocker les tokens d'auth dans
expo-secure-store(pas AsyncStorage) - Ne jamais stocker de secrets API dans le bundle de l'app
- Utiliser des variables d'environnement pour la configuration, pas de valeurs codées en dur
- Effacer les données sensibles à la déconnexion
import * as SecureStore from "expo-secure-store";
// Bien — stockage chiffré
await SecureStore.setItemAsync("auth-token", token);
// Mal — stockage en texte clair
await AsyncStorage.setItem("auth-token", token);Réseau
- Utiliser HTTPS pour tous les appels API (jamais HTTP)
- Implémenter le certificate pinning pour les apps sensibles
- Valider toutes les réponses serveur
- Définir des timeouts de requête
Authentification
- Utiliser l'authentification biométrique pour les actions sensibles
- Implémenter l'expiration de session et le rafraîchissement automatique
- Verrouiller l'app après inactivité
- Supporter la déconnexion sécurisée qui efface tous les tokens
Code
- Ne jamais intégrer de clés API ou secrets dans le code JavaScript
- Utiliser
expo-constantspour la configuration spécifique à l'environnement - Activer le moteur Hermes (compile le JS en bytecode, plus difficile à lire)
import Constants from "expo-constants";
// Bien — depuis l'environnement
const apiUrl = Constants.expoConfig?.extra?.apiUrl;
// Mal — codé en dur
const apiUrl = "https://my-api.com/secret-key-here";Build et distribution
- Signer les builds de release avec des certificats appropriés
- Activer ProGuard (Android) pour l'obfuscation du code
- Utiliser l'App Store et le Play Store comme seuls canaux de distribution
- Activer Play Integrity / App Attest pour la protection API
Paramètres par défaut de ScaleRocket Mobile
ScaleRocket Mobile inclut nativement :
| Fonctionnalité | Implémentation |
|---|---|
| Stockage de tokens | expo-secure-store (Keychain/Keystore) |
| Flux d'auth | Rafraîchissement auto de session, déconnexion sécurisée |
| HTTPS | Tous les appels API en TLS |
| Biométrie | Optionnel via expo-local-authentication |
| Config d'environnement | Via extras de app.json |
Prochaines étapes
- Stockage sécurisé — Plongée dans le stockage chiffré
- Permissions — Demander les permissions de l'appareil
- SSL Pinning — Certificate pinning pour les appels API
Haptique
Utilisation d'expo-haptics pour le retour tactile sur les appuis de boutons, confirmations de succès et alertes d'erreur.
Stockage sécurisé
Utilisation d'expo-secure-store pour les tokens, pourquoi AsyncStorage est dangereux pour les données sensibles, et mécanismes de stockage par plateforme.