Não é recomendável que os desenvolvedores criem seus aplicativos usando APIs não documentadas ou ocultas. Não há garantias de que o Google não irá remover ou alterar essas APIs no futuro e, portanto, elas devem ser evitadas. Dessa forma, usar esses métodos ou campos tem um alto risco de violar seu aplicativo.

O código tenta usar o objeto Camera depois que ele já foi liberado. Qualquer referência adicional ao objeto Camera sem a reaquisição do recurso lançará uma exceção e poderá fazer com que o aplicativo trave se essa exceção não for detectada.

Exemplo: O código a seguir usa um botão de alternância para ativar e desativar a visualização da câmera. Depois que o usuário tocar no botão uma vez, a visualização da câmera será interrompida, e o recurso da câmera será liberado. No entanto, se ele tocar no botão novamente, startPreview() será chamado no objeto Camera anteriormente liberado.

public class ReuseCameraActivity extends Activity {
  private Camera cam;

  ...
  private class CameraButtonListener implements OnClickListener {
      public void onClick(View v) {
          if (toggle) {
              cam.stopPreview();
              cam.release();
          }
          else {
              cam.startPreview();
          }
          toggle = !toggle;
      }
  }
  ...
}

O código tenta usar o objeto de mídia depois que ele já foi liberado. Qualquer referência adicional a esse objeto de mídia sem a reaquisição do recurso lançará uma exceção e poderá fazer com que o aplicativo trave se essa exceção não for detectada.

Exemplo: O código a seguir usa um botão de pausa para alternar a reprodução da mídia. Depois que o usuário tocar no botão uma vez, a música ou o vídeo atual será pausado, e o recurso da câmera será liberado. No entanto, se ele tocar no botão novamente, start() será chamado no recurso de mídia anteriormente liberado.

public class ReuseMediaPlayerActivity extends Activity {
  private MediaPlayer mp;

  ...
  private class PauseButtonListener implements OnClickListener {
      public void onClick(View v) {
          if (paused) {
              mp.pause();
              mp.release();
          }
          else {
              mp.start();
          }
          paused = !paused;
      }
  }
  ...
}

O código tenta usar o manipulador de banco de dados SQLite do Android depois que ele já foi fechado. Qualquer referência adicional ao manipulador sem o restabelecimento da conexão com o banco de dados lançará uma exceção e poderá fazer com que o aplicativo trave se essa exceção não for detectada.

Exemplo: O código a seguir pode ser de um programa que armazena em cache valores de usuário temporariamente na memória, mas que pode chamar flushUpdates() para confirmar as alterações no disco. O método fecha corretamente o manipulador de banco de dados depois de gravar atualizações no banco de dados. No entanto, quando flushUpdates() é chamado novamente, o objeto de banco de dados é referenciado novamente antes da reinicialização.

public class ReuseDBActivity extends Activity {
  private myDBHelper dbHelper;
  private SQLiteDatabase db;

  @Override
  public void onCreate(Bundle state) {
      ...
      db = dbHelper.getWritableDatabase();
      ...
  }
  ...

  private void flushUpdates() {
      db.insert(cached_data);     // flush cached data
      dbHelper.close();
  }
  ...
}

A minificação melhora os tempos de carregamento de páginas para aplicativos que incluem arquivos JavaScript, reduzindo o tamanho do arquivo. O termo Minificação refere-se ao processo de remover espaços em branco, comentários, pontos-e-vírgulas e chaves desnecessários, de encurtar nomes de variáveis locais e de remover códigos inacessíveis.

Exemplo 1: O código ASPX a seguir inclui a versão não minificada da biblioteca jQuery da Microsoft:

...
<script src="http://applicationserver.application.com/lib/jquery/jquery-1.4.2.js" type="text/javascript"></script>
...

Operações aritméticas não atuarão da mesma maneira em valores boolianos como fariam em valores integrais, o que pode resultar em comportamentos inesperados.

Quando os dados de um array de bytes são convertidos em uma String, não fica claro o que acontecerá com os dados que estiverem fora do conjunto de caracteres aplicável. Isso pode provocar perda de dados ou uma diminuição no nível de segurança quando dados binários são necessários para assegurar que medidas de segurança adequadas sejam seguidas.

Exemplo 1: O código a seguir converte dados em uma String para criar um hash.

  ...
  FileInputStream fis = new FileInputStream(myFile);
  byte[] byteArr = byte[BUFSIZE];
  ...
  int count = fis.read(byteArr);
  ...
  String fileString = new String(byteArr);
  String fileSHA256Hex = DigestUtils.sha256Hex(fileString);
  // use fileSHA256Hex to validate file
  ...

