Un startup sanitario può trascorrere mesi a progettare un flusso di lavoro mobile sicuro, scoprendo poi che un tester con un telefono jailbroken ha esposto i record dei pazienti attraverso screenshot e cache locali. Allo stesso tempo, un build di debug del pannello di amministrazione del team Electron potrebbe essere spedito con una chiave API incorporata nel suo pacchetto. Entrambi gli incidenti coinvolgono l'encryptazione, ma nessuno è risolto aggiungendo una libreria di encryptazione.
L'encryptazione degli app è un sistema di decisioni. Gli squadre devono decidere come proteggere i dati mentre sono archiviati, come muoverli tra sistemi, dove vivono le chiavi, cosa un attaccante può imparare dal pacchetto dell'applicazione, come il runtime risponde alla manipolazione e come gli aggiornamenti firmati preservano quelle garanzie. Un punto di partenza utile è un valutazione del rischio dell'applicazione che mappa dati sensibili, confini di fiducia, capacità del client e percorsi di abuso probabili.
Gli applicativi mobili e cross-platform affrontano un ambiente particolarmente esposto. I dispositivi lasciano l'ufficio, i build possono essere copiati o caricati lateralmente, i file locali possono essere ispezionati e gli strumenti di reverse-engineering sono ampiamente disponibili. Le sezioni che seguono costruiscono il modello passo dopo passo, dallo storage e dal trasporto alla protezione delle chiavi del sistema, alla segretezza dei client, alla conformità e alle operazioni di rilascio.
Elenco dei Contenuti
- Perché la Crittografia delle App è Più Importante che Mai
- L'encryptazione in Recesso Versus in Trasferimento
- Proteggere Code, i dati e i segreti nell'app
- Considerazioni di piattaforma per iOS, Android, Capacitor, e Electron
- Gestione delle chiavi e i limiti della segretezza client-side
- Implicazioni regolatorie e di conformità
- Trappole comuni e migliori pratiche rafforzate
- Mettere tutto insieme nel tuo piano di cifratura
Perché la cifratura dell'app è più importante che mai
Una applicazione web mantiene di solito gran parte della sua logica sensibile e del materiale segreto su infrastrutture che l'organizzazione controlla. Un'app mobile invia code, risorse, configurazione e logica di gestione dei dati su un dispositivo che appartiene a qualcun altro. Un'app Electron ha un problema simile, perché il suo JavaScript, risorse e file pacchettati possono essere ispezionati da un utente che può eseguire l'applicazione.
Questo cambia il confine di sicurezza. La client è utile, ma non è un deposito. La crittografia può proteggere l'informazione da ispezioni casuali e rendere meno utili i file rubati, ma l'applicazione ha ancora bisogno di accesso al testo in chiaro in alcuni punti. Un attaccante che controlla il dispositivo può osservare gli input, ispezionare la memoria, strumentare le API o modificare l'esecuzione.
Considera l'esempio sanitario. Crittografare un database può proteggere i registri copiati da disco, ma non fermerebbe un runtime compromesso che mostra i registri decrittografati a un processo malintenzionato. Crittografare il traffico di rete può proteggere la richiesta di un clinico mentre si sposta verso il backend, ma non protegge l'esportazione locale dopo che l'app salva i dati in un cache non protetto. Una chiave nascosta nel JavaScript minificato rimane recuperabile se l'applicazione deve usarla.
Regola pratica: Tratta ogni protezione client-side come un layer che riduce l'esposizione, non come una prova che il dispositivo è affidabile.
Un design completo normalmente combina:
- La protezione a riposo, per database, file, cache, preferenze e documenti scaricati.
- La protezione in transito, per richieste, sincronizzazione, invio di aggiornamenti e comunicazione servizio-servizio.
- La memorizzazione delle chiavi di piattaformaCosì le chiavi di crittografia non rimangono nelle file di applicazione ordinarie.
- Code e protezioni di runtimeInclusi l'obfuscamento, le verifiche di integrità, le misure anti-debug e la validazione dei certificati appropriati.
- Un canale di aggiornamento controllatoperché una versione rilasciata firmata deve preservare le ipotesi di sicurezza costruite nelle versioni precedenti.
- Controlli di conformità documentatitra cui proprietà, prove, monitoraggio e procedure di risposta.
Le obbligazioni regolamentari aumentano la pressione, ma migliorano anche la disciplina ingegneristica. GDPR, HIPAA, PCI DSS e SOC 2 non trasformano l'encryption in un casellario universale. Richiedono ai team di capire cosa si protegge, come sono controllate le chiavi e come possono dimostrare che i dispositivi di sicurezza funzionano come previsto.
L'encryption in riposo Versus in Trasmissione
Pensate a un documento confidenziale inviato per posta certificata. La busta sigillata protegge il messaggio mentre viaggia tra le persone. Una volta che il destinatario l'apre, il documento ancora ha bisogno di un armadio chiuso a chiave. L'encryption in trasmissione protegge il movimento. L'encryption in riposo protegge lo storage. L'invio e il cassetto risolvono problemi diversi.
L'encryption in riposo
L'encryption in riposo si applica quando i dati sono in attesa su un dispositivo, un disco server, un backup, una banca dati o un volume rimovibile. Su piattaforme mobili, le protezioni del sistema operativo possono cifrare automaticamente parti del dispositivo, ma l'applicazione deve comunque scegliere locazioni di archiviazione sicure, controlli di accesso e utilizzo delle chiavi. I file di applicazione sensibili dovrebbero utilizzare la crittografia supportata dalla piattaforma e le chiavi tenute in archivi protetti, piuttosto che una chiave scritta accanto ai dati cifrati.
Crittografia autenticata è importante qui. OWASP raccomanda API di crittografia del platform, archiviazione di chiavi supportate da hardware quando disponibili, e modalità autenticate come AES-GCM o AES-CCM, che aiutano a rilevare eventuali tentativi di manipolazione e a nascondere il contenuto. Lo stesso consiglio raccomanda di proteggere i dati sensibili sia in stato di riposo che in stato di trasferimento, di inserire i dati privati in archiviazione interna e di evitare l'uso di algoritmi criptografici proprietari a favore di implementazioni di piattaforma (La guida OWASP per la sicurezza delle applicazioni mobili).
Le informazioni pratiche differiscono a seconda della piattaforma. iOS fornisce servizi di protezione dei dati e di Keychain. Android fornisce opzioni e librerie basate su Keystore che possono aiutare a gestire file crittografati. Le applicazioni desktop dipendono più pesantemente dalle credenziali del sistema operativo e dai controlli di accesso locale. Le squadre che lavorano con file in un ambiente Chromium Embedded Framework possono anche esaminare le migliori pratiche per lo storage dei documenti CEF esaminare i confini di archiviazione al di là del cifrario stesso.
Crittografia in transito
In-transit encryption protegge le richieste e le risposte mentre attraversano le reti. Una configurazione TLS corretta aiuta a prevenire che un intermediario legga o modifichi il traffico dell'applicazione, ma il TLS funziona solo quando il client verifica correttamente il server e il backend presenta un certificato di fiducia. Se si disabilita la verifica del certificato, si utilizza un fallback pericoloso o si crea un endpoint di testo chiaro per errore, si può sminuire la protezione prevista.
La pinning del certificato può aggiungere un altro strato di verifica in scenari mobili selezionati, soprattutto quando il team controlla le operazioni di certificato e ha un piano di recupero per la rotazione. Non è una sostituzione per il TLS corretto, e un pin errato può bloccare gli utenti legittimi. Le squadre che utilizzano Capacitor possono esaminare La pinning SSL per le app Capacitor prima di decidere se gli scambi operativi si adattano alla loro applicazione.
Le modalità di fallimento sono complementari. La sicurezza di trasporto non protegge una copia del database da un dispositivo perso. L'encryption del storage non protegge una password inviata attraverso una connessione compromessa. Progettate entrambe le vie, quindi testate i punti in cui compare il testo chiaro, compresi i log, le schermate, i file temporanei, i rapporti di crash, il contenuto della clipboard e le code di sincronizzazione.
Proteggere Code, i dati e i segreti nell'app
Le squadre spesso utilizzano le parole 'encryption', 'obfuscation' e 'hardening' come se descrivessero lo stesso controllo. Non è così. Ognuno di loro affronta un'azione diversa dell'attaccante, e confonderli crea una falsa fiducia.
L'obfuscation e la minificazione renda code più difficile da leggere. Possono aumentare il costo di clonare un'applicazione o comprendere la logica di business, ma non rendono un segreto inaccessibile a un'applicazione che deve utilizzarlo. Una chiave API in un bundle JavaScript, un credenziale di firma in un archivio, o un valore ricostruito da una funzione predittiva può ancora essere estratto. Il bytecode Hermes e Electron asar gli archivi possono essere meno comodi da esaminare rispetto ai file di origine, ma la packaging non è la stessa cosa della segretezza.
La crittografia dei dati proteggono il contenuto degli utenti e le credenziali locali mentre sono memorizzati. Dovrebbe utilizzare le API crittografiche della piattaforma e le chiavi conservate nella Keychain, Keystore, Secure Enclave, StrongBox o un'equivalente facoltà del sistema operativo dove disponibile. La guida di OWASP per il testing crittografico avverte contro l'inserimento di password o chiavi nei file di origine code e sottolinea che i segreti rimasti sul client possono essere estratti (Crittografia di OWASP MASTG).
Le protezioni in esecuzione cerca di individuare le condizioni che aumentano la probabilità di tampering o abuso automatizzato. I segnali di jailbreak e root, la detezione del debugger, le verifiche di integrità dell'applicazione, l'attestazione e la validazione del certificato possono rendere gli attacchi più difficili o fornire un segnale di risposta. Nessuna rende un dispositivo affidabile. Un attaccante determinato può modificare le verifiche, e un utente legittimo può attivare un heuristico.
| Layer di protezione | Cosa protegge | Cosa non blocca |
|---|---|---|
| L'Code obfuscation | La lettura e la clonazione casuale della logica dell'applicazione | Estrazione dei segreti che l'app può accedere |
| Crittografia dei dati | Confidentialità e integrità dei dati archiviati selezionati | Esposizione di testo puro dopo decrittazione legittima |
| Protezioni in esecuzione | Alcune manipolazioni, debug e abusi automatizzati | Un attaccante esperto che controlla l'esecuzione |
Un design più sicuro mantiene i segreti di alto valore sul server, fornisce al client credenziali ristrette e crittografa solo i dati locali che richiedono l'accesso offline. La gestione dei token merita una propria revisione delle scadenze, della revoca, del comportamento di aggiornamento e della legatura al sistema operativo. Il Guida alla sicurezza dei token per gli sviluppatori di applicazioni mobili sono utili quando si trasformano quelle decisioni in requisiti di implementazione.
Le approcci ingenui falliscono perché proteggono l'aspetto della segretezza piuttosto che il ciclo di vita del segreto. XOR-ando un valore in code, suddividendo una chiave in più file o affidandosi alla minificazione del JavaScript non cambia il fatto che l'applicazione in esecuzione debba ricostruire e utilizzare il valore.
Considerazioni relative alla piattaforma per iOS, Android, Capacitor, e Electron
Lo stesso design di crittografia si comporta in modo diverso tra i runtime a causa di ogni piattaforma che esporre diverse archiviazioni di chiavi, API, confini di isolamento e meccanismi di ripristino. Una astrazione cross-platform può semplificare l'applicazione code, ma non può cancellare quelle differenze.
Piattaforme mobili native
Sui dispositivi iOS, il Keychain fornisce un archivio di credenziali protette, mentre Enclave di Sicurezza può isolare certe operazioni di chiave dal processore di applicazione principale. L'applicazione deve comunque selezionare controlli di accesso che corrispondano ai requisiti di usabilità, come ad esempio se i dati dovrebbero essere disponibili dopo l'autenticazione del dispositivo o solo quando l'utente si è autenticato.
Android Keystore fornisce un percorso supportato da hardware su dispositivi supportati, e StrongBox può offrire un ambiente isolato più forte dove disponibile. Le squadre Android dovrebbero anche considerare le capacità del dispositivo, il comportamento di backup, i requisiti di autenticazione e i segnali di attestazione. La supporto hardware non è uniforme, quindi l'applicazione ha bisogno di una politica di fallback definita piuttosto che assumere che ogni dispositivo offra una protezione identica.
Scheletri cross-platform
Applicazioni Capacitor combinano web code con funzionalità native di piattaforma attraverso un ponte. Quel ponte è un confine di sicurezza, non solo un layer di comodità. localStorage, IndexedDB e le preferenze web ordinarie non dovrebbero essere trattate come archivi di segreti crittografati per impostazione predefinita. Una squadra deve scegliere esplicitamente un plugin di archiviazione nativa o implementare un modulo nativo che utilizza le facciate di chiave protette della piattaforma.
Elettron ha un modello di minaccia diverso. Il suo renderer gestisce il contenuto web, mentre il processo principale ha privilegi più ampi, quindi le operazioni sensibili dovrebbero rimanere fuori da un renderer esposto. Elettron safeStorage può utilizzare la protezione delle credenziali del sistema operativo, ma la sicurezza risultante dipende dal sistema operativo host, dal conto utente, dalla configurazione del desktop e dall'isolamento del processo. La chiave non è automaticamente isolata in hardware nello stesso modo in cui una piattaforma mobile può isolare una chiave protetta.
| Piattaforma | Key Storage | Crittografia API | Modello di minaccia predefinito |
|---|---|---|---|
| iOS | Keychain e, ove supportato, Secure Enclave | Crittografia della piattaforma Apple e Protezione dei dati | Dispositivo e app sono separati, ma un dispositivo o un runtime compromessi possono osservare l'uso |
| Android | Keystore e, ove supportato, StrongBox | Crittografia della piattaforma Android e componenti di sicurezza di Jetpack | Il supporto hardware e software varia a seconda del dispositivo |
| Capacitor | Memoria nativa selezionata attraverso plugin o ponte personalizzata code | API web più API native della piattaforma | Risorse web eseguite all'interno di un shell nativo non ereditano automaticamente la memorizzazione sicura. |
| Electron | Le autorizzazioni del sistema tramite API safeStorage |
L'API applicazione compatibile con Node e Chromium | Esposizione del renderer e accesso a livello di host sono preoccupazioni centrali |
Le squadre dovrebbero documentare il comportamento per ogni piattaforma di destinazione, anziché descrivere il prodotto come "crittografato su tutte le piattaforme". approccio Capacitor alle differenze tra piattaforme aiuta a delineare il ponte come un luogo dove le decisioni specifiche della piattaforma devono rimanere visibili.
Gestione delle chiavi e i limiti della segretezza client-side
L'encryption protegge i dati solo quando la gestione delle chiavi protegge le chiavi. Un utile ciclo di vita ha cinque fasi: generazione, distribuzione, archiviazione, rotazione e revoca. Ogni fase crea un diverso modo di fallimento.
Genera le chiavi con API criptografiche di piattaforma o server affidabili. Distribuiscile attraverso un protocollo autenticato piuttosto che immetterle in un bundle. Archiviale in una struttura di piattaforma protetta quando possibile. Rota le chiavi quando la politica, il rischio o le esigenze criptografiche lo richiedono. Revoca l'accesso attraverso l'autorizzazione controllata dal server quando un dispositivo, un account o una sessione non dovrebbe più decrittare i dati.
Il client è più debole dell'infrastruttura per queste operazioni perché l'utente controlla il dispositivo e può potenzialmente ispezionare lo stato dell'applicazione. Una chiave tenuta dal client può avere senso per i dati offline protetti da una passphrase derivata dall'utente, a condizione che il prodotto accetti le conseguenze di recupero e di utilizzo. Ha molto meno senso per un token API che concede un accesso backend ampio. Se un attaccante estrae quel token, l'encryption intorno a un database locale non limita cosa il token può fare a distanza.
La crittografia dell'oggetto separa la chiave di crittografia dei dati dalla chiave principale. L'applicazione può crittografare un oggetto locale con una chiave di dati a breve durata, mentre un servizio di gestione delle chiavi a livello server o un sistema basato su HSM protegge la chiave di avvolgimento. Un design di rilascio di chiavi remote può richiedere un dispositivo autenticato, un utente, una decisione di politica o un segnale di attestazione prima di rilasciare i materiali necessari per la decrittografia. Questi pattern non rendono il client compromesso sicuro, ma riducono l'autorità che si trova permanentemente sul dispositivo.
L'OWASP identifica i dati sensibili locali come includenti informazioni personali identificative, materiali crittografici, segreti e API chiavi. Connette anche la crittografia con i controlli di ciclo di vita come lo storage locale sicuro, la rotazione delle chiavi e la zeroizzazione dopo l'uso. Il principio architettonico è chiaro:
Conserva i segreti di alto valore su sistemi controllati dal team. Dà al client solo l'autorità minima richiesta per la sua attività corrente.
For release systems, key management also applies to update signing and delivery. A team should define who can sign a bundle, where signing credentials reside, how access is audited, and how a compromised signing credential is replaced. Guidance on securing OTA updates with key management Può aiutare a collegare la crittografia dell'applicazione al ciclo di aggiornamento.
Implicazioni Regolamentari e di Conformità
Le team di compliance non accettano generalmente la dichiarazione "l'applicazione utilizza l'encryption" come prova sufficiente. Chiedono quali dati sono coperti, quali algoritmi e protocolli sono attivi, chi controlla le chiavi, come l'accesso è limitato e come l'organizzazione rileva la deriva della configurazione.
L'articolo 32 del GDPR considera l'encryption come una misura tecnica appropriata per ridurre il rischio, come riportato nel testo dell'Unione europea sul GDPR. L'obbligo è basato sul rischio, quindi l'organizzazione deve ancora collegare le sue misure di sicurezza alla natura dei dati personali e all'ambiente di elaborazione. Un'app mobile che gestisce informazioni mediche, dati di identità o registri finanziari ha bisogno di una spiegazione difendibile della memorizzazione locale, del trasporto, dell'accesso e della risposta agli incidenti.
La regola di sicurezza HIPAA considera l'encryption per i dati protetti di salute elettronici come un requisito di sicurezza gestibile piuttosto che un controllo tecnico universale. Ciò significa che un ente coperto o un associato commerciale dovrebbe valutare se l'encryption è ragionevole e appropriato, documentare la decisione e applicare misure alternative dove non implementa il requisito. La guida sulla sicurezza dell'HHS fornisce il contesto regolatorio.
Il PCI DSS separa i dati dei titolari di carte dai trasferimenti su reti aperte. Le team dovrebbero mappare le decisioni sull'encryption alle richieste applicabili e evitare di memorizzare i dati di pagamento inutilmente. La biblioteca dei documenti del Consiglio di sicurezza PCI è il luogo appropriato per verificare la formulazione e lo scopo correnti.
E i revisori SOC 2 si concentrano su prove che i controlli operino. Queste prove possono includere politiche di gestione delle chiavi, configurazioni TLS, inventari di cifre, registri di accesso, approvazioni di modifiche, registri di incidenti, risultati dei test e prove che le rilasci firmati seguano il processo previsto. Un controllo documentato senza monitoraggio potrebbe non dimostrare un'operazione efficace.
La comune trama è la provvabilità. Costruisci la traccia di prove mentre implementi la crittografia dell'app, non durante la settimana prima di un audit.
Comuni insidie e migliori pratiche rafforzate
La maggior parte delle fallite di crittografia inizia come decisioni di ingegneria ordinarie. Un sviluppatore ha bisogno di un token disponibile durante l'avvio, un team vuole una ricerca offline che si senta veloce o un processo di rilascio richiede un modo rapido per distribuire un hotfix. Il rischio appare quando lo shortcut diventa una parte permanente del modello di fiducia.
Un recente studio sui rischi mobili ha riferito che più del 60% degli app valutati utilizzavano crittografia in sicurezza o obsoleta per dati sensibilimentre circa un terzo ha riutilizzato vettori di inizializzazione e 20% utilizza valori statici hardcodedQueste scoperte spostano la domanda da “la app cifra?” a “la implementazione può preservare la riservatezza e l'integrità nell'uso reale?”Rapporto SC World sui rischi delle app mobili)
| Pitfall Comune | Pratica Affinata |
|---|---|
| Hardcodare le chiavi API o le chiavi di crittografia nei file sorgente, bytecode o bundle. | Conservare le credenziali di alto valore sul lato del server e utilizzare lo storage di piattaforma protetto per materiali di dispositivo |
| Cifrare un database SQLite lasciando cache, esportazioni, log o backup in testo piano | Elencare ogni copia di dati sensibili e applicare la stessa politica di archiviazione agli artefatti temporanei |
| Memorizzare i token di refresh nel storage web ordinario | Utilizzare la memorizzazione dei credenziali supportata dalla piattaforma, limitare lo scopo del token e supportare la revoca server-side |
| Scrivere crittografia personalizzata o inventare l'obfuscamento delle chiavi | Utilizzare API di piattaforme verificate e modalità di crittografia autenticate |
| Disabilitare la validazione dei certificati per risolvere gli issue di connessione | Configurare TLS correttamente, poi valutare la pinning con un processo di ripristino testato |
| Considerare la minificazione come protezione segreta | Eliminare i segreti dal client code e utilizzare l'obfuscation solo per aumentare il costo di reverse-engineering |
| Omettendo i controlli di integrità dell'app e i segnali di attestazione | Validare l'identità delle release dove appropriato e utilizzare i segnali per regolare l'accesso o attivare la revisione |
| Consentire aggiornamenti non firmati o debolmente controllati | Crittografa gli artefatti di rilascio, proteggi le credenziali di firma e monitora gli esiti degli aggiornamenti |
Un rapporto di minaccia separato descriveva squadre di spie che miravano ai conti Signal e WhatsApp falsificando le applicazioni e abusando dei telefoni sottostanti. Lo stesso rapporto citava una valutazione delle minacce mobili in cui Android smartphone attacks were up 29% in H1 2025 compared with H1 2024 (La copertura di The Register sull'articolo del CISALa lezione non è che l'encryption sia fallito. Gli attaccanti spesso scelgono il dispositivo, l'account, la sessione o il percorso dell'aggiornamento perché quei livelli possono bypassare il ciphertext protetto.
Trasforma ogni pratica rafforzata in una regola di rilascio automatizzato. Il CI può rifiutare i modelli di segreti noti, segnalare i passaggi di firma personalizzati code, verificare i passaggi di firma, ispezionare i contenuti dei bundle e richiedere una revisione di sicurezza quando cambiano le impostazioni di archiviazione o di trasporto. L'obiettivo è catturare una cattiva decisione prima che diventi una dipendenza consegnata.
Mettere tutto insieme nel tuo piano di encryption.
Un piano di encryption dovrebbe essere come un contratto di ingegneria. Deve dire cosa l'app protegge, dove vivono le chiavi, quali componenti possono vedere il testo in chiaro e come il team dimostra che i controlli rimangono attivi dopo ogni rilascio.
Inizia con la classificazione dei dati. Etichetta i record, i token, i documenti, i log, le cache, le copie di backup e i campi di analisi secondo la sensibilità e le esigenze di conservazione. Minimizza le copie locali prima di selezionare un algoritmo. I dati che non raggiungono mai il dispositivo non hanno bisogno di un design di archiviazione del dispositivo.
Poi documenta le decisioni di archiviazione e di trasporto:
- Schema di archiviazione: Scegli l'encryption autenticato, la gestione delle chiavi gestita dal sistema, le posizioni di file protette, il comportamento di backup e la gestione della cancellazione o dello zeroizzazione.
- Protocollo di trasporto: Definisci la configurazione TLS, la validazione del certificato, la politica degli endpoint e se è appropriato per il modello di minaccia l'attacco del pinning.
- La custodia delle chiavi: Procedure di generazione, accesso, distribuzione, rotazione, revoca, ripristino e sostituzione d'urgenza.
- Code e controlli di esecuzione: Decidere quali contributi di oscuramento, controllo di integrità, attestazione, rilevamento di debugger e protezioni della schermata sensibile.
- La prova di audit: Cattura inventari di configurazione, accessi, autorizzazioni di rilascio, risultati di test, registrazioni di incidenti e eccezioni.
La sequenza conta. La classificazione dei dati determina cosa ha bisogno di protezione. Questa decisione forma la conservazione e la custodia delle chiavi. I controlli di trasporto e di aggiornamento preservano poi il percorso tra servizi fidati e il client. Capacitor e i team di Electron dovrebbero ripetere la revisione per ogni target, poiché un archivio delle chiavi nativo iOS, un'opzione Android con supporto hardware, un archivio di storage del browser API e una facoltà di credenziali desktop non forniscono garanzie identiche.
La canale di aggiornamento appartiene a questo piano, non dopo. Un rilascio firmato può preservare l'integrità di code, mentre la protezione di rollback, la protezione di controllo e l'osservabilità di rilascio aiutano la squadra a rispondere quando un rilascio vulnerabile o una configurazione raggiunge gli utenti. Revisionare il piano ogni volta che l'app aggiunge dati offline, cambia il plugin di storage, introduce una nuova autorizzazione backend o altera come gli aggiornamenti sono firmati e consegnati.
Capgo fornisce aggiornamenti live firmati per le applicazioni CapacitorJS e Electron, con supporto per pacchetti criptati per JavaScript code e risorse, canali di rilascio controllati, protezione del rollback e osservabilità degli aggiornamenti per dispositivo. Capgo valutare come un percorso di aggiornamento controllato possa supportare il vostro piano di crittografia dell'app e la gestione delle rilasci.
