Os aplicativos podem registrar esquemas de URL personalizados para aplicativos de terceiros a fim de se comunicar com eles. Embora esse seja um canal IPC simples, ele pode expor seu aplicativo ao “Sequestro de Esquema de URL". Como qualquer aplicativo pode registrar um esquema de URL, desde que não esteja reservado pela Apple, um aplicativo mal-intencionado pode registrar o mesmo esquema usado pelo seu aplicativo, que resulta em um comportamento não definido. De acordo com a documentação da Apple: “Se mais de um aplicativo de terceiros estiver registrado para manipular o mesmo esquema de URL, não haverá atualmente nenhum processo para determinar qual aplicativo receberá esse esquema". Se o aplicativo mal-intencionado estiver instalado antes de seu aplicativo, ele poderá registrar o esquema e impedir que seu aplicativo seja instalado com êxito. Como alternativa, se o aplicativo mal-intencionado for instalado após o aplicativo e for bem-sucedido no registro do esquema, ele poderá sequestrar seu aplicativo.

O serviço de backup do Android permite que o aplicativo salve dados persistentes em um armazenamento remoto em nuvem para fornecer um ponto de restauração para os dados do aplicativo no futuro.

Os aplicativos Android podem ser configurados com este serviço de backup, definindo o atributo allowBackupcomo true (o valor padrão) e definindo o atributo backupAgent na tag do <application>.

O Android, entretanto, não garante a segurança dos seus dados durante o uso do backup, já que o armazenamento e transporte em nuvem variam de dispositivo para dispositivo.

Arquivos salvos no armazenamento externo são legíveis publicamente e podem ser modificados pelo usuário quando permitem que armazenamento em massa via USB transfira arquivos em um computador. Além disso, os arquivos no cartão de armazenamento externo permanecerão lá até mesmo após a desinstalação do aplicativo que os gravou. Essas limitações podem comprometer informações confidenciais gravadas no armazenamento ou permitir que os invasores injetem dados mal-intencionados no programa, modificando um arquivo externo no qual ele se baseia.

Exemplo 1: No código a seguir, Environment.getExternalStorageDirectory() retorna uma referência ao armazenamento externo do dispositivo Android.

 private void WriteToFile(String what_to_write) {
        try{
            File root = Environment.getExternalStorageDirectory();
            if(root.canWrite()) {
                File dir = new File(root + "write_to_the_SDcard");
                File datafile = new File(dir, number + ".extension");
                FileWriter datawriter = new FileWriter(datafile);
                BufferedWriter out = new BufferedWriter(datawriter);
                out.write(what_to_write);
                out.close();
             }
        }
   }

Os dados armazenados no armazenamento interno do Android usando MODE_WORLD_READBLE ou MODE_WORLD_WRITEABLE podem ser acessados por todos os aplicativos no dispositivo. Isso não só nega proteção contra corrupção de dados, como também, no caso de informações confidenciais, viola preocupações com a privacidade e a segurança do usuário.

Ao armazenar dados no conjunto de chaves, um nível de acessibilidade, que define quando será possível acessar o item, precisa ser configurado. Os níveis possíveis de acessibilidade incluem:

-kSecAttrAccessibleAfterFirstUnlockThisDeviceOnly:
Os dados no item de conjunto de chaves não poderão ser acessados após uma reinicialização até que o dispositivo tenha sido desbloqueado uma vez pelo usuário.
Após o primeiro desbloqueio, os dados permanecem acessíveis até a próxima reinicialização. Isso é recomendado para os itens que precisam ser acessados por aplicativos em segundo plano. Os itens com esse atributo não migram para um novo dispositivo. Assim, após a restauração de um backup de um dispositivo diferente, esses itens não estarão presentes.
Disponível em iOS 4.0 ou posterior.

-kSecAttrAccessibleAlways:
Os dados no item de conjunto de chaves sempre podem ser acessados independentemente do dispositivo estar bloqueado.
Isso não é recomendado para uso do aplicativo. Os itens com esse atributo migram para um novo dispositivo ao usar backups criptografados.
Disponível em iOS 4.0 ou posterior.

-kSecAttrAccessibleWhenPasscodeSetThisDeviceOnly:
Os dados no conjunto de chaves só podem ser acessados quando o dispositivo está desbloqueado. Disponível somente se uma senha estiver definida no dispositivo.
Isso é recomendado para itens que só precisam ser acessíveis enquanto o aplicativo está em primeiro plano. Os itens com esse atributo nunca migram para um novo dispositivo. Depois que um backup é restaurado para um novo dispositivo, esses itens estarão ausentes. Nenhum item pode ser armazenado nesta classe em dispositivos sem uma senha. Desabilitar a senha do dispositivo faz com que todos os itens dessa classe sejam excluídos.
Disponível em iOS 8.0 ou posterior.

