程序可以从 public 访问方法中返回一个 private 数组变量，通过此种方式，您可以调用代码来修改该数组的内容，还可以轻易地获取数组的 public 访问，并阻止程序员将其设置为 private 的计划。

例 1：以下 Java Applet 代码错误地从 public 访问方法中返回了一个 private 数组变量。

public final class urlTool extends Applet {
private URL[] urls;
public URL[] getURLs() {
	return urls;
}
	...
}

移动代码，在本例中也就是 Java Applet，通过网络进行传递并在远程机器上运行。因为移动代码的编写者很难控制其所编写代码的运行环境，所以在安全上提出特别的要求理所当然。一个最大的环境威胁在于，移动代码可以伴随其他潜在的恶意移动代码一起运行。因为所有的主流 web 浏览器会在同一 JVM 中执行来自多个来源的代码，所以，许多移动代码的安全指导原则都很关注可以访问到运行着您程序的同一虚拟机的攻击者，避免他们操纵您的对象的状态和行为。

默认情况下，允许 Java Applet 将数据库连接打开回它们从其下载的服务器。在可信赖的环境中，这是可接受的；然而，在不可信赖的环境中，攻击者可能会使用 Applet 查找数据库凭证，并最终获得对数据库的直接访问。
例 1：以下代码显示在 applet 中使用的硬编码的数据库密码。

public class CustomerServiceApplet extends JApplet
{
    public void paint(Graphics g)
    {
        ...
        conn = DriverManager.getConnection ("jdbc:mysql://db.example.com/customerDB", "csr", "p4ssw0rd");
        ...

具有硬编码的 JDBC 凭证的 Applet 用户可以容易地找到凭证，因为 Applet 代码已下载到客户端。此外，如果通过未加密的通道建立数据库连接，那么能够在网络上截取信息流的任何人也可以获得这些凭证。最后，允许用户直接连接到数据库会暴露可公开访问的数据库服务器，这使得攻击者能够将该数据库作为直接网络攻击的目标。

Inner class 转换为 Java 字节码所采用的方式，导致它会悄然引入一些安全问题。在 Java 源代码中，inner class 只能由封装类来声明它是可以访问的，但是 Java 字节码中并没有 inner class 的概念，因此，编译器必须把一个内部类声明转换成与 package 有同等级别的类（有权访问源外部类）。由于内部类可以访问其封装类中的 private 字段，一旦某个 inner class 成为字节码中的同等类，该编译器便会把 inner class 访问的 private 字段转换成 protected 字段，这一点具有潜在的危险性。

例 1：以下 Java Applet 代码错误地使用了 inner class。

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

移动代码，在本例中也就是 Java Applet，通过网络进行传递并在远程机器上运行。因为移动代码的编写者很难控制其所编写代码的运行环境，所以在安全上提出特别的要求理所当然。一个最大的环境威胁在于，移动代码可以伴随其他潜在的恶意移动代码一起运行。因为所有的主流 web 浏览器会在同一 JVM 中执行来自多个来源的代码，所以，许多移动代码的安全指导原则都很关注可以访问到运行着您程序的同一虚拟机的攻击者，避免他们操纵您的对象的状态和行为。

除非在 finalize() 的实现方法内部调用 super.finalize()，否则请不要显式地调用 finalize。在移动代码中，手动垃圾回收这种带有错误倾向的操作会威胁到系统的安全，由于 finalize() 的声明中包含对 public 访问，因此会造成攻击者的恶意调用。如果您按其最初设计使用 finalize()，则应首先声明 finalize() 包含 protected 访问权限。

例 1：以下 Java Applet 代码错误地声明了一种 public finalize() 方法。

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

移动代码，在本例中也就是 Java Applet，通过网络进行传递并在远程机器上运行。因为移动代码的编写者很难控制其所编写代码的运行环境，所以在安全上提出特别的要求理所当然。一个最大的环境威胁在于，移动代码可以伴随其他潜在的恶意移动代码一起运行。因为所有的主流 web 浏览器会在同一 JVM 中执行来自多个来源的代码，所以，许多移动代码的安全指导原则都很关注可以访问到运行着您程序的同一虚拟机的攻击者，避免他们操纵您的对象的状态和行为。

在大多数情况下，把数组声明为 public、final 和 static 是一个 bug。因为数组是一个可变的对象，而 final 限制要求数组对象本身只能分配一次，但并不保证数组元素的数值不变。既然数组是公用的，恶意程序便可以篡改数组中存储的值。所以，在大多数情况下，应将数组设置为 private。

例 1：以下 Java Applet 代码错误地把一个数组声明为 public、final 和 static。

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

移动代码，在本例中也就是 Java Applet，通过网络进行传递并在远程机器上运行。因为移动代码的编写者很难控制其所编写代码的运行环境，所以在安全上提出特别的要求理所当然。一个最大的环境威胁在于，移动代码可以伴随其他潜在的恶意移动代码一起运行。因为所有的主流 web 浏览器会在同一 JVM 中执行来自多个来源的代码，所以，许多移动代码的安全指导原则都很关注可以访问到运行着您程序的同一虚拟机的攻击者，避免他们操纵您的对象的状态和行为。

在 Applet 及其所使用的类中，所有 public 的成员变量都应声明 final，以防止攻击者未经授权，操纵或获取对 Applet 内部状态的访问权。

例 1：以下 Java Applet 代码错误地声明了成员变量 public，而不是 final。

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

移动代码，在本例中也就是 Java Applet，通过网络进行传递并在远程机器上运行。因为移动代码的编写者很难控制其所编写代码的运行环境，所以在安全上提出特别的要求理所当然。一个最大的环境威胁在于，移动代码可以伴随其他潜在的恶意移动代码一起运行。因为所有的主流 web 浏览器会在同一 JVM 中执行来自多个来源的代码，所以，许多移动代码的安全指导原则都很关注可以访问到运行着您程序的同一虚拟机的攻击者，避免他们操纵您的对象的状态和行为。