Isso funciona muito bem supondo que o tamanho do arquivo seja menor que BUFSIZE, desde que as informações em myFile sejam codificadas da mesma maneira que o conjunto de caracteres padrão. Porém, se uma codificação diferente estiver em uso, ou se o arquivo for binário, haverá perda de informações. Isso por sua vez fará com que o hash SHA resultante seja menos confiável e pode implicar que colisões podem ser provocadas com muito mais facilidade, especialmente se os dados fora do conjunto de caracteres padrão forem representados pelo mesmo valor, como um ponto de interrogação.

Não há como especificar qual thread será ativado por chamadas para notify().

Exemplo 1: No código a seguir, notifyJob() chama notify().

public synchronized notifyJob() {
flag = true;
notify();
}
...
public synchronized waitForSomething() {
while(!flag) {
    try {
        wait();
    }
    catch (InterruptedException e)
    {
        ...
    }
}
...
}

Nesse caso, o desenvolvedor tem a intenção de ativar o thread que chama wait(), mas é possível que notify() notifique um thread diferente do pretendido.

Na maioria dos casos, uma chamada direta para o método run() de um objeto Thread é um bug. O programador pretendia iniciar um novo thread de controle, mas acidentalmente chamou run() no lugar de start() e, portanto, o método run() será executado no thread de controle do chamador.

Exemplo 1: O seguinte trecho de um programa Java chama equivocadamente run() em vez de start().

    Thread thr = new Thread() {
      public void run() {
        ...
      }
    };

  thr.run();

Na maioria dos casos, uma chamada direta para o método stop() de um objeto Thread é um bug. O programador pretendia parar a execução de um thread, mas não sabia que esta não é uma maneira adequada de fazer isso. A função stop() dentro de Thread causa uma exceção ThreadDeath em qualquer lugar dentro do objeto Thread, provavelmente deixando objetos em um estado inconsistente e possivelmente deixando vazar recursos. Como essa API é inerentemente insegura, seu uso foi preterido há muito tempo.

Exemplo 1: O seguinte trecho de um programa Java chama equivocadamente Thread.stop().

  ...
  public static void main(String[] args){
    ...
    Thread thr = new Thread() {
      public void run() {
        ...
      }
    };
    ...
    thr.start();
    ...
    thr.stop();
    ...
  }

Parece que o programador pretendia que essa classe implementasse a interface Cloneable, pois ela implementa um método denominado clone(). No entanto, a classe não implementa a interface Cloneable, e o método clone() não se comportará corretamente.

Exemplo 1: Chamar clone() para essa chamada resultará em uma CloneNotSupportedException.

public class Kibitzer {
  public Object clone() throws CloneNotSupportedException {
    ...
  }
}

A interface ICloneable não garante uma clonagem profunda. As classes que a implementam podem não apresentar o comportamento esperado ao serem clonadas. Classes que implementam ICloneable e executam apenas uma clonagem superficial (cópias apenas do objeto, o que inclui referências existentes a outros objetos) podem resultar em um comportamento inesperado. Como a clonagem profunda (cópias do objeto e de todos os objetos referenciados) é normalmente o comportamento assumida de um método de clone, o uso da interface ICloneable é propenso a erros e deve ser evitado.

Quando uma função clone() chama uma função substituível, ela pode fazer com que o clone seja deixado em um estado parcialmente inicializado ou se torne corrompido.

Exemplo 1: A função clone() a seguir chama um método que pode ser substituído.

  ...
  class User implements Cloneable {
    private String username;
    private boolean valid;
    public Object clone() throws CloneNotSupportedException {
      final User clone = (User) super.clone();
      clone.doSomething();
      return clone;
    }
    public void doSomething(){
      ...
    }
  }

Como a função doSomething() e a sua classe delimitadora não são final, significa que a função pode ser substituída, o que pode deixar o objeto clone clonado em um estado parcialmente inicializado, capaz de provocar erros, se não estiver trabalhando em torno da lógica de uma forma inesperada.

Ao lidar com primitivas encaixotadas, ao comparar a igualdade, o método equals() da primitiva encaixotada deve ser chamado em vez dos operadores == e !=. A Especificação Java declara o seguinte sobre conversões de encaixotamento:

"Se o valor de p que está sendo encaixotado for um número inteiro literal do tipo int entre -128 e 127, inclusive, ou um booliano literal true ou false, ou um caractere literal entre '\u0000' e '\u007f', inclusive, deixe que a e b sejam os resultados de quaisquer duas conversões de encaixotamento de p. Em todos os casos, a == b."

Isso significa que, se uma primitiva encaixotada for usada (diferente de Boolean ou Byte), apenas uma faixa de valores será armazenada em cache ou memorizada. Para um subconjunto de valores, o uso de == ou != retornará o valor correto. Para todos os outros valores fora desse subconjunto, isso retornará o resultado da comparação dos endereços de objetos.