-kSecAttrAccessibleAlwaysThisDeviceOnly:
Os dados no item de conjunto de chaves sempre podem ser acessados independentemente do dispositivo estar bloqueado.
Isso não é recomendado para uso do aplicativo. Os itens com esse atributo não migram para um novo dispositivo. Assim, após a restauração de um backup de um dispositivo diferente, esses itens não estarão presentes.
Disponível em iOS 4.0 ou posterior.

-kSecAttrAccessibleWhenUnlocked:
Os dados no item de conjunto de chaves só podem ser acessados quando o dispositivo é desbloqueado pelo usuário.
Isso é recomendado para itens que só precisam ser acessíveis enquanto o aplicativo está em primeiro plano. Os itens com esse atributo migram para um novo dispositivo ao usar backups criptografados.
Esse é o valor padrão para os itens do conjunto de chaves adicionados sem definir explicitamente uma constante de acessibilidade.
Disponível em iOS 4.0 ou posterior.

-kSecAttrAccessibleWhenUnlockedThisDeviceOnly:
Os dados no item de conjunto de chaves só podem ser acessados quando o dispositivo é desbloqueado pelo usuário.
Isso é recomendado para itens que só precisam ser acessíveis enquanto o aplicativo está em primeiro plano. Os itens com esse atributo não migram para um novo dispositivo. Assim, após a restauração de um backup de um dispositivo diferente, esses itens não estarão presentes.
Disponível em iOS 4.0 ou posterior.

Os níveis de acessibilidade que não contêm o ThisDeviceOnly serão armazenados em backup no iCloud e no iTunes, mesmo se você estiver usando backups não criptografados que podem ser restaurados para qualquer dispositivo. Dependendo de quão confidenciais e privados os dados armazenados são, isso pode gerar uma preocupação de privacidade.

Exemplo 1: No exemplo a seguir, o item de conjunto de chaves está protegido o tempo todo, exceto quando o dispositivo estiver ligado e desbloqueado, mas o item de conjunto de chaves será armazenado em backup no iCloud e em backups não criptografados do iTunes:

...
    NSMutableDictionary *dict = [NSMutableDictionary dictionary];
    NSData *token = [@"secret" dataUsingEncoding:NSUTF8StringEncoding];

    // Configure KeyChain Item
    [dict setObject:(__bridge id)kSecClassGenericPassword forKey:(__bridge id) kSecClass];
    [dict setObject:token forKey:(__bridge id)kSecValueData];
    ...
    [dict setObject:(__bridge id)kSecAttrAccessibleWhenUnlocked forKey:(__bridge id) kSecAttrAccessible];

    OSStatus error = SecItemAdd((__bridge CFDictionaryRef)dict, NULL);
...

As respostas HTTP(S) podem conter dados confidenciais, como cookies da sessão e tokens de API. O sistema de carregamento de URL armazenará em cache todas as respostas HTTP(S) para fins de desempenho, armazenando-as sem criptografia em um armazenamento compartilhado inseguro.

Exemplo 1: O código a seguir instala o cache de resposta HTTP(S) no espaço de armazenamento compartilhado:

    protected void onCreate(Bundle savedInstanceState) {
       ...

       try {
           File httpCacheDir = new File(context.getExternalCacheDir(), "http");
           long httpCacheSize = 10 * 1024 * 1024; // 10 MiB
           HttpResponseCache.install(httpCacheDir, httpCacheSize);
       } catch (IOException e) {
           Log.i(TAG, "HTTP response cache installation failed:" + e);
       }
    }

    protected void onStop() {
       ...

       HttpResponseCache cache = HttpResponseCache.getInstalled();
       if (cache != null) {
           cache.flush();
       }
   }

As respostas HTTP(S) podem conter dados confidenciais, como cookies da sessão e tokens de API. O sistema de carregamento de URL armazenará em cache todas as respostas HTTP(S) para fins de desempenho, armazenando-as de forma descriptografada nos arquivos {app ID}/Library/Caches/com.mycompany.myapp/Cache.db*.
Os desenvolvedores podem pensar que ao definir as propriedades diskCapacity ou memoryCapacity da classe URLCache como 0, eles podem estar desabilitando efetivamente o sistema de cache de respostas HTTP(S). No entanto, a documentação de NSURLCache indica que os caches no disco e na memória serão truncados para os tamanhos configurados somente se o dispositivo estiver sendo executado com pouca memória ou pouco espaço em disco. Ambas as configurações são usadas pelo sistema para liberar recursos do sistema e melhorar o desempenho, não como um controle de segurança.