A especificação Enterprise JavaBeans exige que todos os fornecedores de beans sigam um conjunto de orientações de programação destinadas a assegurar que o bean será portátil e terá um comportamento consistente em qualquer contêiner EJB [1].

Neste caso, o programa viola a seguinte orientação EJB:

"O enterprise bean não deve tentar criar um carregador de classes; definir o carregador de classes de contexto; definir o gerenciador de segurança; criar um novo gerenciador de segurança; parar a JVM; ou alterar os fluxos de entrada, saída e erro."

Uma exigência que a especificação justifica da seguinte maneira:

"Essas funções são reservadas para o contêiner do Enterprise Beans. Permitir que o enterprise bean use essas funções pode comprometer a segurança e diminuir a capacidade do contêiner de gerenciar adequadamente o ambiente de tempo de execução."

O comportamento de funções nessa categoria varia de acordo com o sistema operacional e, às vezes, até mesmo com a versão do sistema operacional. Diferenças de implementação podem incluir:

- Pequenas diferenças em como os parâmetros são interpretados, provocando resultados inconsistentes.

- Algumas implementações da função contêm riscos de segurança significativos.

- A função não pode ser definida em todas as plataformas.

Diferentes sistemas operacionais usam diferentes caracteres como separadores de arquivo. Por exemplo, os sistemas Microsoft Windows usam "\", enquanto os sistemas UNIX usam "/". Quando os aplicativos precisam ser executados em plataformas diferentes, o uso de separadores de arquivo inseridos em código fixo pode resultar na execução incorreta da lógica do aplicativo e, potencialmente, em uma negação de serviço.

Exemplo 1: O seguinte código usa um separador de arquivo inserido em código fixo para abrir um arquivo:

...
File file = new File(directoryName + "\\" + fileName);
...

Ao comparar dados que pode ser dependentes de localidade, uma localidade apropriada deve ser especificada.

Exemplo 1: O exemplo a seguir tenta realizar uma validação para determinar se a entrada do usuário inclui uma tag <script>.

  ...
  public String tagProcessor(String tag){
    if (tag.toUpperCase().equals("SCRIPT")){
      return null;
    }
    //does not contain SCRIPT tag, keep processing input
    ...
  }
  ...

O problema com o Example 1 é que java.lang.String.toUpperCase(), quando usado sem uma localidade, aplica as regras da localidade padrão. O uso da localidade turca "title".toUpperCase() retorna "T\u0130TLE", onde "\u0130" é o caractere "LATIN CAPITAL LETTER I WITH DOT ABOVE". Isso pode provocar resultados inesperados, como no Example 1, em que isso impedirá que a palavra "script" seja capturada por essa validação, podendo causar uma vulnerabilidade de Cross-Site Scripting.

Os sistemas SAP são projetados para serem independentes de plataforma. Open SQL, o dialeto SQL portátil do SAP, torna os aplicativos independentes do driver JDBC de um fornecedor de banco de dados específico. A utilização do Open SQL abstrai os meandros do banco de dados subjacente e fornece uma interface comum para programas de aplicativo para todas as operações de banco de dados. No entanto, o SQL nativo é específico do banco de dados subjacente e, portanto, o uso dele em outras plataformas pode provocar a execução incorreta da lógica do aplicativo e, potencialmente, uma negação de serviço.
Exemplo 1: O seguinte código usa SQL nativo:

...
import java.sql.PreparedStatement;
import com.sap.sql.NativeSQLAccess;

String mssOnlyStmt = "...";
// variant 1
  PreparedStatement ps =
  NativeSQLAccess.prepareNativeStatement(
    conn, mssOnlyStmt);
  . . .
// variant 2
  Statement stmt =
  NativeSQLAccess.createNativeStatement(conn);
  int result = stmt.execute(mssOnlyStmt);
  . . .
// variant 3
  CallableStatement cs =
  NativeSQLAccess.prepareNativeCall(
  conn, mssOnlyStmt);
  . . .