Em um aplicativo JSF regular, os valores são convertidos e validados usando conversores e validadores especificados pelos componentes de IU. A conversão e validação em si acontecem quando a página é enviada. Uma visualização favoritável de um aplicativo Fusion resulta no não envio da página e, portanto, nenhuma conversão ou validação semelhante é realizada por padrão.

Exemplo 1: O seguinte trecho de um arquivo de configuração mostra uma amostra de visualização favoritável, configurada para não realizar conversão ou validação do parâmetro do URL paramName.

...
    <bookmark>
        <method>#{paramHandler.handleParams}</method>
        <url-parameter>
            <name>paramName</name>
            <value>#{requestScope.paramName}</value>
        </url-parameter>
    </bookmark>
...

Os valores de atributos para componentes do Oracle ADF Faces podem ser definidos normalmente apenas no servidor. No entanto, vários componentes permitem que o desenvolvedor defina uma lista de atributos que podem ser definidos no cliente. O atributo unsecure desses componentes pode especificar uma lista como essa.

Atualmente, o único atributo que pode aparecer dentro do atributo unsecure é disabled e permite que o cliente defina quais componentes estão habilitados e quais não estão. Nunca é uma boa ideia deixar que o cliente controle os valores de atributos que só devem ser configuráveis no servidor.

Exemplo: O código a seguir demonstra um componente inputText que coleta informações de senha do usuário e usa o atributo unsecure.

...
    <af:inputText id="pwdBox"
                  label="#{resources.PWD}"
                  value=""#{userBean.password}
                  unsecure="disabled"
                  secret="true"
                  required="true"/>
...

O armazenamento de chaves de criptografia em campos de classe estática permite a recuperação fácil por uma entidade que pode acessar a memória de processo (por exemplo, dispositivo com raiz) ou despejos de memória de processo (por exemplo, despejos de memória).

Embora seja uma boa ideia definir permissões separadas de leitura e gravação para provedores de conteúdo, definir apenas a writePermission pode ser enganoso. Devido à natureza do SQL, gerar somente consultas verdadeiras de gravação é geralmente impossível: mesmo quando o usuário não tem acesso direto aos dados, um invasor pode reconstruir os dados armazenados manipulando a cláusula where.

Exemplo: Veja a seguir um exemplo de um provedor de conteúdo declarado somente com a writePermission.

 <provider android:name=".ContentProvider" android:writePermission="content.permission.WRITE_CONTENT"/> 

Uma prática comum de desenvolvimento é adicionar código "back door" (porta dos fundos), projetado especificamente para fins de depuração ou teste, que não se destina a ser enviado ou implantado com o aplicativo. Quando esse tipo de código de depuração é acidentalmente deixado no aplicativo, o aplicativo fica aberto a modos não intencionais de interação. Esses pontos de entrada "back door" criam riscos de segurança, pois não são levados em consideração durante procedimentos de design ou teste e não se enquadram nas condições operacionais esperadas do aplicativo.

O receptor registrado sem a permissão do transmissor receberá mensagens de qualquer transmissor. Se essas mensagens contiverem dados mal-intencionados ou provenientes de um transmissor mal-intencionado, o aplicativo poderá ficar comprometido.

Exemplo 1: O código a seguir registra um receptor sem especificar a permissão do transmissor.

...
context.registerReceiver(broadcastReceiver, intentFilter);
...

Qualquer aplicativo pode acessar componentes públicos que não tenham uma permissão de acesso explicitamente atribuída em sua definição de manifesto.

O valor padrão do atributo exported para os componentes de atividade, receptor e serviço em um aplicativo Android depende da presença ou ausência de um intent-filter. A presença de um intent-filter implica que o componente destina-se para uso externo, definindo assim o atributo exported como "true". Esse componente agora está acessível para qualquer outro aplicativo na plataforma Android.

Exemplo 1: Veja a seguir um exemplo de uma atividade do Android com um intent-filter e sem nenhuma permissão de acesso explícito definida.

 <activity android:name=".AndroidActivity"/> 

   <intent-filter android:label="activityName"/> 

    <action android:name=".someFunAction"/> 

   </intent-filter> 

    ... 

 </activity> 

Esta atividade pode ser explorada por aplicativos mal-intencionados.