Java 适用于服务器。Java 的安全问题实际上是Java 小程序模型的问题，其中您的JVM（在您的浏览器中）旨在运行潜在的恶意代码（即“来自 Web”的代码），但以某种方式阻止该恶意代码做坏事. 小程序模型有点像在虚拟机中运行小程序代码，只是隔离层是由语言本身和标准库中的保护措施完成的。事实证明，试图做一个沙盒这种方式非常困难，因为您必须在每个潜在危险的库类和方法中包含显式控件，并且有数千个这样的控件。过去几年新闻中出现的所有 Java 漏洞都与此有关：一些标准库代码没有足够健壮地过滤调用，以防调用者是恶意小程序。

这些都不适用于服务器上的 Java。在服务器上，这是您的代码，假定是非敌对的，并且可以完全访问标准库。在您的服务器上运行 Java 代码（为了安全）并不比运行 C 或 C++ 代码差；实际上它可以说更好，因为 Java语言的固有保护（基于垃圾收集器的内存管理、强类型和数组边界检查）使其在某些类别的错误（如缓冲区溢出）方面更加健壮。即，缓冲区溢出的后果受到更多限制（缓冲区实际上并未溢出；相反会引发异常），并且 GC 允许更轻松地处理字符串，这是编写 C 代码时缓冲区溢出的丰富来源.

同样的道理也适用于 .NET 及其各种语言（C#、VB...）。

如果您想限制对应用程序某些部分的某些访问（取决于正在运行的代码和身份验证状态），可以使用安全管理器运行 Java 运行时环境。

例如，这可以在Apache Tomcat或JBoss中启用。

策略和权限系统是一个复杂的主题，并在此处记录。

诚然，该系统并不完美，因为您提到的有关小程序的漏洞是在小程序“逃脱”其安全管理器时发生的。如果安全管理器本身存在错误（显然是问题）或策略过于宽松，则可能会发生这种情况。

在这方面，服务器环境与 applet 环境的不同之处在于，applet 环境安装了一个万能的策略：目标是在启用大多数功能的同时限制不良行为，而无需知道代码是什么将在哪个确切环境中运行。服务器环境在这方面不太容易受到攻击，因为您可以自定义策略以满足您的特定需求（例如，允许连接到您的特定数据库服务器但不允许其他传出连接）。

默认情况下，webapp 容器中通常不会启用安全管理器，但如果需要，您可以根据需要配置策略。

是的，JVM 和类似环境降低了内存损坏漏洞的风险，尽管应该注意这类问题也可能发生在 VM 级别（例如 CVE-2013-2420）

最近一波 Java 漏洞确实集中在客户端小程序上，但还应该注意的是，已经有一些方法可以在服务器端利用这些问题（例如通过 RMI 协议）。Oracle 并不总是在他们的建议中指出这一点：

http://seclists.org/bugtraq/2013/Feb/15

关于不同 JVM 实现的安全性，Security Explorations 的 SE-2012-01 项目似乎是一个很好的起点：

http://www.security-explorations.com/en/SE-2012-01-details.html