Une startup du secteur de la santé peut passer des mois à concevoir un flux mobile sécurisé, pour découvrir ensuite que le téléphone d’un testeur jailbreaké a exposé des dossiers de patients via des captures d’écran et des caches locaux. Dans le même temps, un build de debug du panneau d’administration Electron de l’équipe pourrait être livré avec une clé API intégrée dans son bundle. Les deux incidents impliquent le chiffrement, mais aucun ne se résout en ajoutant une simple bibliothèque de chiffrement.
Le chiffrement d’app est un ensemble de décisions. Les équipes doivent décider comment les données sont protégées au repos, comment elles circulent entre les systèmes, où sont stockées les clés, ce qu’un attaquant peut apprendre du package applicatif, comment le runtime réagit aux tentatives de manipulation et comment les mises à jour signées préservent ces garanties. Un bon point de départ est un checklist de sécurité OTA pour les apps Capacitor qui cartographie les données sensibles, les frontières de confiance, les capacités du client et les vecteurs d’abus probables.
Les applications mobiles et cross-platform évoluent dans un environnement particulièrement exposé. Les appareils sortent du bureau, les builds peuvent être copiés ou installés en sideload, les fichiers locaux peuvent être inspectés et les outils de reverse engineering sont largement disponibles. Les sections ci-dessous construisent le modèl’étape par étape, du stockage et du transport à la protection des clés par la plateforme, la confidentialité côté client, la conformité et les opérations de release.
Table des matières
- Pourquoi le chiffrement d’app est plus important que jamais
- Chiffrement au repos ou en transit
- Protéger Code, les données et les secrets dans l'app
- Considérations par plateforme pour iOS, Android, Capacitor et Electron
- Gestion des clés et limites du secret côté client
- Implications réglementaires et de conformité
- Erreurs courantes et bonnes pratiques renforcées
- Synthèse de votre plan de chiffrement
Why App Encryption Matters More Than Ever
Une application web conserve généralement une grande partie de sa logique sensible et de ses secrets sur une infrastructure contrôlée par l'organisation. Une application mobile envoie code, des assets, de la configuration et de la logique de traitement des données vers un appareil qui appartient à quelqu'un d'autre. Une application Electron a le même problème, car son JavaScript, ses ressources et ses fichiers packagés peuvent être inspectés par un utilisateur qui peut lancer l'application.
Cela déplace la frontière de la sécurité. Le client est utile, mais ce n'est pas un coffre-fort. Le chiffrement peut protéger les informations d'une inspection superficielle et rendre les fichiers volés moins exploitables, mais l'app aura toujours besoin d'accéder au texte en clair à un moment donné. Un attaquant qui contrôle l'appareil peut observer les entrées, inspecter la mémoire, instrumenter les API ou modifier l'exécution.
Prenons l'exemple de la santé. Chiffrer une base de données peut protéger les enregistrements copiés depuis le disque, mais cela n'empêchera pas un runtime compromis d'afficher des données déchiffrées à un processus malveillant. Chiffrer le trafic réseau peut protéger la requête d'un clinicien pendant son trajet vers le backend, mais cela ne protégera pas un export local une fois que l'app l'a sauvegardé dans un cache non protégé. Une clé cachée dans du JavaScript minifié reste récupérable si l'application doit l'utiliser.
Règle pratique : Considérez chaque protection côté client comme une couche qui réduit l'exposition, et non comme une preuve que l'appareil est fiable.
Une conception complète combine généralement :
- Protection des données au repos, pour les bases de données, fichiers, caches, préférences et documents téléchargés.
- Protection des données en transit, pour les requêtes, la synchronisation, la livraison des mises à jour et la communication inter-services.
- Stockage des clés par la plateforme, afin que les clés de chiffrement ne restent pas dans des fichiers d'application ordinaires.
- Code et protections au runtime, incluant l'obfuscation, les contrôles d'intégrité, les mesures anti-débogage et la validation appropriée des certificats.
- Un canal de mise à jour contrôlé, car une release signée doit préserver les hypothèses de sécurité intégrées aux versions précédentes.
- Contrôles de conformité documentés, incluant les responsabilités, les preuves, la surveillance et les procédures de réponse.
Les obligations réglementaires ajoutent de la pression, mais elles renforcent aussi la discipline d’ingénierie. Le RGPD, HIPAA, PCI DSS et SOC 2 ne transforment pas le chiffrement en une case à cocher universelle. Ils exigent des équipes qu’elles comprennent ce qu’elles protègent, comment les clés sont contrôlées et comment elles peuvent démontrer que les mesures de sécurité fonctionnent comme prévu.
Chiffrement au repos ou en transit
Pensez à un document confidentiel envoyé en recommandé. L’enveloppe scellée protège le message pendant qu’il circule d’une personne à l’autre. Une fois que le destinataire l’a ouvert, le document a toujours besoin d’un classeur verrouillé. Le chiffrement en transit protège les déplacements. Le chiffrement au repos protège le stockage. L’enveloppe et le classeur répondent à des problèmes différents.
Chiffrement au repos
Le chiffrement au repos s’applique lorsque les données se trouvent sur un appareil, un disque de serveur, une sauvegarde, une base de données ou un volume amovible. Sur les plateformes mobiles, les protections du système d’exploitation peuvent chiffrer automatiquement certaines parties de l’appareil, mais votre application doit toujours choisir des emplacements de stockage sûrs, des contrôles d’accès et une utilisation appropriée des clés. Les fichiers sensibles de l’application doivent utiliser la cryptographie prise en charge par la plateforme et des clés conservées dans des stockages protégés, plutôt qu’une clé écrite à côté des données chiffrées.
Le chiffrement authentifié est essentiel ici. OWASP recommande d’utiliser les API cryptographiques de la plateforme, le stockage des clés sur matériel si disponible, et des modes authentifiés tels que AES-GCM ou AES-CCM, qui aident à détecter toute altération tout en masquant le contenu. Les mêmes recommandations préconisent de protéger les données sensibles au repos comme en transit, de placer les données privées dans le stockage interne et d’éviter les algorithmes cryptographiques propriétaires au profit des implémentations de la plateforme (Feuille de triche de sécurité des applications mobiles OWASP).
Les détails pratiques varient selon la plateforme. iOS propose Data Protection et les services Keychain. Android offre des options basées sur Keystore et des bibliothèques qui peuvent aider à gérer les fichiers chiffrés. Les applications de bureau s’appuient davantage sur les identifiants du système d’exploitation et les contrôles d’accès locaux. Les équipes travaillant avec des fichiers dans un environnement Chromium Embedded Framework peuvent également consulter les bonnes pratiques pour le stockage de documents CEF afin d’examiner les limites de stockage au-delà du chiffrement lui-même.
Chiffrement en transit
Le chiffrement en transit protège les requêtes et les réponses lorsqu’elles traversent les réseaux. Une connexion TLS correctement configurée aide à empêcher un intermédiaire de lire ou de modifier le trafic de l’application, mais le TLS ne fonctionne que si le client valide correctement le serveur et que le backend présente un certificat de confiance. Une vérification de certificat désactivée, un repli non sécurisé ou un point d’accès en clair accidentel peuvent compromettre la protection prévue.
Le pinning de certificats peut ajouter une couche de vérification supplémentaire dans certains scénarios mobiles, en particulier lorsque l’équipe contrôle les opérations de certificats et dispose d’un plan de récupération pour la rotation. Ce n’est pas un remplacement pour un TLS correct, et un pin incorrect peut bloquer des utilisateurs légitimes. Les équipes qui développent avec Capacitor peuvent examiner le SSL pinning pour les applications Capacitor avant de choisir si les compromis opérationnels conviennent à leur application.
Les modes de défaillance sont complémentaires. La sécurité du transport ne protégera pas une base de données copiée depuis un appareil perdu. Le chiffrement du stockage ne protégera pas un mot de passe soumis via une connexion compromise. Concevez les deux chemins, puis testez les points où le texte en clair apparaît, y compris les logs, les captures d’écran, les fichiers temporaires, les rapports de crash, le contenu du presse-papiers et les files de synchronisation.
Protéger Code, les données et les secrets dans l'app
Les équipes utilisent souvent les mots « chiffrement », « obfuscation » et « durcissement » comme s’ils décrivaient le même contrôle. Ce n’est pas le cas. Chacun traite une action d’attaquant différente, et les confondre crée une fausse confiance.
Obfuscation et minification rendre code plus difficile à lire. Ils peuvent augmenter le coût de la duplication d'une application ou de la compréhension de la logique métier, mais ils ne rendent pas un secret inaccessible à une application qui doit l'utiliser. Une clé API dans un bundle JavaScript, une information d'authentification dans une archive ou une valeur reconstruite par une fonction prévisible peut toujours être extraite. Bytecode Hermes et Electron asar les archives peuvent être moins pratiques à inspecter que les fichiers sources, mais le packaging n'est pas synonyme de confidentialité.
Chiffrement des données protège le contenu de l'utilisateur et les identifiants locaux lors du stockage. Il doit utiliser les API cryptographiques de la plateforme et des clés conservées dans le Keychain, le Keystore, Secure Enclave, StrongBox ou un mécanisme équivalent du système d'exploitation lorsqu'il est disponible. Les recommandations de test de cryptographie de l'OWASP mettent en garde contre le placement de mots de passe ou de clés dans le code source et soulignent que les secrets qui restent côté client peuvent être extraits (Tests de cryptographie OWASP MASTG).
Protections au runtime recherchez les conditions qui augmentent la probabilité de falsification ou d'abus automatisés. Les signaux de jailbreak et de root, la détection de debugger, les contrôles d'intégrité de l'application, l'attestation et la validation de certificat peuvent rendre les attaques plus difficiles ou fournir un signal de réponse. Aucun de ces éléments ne rend un appareil fiable. Un attaquant déterminé peut modifier les contrôles, et un utilisateur légitime peut déclencher une heuristique.
| Couche de protection | Ce qu'il sécurise | Ce qu'il n'empêche pas |
|---|---|---|
| obfuscation de Code | Lisibilité et clonage facile de la logique applicative | Extraction des secrets auxquels l'app peut accéder |
| Chiffrement des données | Confidentialité et intégrité des données stockées sélectionnées | Exposition en clair après un déchiffrement légitime |
| Protections au runtime | Certains cas de tampering, de debugging et d'abus automatisés | Un attaquant expérimenté qui contrôle le runtime |
Une conception plus sûre conserve les secrets à forte valeur sur le serveur, fournit au client des identifiants à portée limitée et ne chiffre que les données locales nécessitant un accès hors ligne. Le stockage des tokens mérite son propre examen concernant l'expiration, la révocation, le comportement de refresh et la liaison à la plateforme. Le guide de stockage sécurisé des tokens pour les développeurs mobiles est utile pour transformer ces décisions en exigences d'implémentation.
Les approches naïves échouent parce qu'elles protègent l'illusion du secret plutôt que son cycle de vie. Appliquer un XOR à une valeur dans le code source, répartir une clé sur plusieurs fichiers ou se reposer sur la minification JavaScript ne change rien au fait que l'application en cours d'exécution doit reconstruire et utiliser la valeur.
Considérations par plateforme pour iOS, Android, Capacitor et Electron
Une même conception de chiffrement se comporte différemment selon les runtimes, car chaque plateforme expose des keystores, des API, des frontières d'isolation et des mécanismes de récupération différents. Une abstraction multiplateforme peut simplifier le code de l'application, mais elle ne peut pas effacer ces différences.
Plateformes mobiles natives
Sur iOS, le Keychain offre un stockage sécurisé des identifiants, tandis que Secure Enclave peut isoler certaines opérations de clés du processeur principal de l’application. L’application doit néanmoins définir des contrôles d’accès adaptés à ses exigences d’utilisabilité, par exemple si les données doivent rester accessibles après l’authentification de l’appareil ou uniquement lorsque l’utilisateur s’est authentifié.
Android Keystore fournit un chemin sécurisé par le matériel sur les appareils pris en charge, et StrongBox peut offrir un environnement isolé plus robuste lorsqu’il est disponible. Les équipes Android doivent également prendre en compte les capacités de l’appareil, le comportement de sauvegarde, les exigences d’authentification et les signaux d’attestation. Le support matériel n’étant pas uniforme, l’application doit prévoir une politique de repli définie plutôt que de supposer que chaque appareil offre une protection identique.
Shells cross-platform
Les applications Capacitor combinent le code web et les capacités natives des plateformes via un pont. Ce pont constitue une frontière de sécurité, et non une simple couche de commodité. localStorage, IndexedDB et les préférences web ordinaires ne doivent pas être considérés par défaut comme des magasins de secrets chiffrés. L’équipe doit explicitement choisir un plugin de stockage natif ou implémenter un module natif utilisant les services de clés protégés de la plateforme.
Electron a un modèle de menaces différent. Son renderer gère le contenu web, tandis que le processus principal dispose de privilèges plus étendus, il est donc préférable de ne pas exposer les opérations sensibles au renderer. Electron’s safeStorage peut utiliser la protection des identifiants du système d’exploitation, mais la sécurité résultante dépend du système d’exploitation hôte, du compte utilisateur, de la configuration du bureau et de l’isolation des processus. La clé n’est pas isolée matériellement de manière automatique, contrairement à ce que peut faire une plateforme mobile pour une clé protégée.
| Plateforme | Stockage des clés | Chiffrement API | Modèle de menaces par défaut |
|---|---|---|---|
| iOS | Keychain et, si pris en charge, Secure Enclave | Cryptographie de la plateforme Apple et Data Protection | L’appareil et l’application sont distincts, mais un appareil ou un runtime compromis peut observer l’utilisation |
| Android | Keystore et, si pris en charge, StrongBox | Cryptographie de la plateforme Android et composants de sécurité Jetpack | Les capacités matérielles et logicielles varient selon l’appareil |
| Capacitor | Stockage natif choisi via des plugins ou un bridge personnalisé code | API Web et API de la plateforme native | Les assets Web s’exécutent dans un shell natif et n’héritent pas automatiquement du stockage sécurisé |
| Electron | OS credential facilities through APIs such as safeStorage |
API d’application compatibles Node et Chromium | L’exposition du renderer et l’accès au niveau hôte sont des enjeux majeurs |
Les équipes doivent documenter le comportement par cible plutôt que de décrire le produit comme « chiffré sur toutes les plateformes ». Le approche Capacitor des différences de plateforme permet de présenter le bridge comme un lieu où les décisions spécifiques à la plateforme doivent rester visibles.
Gestion des clés et limites du secret côté client
L'encryption ne protège les données que si la gestion des clés protège les clés elles-mêmes. Un cycle de vie efficace comporte cinq étapes : génération, distribution, stockage, rotation et révocation. Chaque étape présente un mode de défaillance différent.
Générez les clés avec des API cryptographiques de plateforme ou de serveur de confiance. Distribuez-les via un protocole authentifié plutôt que de les intégrer dans un bundle. Stockez-les dans un espace protégé de la plateforme quand c'est possible. Effectuez leur rotation lorsque la politique, le risque ou les exigences cryptographiques l'exigent. Révoquez l'accès via une autorisation contrôlée par le serveur lorsqu'un appareil, un compte ou une session ne doit plus pouvoir déchiffrer de données.
Le client est moins robuste que l'infrastructure pour ces opérations, car l'utilisateur contrôle l'appareil et peut potentiellement inspecter l'état de l'application. Une clé détenue par le client peut être pertinente pour des données hors ligne protégées par une phrase secrète dérivée par l'utilisateur, à condition que le produit accepte les conséquences en matière de récupération et d'ergonomie. Cela a beaucoup moins de sens pour un token API qui accorde un large accès au backend. Si un attaquant extrait ce token, le chiffrement d'une base de données locale ne limitera pas ce que le token peut faire à distance.
Le chiffrement par enveloppe sépare la clé de chiffrement des données de la clé maîtresse. L’application peut chiffrer un objet local avec une clé de données à durée de vie courte, tandis qu’un service de gestion des clés côté serveur ou un système adossé à un HSM protège la clé d’enveloppe. Une conception de libération de clé à distance peut exiger un appareil authentifié, un utilisateur, une décision de politique ou un signal d’attestation avant de libérer le matériel nécessaire au déchiffrement. Ces modèles ne rendent pas un client compromis sûr, mais ils réduisent l’autorité qui réside de manière permanente sur l’appareil.
OWASP identifie les données sensibles locales comme incluant les informations personnellement identifiables, le matériel cryptographique, les secrets et les clés API. Il associe également le chiffrement à des contrôles de cycle de vie tels que le stockage local sécurisé, la rotation des clés et la zéroïsation après utilisation. Le principe architectural est simple :
Conservez les secrets de haute valeur sur des systèmes que l’équipe contrôle. Accordez au client uniquement l’autorité minimale requise pour sa tâche actuelle.
Pour les systèmes de release, la gestion des clés s’applique également à la signature et à la livraison des mises à jour. Une équipe doit définir qui peut signer un bundle, où résident les identifiants de signature, comment l’accès est audité et comment un identifiant de signature compromis est remplacé. Des conseils sur Sécuriser les mises à jour OTA grâce à la gestion des clés peuvent aider à relier le chiffrement de l’application au cycle de vie des mises à jour.
Implications réglementaires et de conformité
Les équipes de conformité n'acceptent généralement pas l'affirmation « l'application utilise le chiffrement » comme preuve suffisante. Elles demandent quelles données sont couvertes, quels algorithmes et protocoles sont actifs, qui contrôle les clés, comment l'accès est restreint et comment l'organisation détecte la dérive de configuration.
L'article 32 du RGPD considère le chiffrement comme une mesure technique appropriée pour réduire les risques, comme le reflète le texte du RGPD de l'Union européenne. L'obligation est fondée sur le risque : l'organisation doit donc relier ses mesures de protection à la nature des données personnelles et à l'environnement de traitement. Une application mobile qui traite des informations médicales, des données d'identité ou des dossiers financiers a besoin d'une explication défendable sur le stockage local, le transport, l'accès et la réponse aux incidents.
La règle de sécurité de HIPAA traite le chiffrement des informations de santé protégées électroniques comme une mesure de protection « adressable » plutôt que comme une case à cocher technique universelle. Cela signifie qu'une entité couverte ou un partenaire commercial doit évaluer si le chiffrement est raisonnable et approprié, documenter la décision et appliquer des mesures alternatives s'il ne met pas en œuvre cette protection. Les directives de la règle de sécurité du HHS fournissent le contexte de référence.
La norme PCI DSS distingue les données de titulaire de carte stockées de leur transmission sur des réseaux ouverts. Les équipes doivent rattacher les décisions de chiffrement aux exigences applicables et éviter de stocker inutilement des données de paiement. La bibliothèque de documents du PCI Security Standards Council est l'endroit approprié pour vérifier la formulation et le périmètre actuels.
Les auditeurs SOC 2 se concentrent sur les preuves que les contrôles fonctionnent. Ces preuves peuvent inclure les politiques de gestion des clés, les configurations TLS, les inventaires de chiffrements, les logs d’accès, les approbations de modifications, les registres d’incidents, les résultats de tests et la preuve que les releases signées suivent le processus prévu. Un contrôle documenté sans surveillance peut ne pas démontrer un fonctionnement efficace.
Le fil conducteur est la prouvabilité. Construisez la piste d’audit dès la mise en place du chiffrement de l’application, pas la semaine avant l’audit.
Erreurs courantes et bonnes pratiques renforcées
La plupart des échecs de chiffrement commencent par des décisions d’ingénierie ordinaires. Un développeur a besoin d’un token disponible au démarrage, une équipe veut que la recherche hors ligne soit rapide, ou un processus de release a besoin d’un moyen rapide de distribuer un hotfix. Le risque apparaît lorsque le raccourci devient une partie permanente du modèle de confiance.
Une étude récente sur les risques mobiles a rapporté que plus de 60 % des applications évaluées utilisaient un chiffrement non sécurisé ou obsolète pour les données sensibles, tandis que environ un tiers réutilisait des vecteurs d’initialisation et 20 % utilisaient des valeurs statiques codées en dur. Ces résultats déplacent la question de « l’application chiffre-t-elle ? » vers « l’implémentation peut-elle préserver la confidentialité et l’intégrité en conditions réelles ? » (SC World report on mobile app risks)
| Erreur courante | Bonne pratique |
|---|---|
| Coder en dur les clés API ou les clés de chiffrement dans le code source, le bytecode ou les bundles | Gardez les identifiants sensibles côté serveur et utilisez le stockage sécurisé de la plateforme pour les données liées à l’appareil |
| Chiffrer une base SQLite tout en laissant des caches, exports, logs ou sauvegardes en clair | Inventorier chaque copie de données sensibles et appliquer la même politique de stockage aux artefacts temporaires |
| Stocker les refresh tokens dans un stockage web standard | Utilisez le stockage de credentials natif, restreignez la portée des tokens et gérez la révocation côté serveur |
| Écrire sa propre cryptographie ou inventer une obfuscation de clés | Utilisez des API de plateforme éprouvées et des modes de chiffrement authentifiés |
| Désactiver la validation des certificats pour résoudre des problèmes de connectivité | Configurez correctement le TLS, puis évaluez le pinning avec un processus de récupération testé |
| Traiter la minification comme une protection des secrets | Supprimez les secrets du client code et utilisez l'obfuscation uniquement pour augmenter le coût de la rétro-ingénierie |
| Omettre les contrôles d'intégrité de l'app et les signaux d'attestation | Validez l'identité de la release le cas échéant et utilisez ces signaux pour ajuster l'accès ou déclencher une revue |
| Autoriser des mises à jour non signées ou mal contrôlées | Signez les artefacts de release, protégez vos identifiants de signature et surveillez le résultat des mises à jour |
Un autre rapport sur les menaces décrit des groupes de spyware ciblant des comptes Signal et WhatsApp en usurpant des applications et en exploitant les téléphones sous-jacents. Ce même rapport cite une évaluation des menaces mobiles dans laquelle Les attaques sur smartphones Android ont augmenté de 29 % au S1 2025 par rapport au S1 2024 (La couverture par The Register des rapports liés à la CISA). La leçon n’est pas que le chiffrement a échoué. Les attaquants ciblent souvent l’appareil, le compte, la session ou le chemin de mise à jour, car ces couches peuvent contourner le texte chiffré protégé.
Transformez chaque pratique de durcissement en règle de release automatisée. La CI peut rejeter les motifs de secrets connus, signaler les implémentations cryptographiques personnalisées code, vérifier les étapes de signature, inspecter le contenu du bundle et exiger une revue de sécurité lorsque les paramètres de stockage ou de transport changent. L’objectif est de détecter une mauvaise décision avant qu’elle ne devienne une dépendance déployée.
Synthèse de votre plan de chiffrement
Un plan de chiffrement doit se lire comme un contrat d’ingénierie. Il doit préciser ce que l’application protège, où se trouvent les clés, quels composants peuvent voir le texte en clair, et comment l’équipe prouve que les contrôles restent actifs après chaque release.
Commencez par classification des données. Classez les enregistrements, tokens, documents, logs, caches, sauvegardes et champs d’analyse selon la sensibilité et les besoins de rétention. Minimisez les copies locales avant de choisir un algorithme. Les données qui n’atteignent jamais l’appareil n’ont pas besoin d’une conception de stockage sur appareil.
Documentez ensuite les décisions de stockage et de transport :
- Schéma au repos : Choisissez le chiffrement authentifié, le stockage des clés géré par la plateforme, les emplacements de fichiers protégés, le comportement de sauvegarde et la gestion de la suppression ou de la zéroisation.
- Protocole en transit : Définissez la configuration TLS, la validation des certificats, la politique des endpoints et si le pinning est adapté au modèle de menace.
- Conservation des clés : Documentez les procédures de génération, d'accès, de distribution, de rotation, de révocation, de récupération et de remplacement d'urgence.
- Code et contrôles runtime : Décidez quelles protections d'obfuscation, de vérification d'intégrité, d'attestation, de détection de debugger et d'écrans sensibles sont nécessaires.
- Preuves d'audit : Capturez les inventaires de configuration, les logs d'accès, les approbations de release, les résultats de tests, les rapports d'incidents et les exceptions.
L'ordre compte. La classification des données détermine ce qui doit être protégé. Cette décision façonne le stockage et la conservation des clés. Les contrôles de transport et de mise à jour préservent ensuite le chemin entre les services de confiance et le client. Les équipes Capacitor et Electron doivent refaire cet examen pour chaque cible, car un keystore iOS natif, une option Android adossée au matériel, un API de stockage navigateur et un gestionnaire d'identifiants desktop n'offrent pas les mêmes garanties.
Le canal de mise à jour fait partie de ce plan, il ne vient pas après. Une release signée peut préserver l'intégrité de code, tandis qu'un ciblage contrôlé, la protection contre le rollback et l'observabilité des releases aident l'équipe à réagir lorsqu'un build ou une configuration vulnérable atteint les utilisateurs. Revoyez le plan dès que l'app ajoute des données hors ligne, change de plugin de stockage, introduit une nouvelle permission backend ou modifie la façon dont les mises à jour sont signées et livrées.
Capgo fournit des live updates signées pour les applications CapacitorJS et Electron, avec prise en charge des bundles chiffrés pour le JavaScript code et les assets, des canaux de release contrôlés, une protection contre le rollback et une observabilité des mises à jour par appareil. Visitez Capgo pour évaluer comment un chemin de mise à jour contrôlé peut soutenir votre plan de chiffrement d’app et de gouvernance des releases.