Exemplo 1: O exemplo a seguir usa operadores de igualdade em primitivas encaixotadas.

  ...
  Integer mask0 = 100;
  Integer mask1 = 100;
  ...
  if (file0.readWriteAllPerms){
    mask0 = 777;
  }
  if (file1.readWriteAllPerms){
    mask1 = 777;
  }
  ...
  if (mask0 == mask1){
    //assume file0 and file1 have same permissions
    ...
  }
  ...

O código no Example 1 usa primitivas encaixotadas Integer para tentar comparar dois valores int. Se mask0 e mask1 forem ambos iguais a 100, mask0 == mask1 retornará true. No entanto, quando mask0 e mask1 forem ambos iguais a 777, mask0 == maske1 agora retornará false, pois esses valores não estão dentro do intervalo de valores armazenados em cache para essas primitivas encaixotadas.

Quando é feita uma comparação com NaN, ela é sempre avaliada como false, exceto para o operador !=, que sempre é avaliado como true, já que NaN não está ordenado.

Exemplo 1: O exemplo a seguir tenta garantir que uma variável não é NaN.

  ...
  if (result == Double.NaN){
    //something went wrong
    throw new RuntimeException("Something went wrong, NaN found");
  }
  ...

Isso tenta verificar se result não é NaN, mas o uso do operador == com NaN sempre resulta em um valor de false, e, portanto, essa verificação nunca lançará a exceção.

Quando um construtor chama uma função substituível, isso pode permitir que um invasor acesse a referência this antes que o objeto seja totalmente inicializado, o que, por sua vez, pode provocar uma vulnerabilidade.

Exemplo 1: O exemplo a seguir chama um método que pode ser substituído.

  ...
  class User {
    private String username;
    private boolean valid;
    public User(String username, String password){
      this.username = username;
      this.valid = validateUser(username, password);
    }
    public boolean validateUser(String username, String password){
      //validate user is real and can authenticate
      ...
    }
    public final boolean isValid(){
      return valid;
    }
  }

Como a função validateUser e a classe não são final, isso significa que elas podem ser substituídas e, dessa forma, inicializar uma variável para a subclasse que substitui essa função possibilitaria o desvio da funcionalidade validateUser. Por exemplo:

  ...
  class Attacker extends User{
    public Attacker(String username, String password){
      super(username, password);
    }
    public boolean validateUser(String username, String password){
      return true;
    }
  }
  ...
  class MainClass{
    public static void main(String[] args){
      User hacker = new Attacker("Evil", "Hacker");
      if (hacker.isValid()){
        System.out.println("Attack successful!");
      }else{
        System.out.println("Attack failed");
      }
    }
  }

O código no Example 1 imprime "Attack successful!", uma vez que a classe Attacker substitui a função validateUser() que é chamada a partir do construtor da superclasse User, e o Java primeiro examinará a subclasse em busca de funções chamadas a partir desse construtor.

Os invasores podem duplicar deliberadamente os nomes das classes para fazer com que um programa execute um código mal-intencionado. Por esse motivo, os nomes das classes não são bons identificadores de tipo e não devem ser usados como base para conceder confiança a determinado objeto.

Exemplo 1: O código a seguir determina se a entrada de um objeto inputReader é confiável com base em seu nome de classe. Se um invasor puder fornecer uma implementação de inputReader que executa comandos mal-intencionados, esse código não poderá diferenciar as versões bem-intencionadas das mal-intencionadas do objeto.

if (inputReader.getClass().getName().equals("com.example.TrustedClass")) {
   input = inputReader.getInput();
   ...
}

Esse campo foi anotado com FortifyNonNegative, que é usado para indicar que valores negativos não são permitidos.

No caso de PL/SQL, o valor NULL é indeterminado. Não será equivalente a nada, nem mesmo a um outro valor NULL. Além disso, um valor null nunca é equivalente a outro valor.

Exemplo 1: Esta instrução será sempre false.

checkNull BOOLEAN := x = NULL;

Exemplo 2: Esta instrução será sempre false.

checkNotNull BOOLEAN := x != NULL;

Esse programa usa == ou != para comparar a igualdade de duas strings, o que compara a igualdade de dois objetos, e não seus valores. São boas as chances de que as duas referências nunca serão iguais.

Exemplo 1: A seguinte ramificação nunca deve ser usada.

  if (args[0] == STRING_CONSTANT) {
      logger.info("miracle");
  }

Os operadores == e != apenas se comportarão conforme esperado quando forem usados para comparar strings contidas em objetos que são iguais. A maneira mais comum de isso acontecer é internalizando as strings, processo pelo qual elas são adicionadas a um pool de objetos mantidos pela classe String. Após a internalização de uma string, todas as suas aplicações usarão o mesmo objeto, e os operadores de igualdade terão o comportamento esperado. Todos os literais de string e constantes com valores de string são internalizados automaticamente. Outras strings podem ser internalizadas manualmente chamando String.intern(), o que retornará uma instância canônica da string atual, criando uma se necessário.