Classes internas introduzem silenciosamente várias preocupações de segurança devido à forma como são convertidas em códigos de bytes Java. No código-fonte Java, parece que uma classe interna pode ser declarada para ser acessível somente pela classe delimitadora, mas o código de bytes Java não tem nenhum conceito de uma classe interna e, portanto, o compilador deve transformar uma declaração de classe interna em uma classe de mesmo nível com acesso em nível de package à classe externa original. Mais insidiosamente, como uma classe interna pode acessar os campos private na respectiva classe delimitadora, assim que uma classe interna se tornar uma classe de mesmo nível no código de bytes, o compilador converterá os campos private acessados pela classe interna em campos protected.

Exemplo 1: O seguinte código de Applet Java utiliza uma classe interna por engano.

public final class urlTool extends Applet {
private final class urlHelper {
	...
}
	...
}

O código móvel, nesse caso um Applet Java, é o código que é transmitido através de uma rede e executado em uma máquina remota. Como os desenvolvedores de códigos móveis têm pouco ou nenhum controle sobre o ambiente em que seus códigos serão executados, preocupações especiais de segurança tornam-se relevantes. Uma das maiores ameaças ambientais resulta do risco de o código móvel ser executado correr lado a lado com outro código móvel potencialmente mal-intencionado. Como todos os navegadores da Web populares executam código de várias fontes juntos na mesma JVM, muitas das diretrizes de segurança do código móvel estão concentradas em impedir a manipulação do estado e do comportamento dos seus objetos por adversários que têm acesso à mesma máquina virtual na qual o programa está sendo executado.

Um programa nunca deve chamar finalize explicitamente, exceto para chamar super.finalize() dentro de uma implementação de finalize(). Em situações de código móvel, a outra prática propensa a erros de coleta de lixo manual pode se tornar uma ameaça à segurança quando um invasor é capaz de invocar maliciosamente um dos seus métodos finalize() porque ele é declarado com acesso public. Se você estiver usando finalize() conforme ele foi concebido, não haverá motivo para declarar finalize() com algo diferente de um acesso protected.

Exemplo 1: O seguinte código de Applet Java declara um método erroneamente como public finalize().

public final class urlTool extends Applet {
public void finalize() {
	...
}
	...
}

O código móvel, nesse caso um Applet Java, é o código que é transmitido através de uma rede e executado em uma máquina remota. Como os desenvolvedores de códigos móveis têm pouco ou nenhum controle sobre o ambiente em que seus códigos serão executados, preocupações especiais de segurança tornam-se relevantes. Uma das maiores ameaças ambientais resulta do risco de o código móvel ser executado correr lado a lado com outro código móvel potencialmente mal-intencionado. Como todos os navegadores da Web populares executam código de várias fontes juntos na mesma JVM, muitas das diretrizes de segurança do código móvel estão concentradas em impedir a manipulação do estado e do comportamento dos seus objetos por adversários que têm acesso à mesma máquina virtual na qual o programa está sendo executado.

Na maioria dos casos, um array declarado como public, final e static é um bug. Como os arrays são objetos mutáveis, a restrição de final requer que o próprio objeto de array seja atribuído apenas uma vez, mas não faz nenhuma garantia sobre os valores dos elementos de array. Como o array é público, um programa mal-intencionado pode alterar os valores armazenados nele. Na maioria das situações, o array deve se tornar private.

Exemplo 1: O seguinte código de Applet Java declara um array erroneamente como public, final e static.

public final class urlTool extends Applet {
public final static URL[] urls;
	...
}

O código móvel, nesse caso um Applet Java, é o código que é transmitido através de uma rede e executado em uma máquina remota. Como os desenvolvedores de códigos móveis têm pouco ou nenhum controle sobre o ambiente em que seus códigos serão executados, preocupações especiais de segurança tornam-se relevantes. Uma das maiores ameaças ambientais resulta do risco de o código móvel ser executado correr lado a lado com outro código móvel potencialmente mal-intencionado. Como todos os navegadores da Web populares executam código de várias fontes juntos na mesma JVM, muitas das diretrizes de segurança do código móvel estão concentradas em impedir a manipulação do estado e do comportamento dos seus objetos por adversários que têm acesso à mesma máquina virtual na qual o programa está sendo executado.

Todas as variáveis membros public em um Applet e em classes usadas por um Applet devem ser declaradas como final para impedir que um invasor manipule ou obtenha acesso não autorizado ao estado interno do Applet.

Exemplo 1: O seguinte código de Applet Java declara erroneamente uma variável membro como public, mas não como final.

public final class urlTool extends Applet {
public URL url;
	...
}

O código móvel, nesse caso um Applet Java, é o código que é transmitido através de uma rede e executado em uma máquina remota. Como os desenvolvedores de códigos móveis têm pouco ou nenhum controle sobre o ambiente em que seus códigos serão executados, preocupações especiais de segurança tornam-se relevantes. Uma das maiores ameaças ambientais resulta do risco de o código móvel ser executado correr lado a lado com outro código móvel potencialmente mal-intencionado. Como todos os navegadores da Web populares executam código de várias fontes juntos na mesma JVM, muitas das diretrizes de segurança do código móvel estão concentradas em impedir a manipulação do estado e do comportamento dos seus objetos por adversários que têm acesso à mesma máquina virtual na qual o programa está sendo executado.