Java安全需四维协同：更新至LTS版本、禁用弱协议算法、限制远程代码执行、启用最小权限策略。关键措施包括修改java.security禁用TLSv1.0/1.1及弱算法，移除deploy.jar和浏览器插件，使用安全管理器定制策略，并用jlink精简运行时。
Java运行环境（JRE）或开发环境（JDK）本身不自带“开箱即用”的强安全策略，安全依赖于合理配置与持续维护。关键不是“装上就安全”，而是控制执行来源、限制权限、关闭冗余服务、及时更新。
禁用不安全的旧协议和算法
Java 8u161+ 默认禁用 TLS 1.0/1.1 和部分弱加密套件，但老旧应用可能强制启用。需主动检查并加固：
- 在 java.security 文件（位于
$JAVA_HOME/jre/lib/security/）中，确认以下行已启用且配置严格：
jdk.tls.disabledAlgorithms=SSLv3, TLSv1, TLSv1.1, RC4, DES, MD5withRSA, DH keySize
jdk.certpath.disabledAlgorithms=MD2, MD5, SHA1 jdkCA && usage TLSServer
立即学习“Java免费学习笔记（深入）”；
- 如需临时兼容旧系统，仅在明确风险可控时，局部调整（例如启动参数加
-Dhttps.protocols=TLSv1.2,TLSv1.3），切勿全局放开。
限制Applet、Web Start和远程代码执行
Java Web Start（JNLP）和浏览器插件（Applet）已被彻底移除（自 Java 11 起），但若仍在使用旧版 JDK（如 8u202 之前），必须手动关闭：
- 删除或重命名
$JAVA_HOME/jre/lib/deploy.jar（禁用 Web Start） - 在控制面板 → Java → 安全选项卡中，取消勾选“启用 Java 内容在浏览器中运行”（JDK 8 控制面板）
- 通过策略文件禁止远程代码加载：在
java.policy中移除或注释掉permission java.net.SocketPermission "*:1024-", "connect,resolve";等宽泛授权
启用安全管理器并定制策略（适用于服务端/可信内网场景）
安全管理器（SecurityManager）虽在 Java 17+ 中被标记为废弃，但在 Java 8–16 的关键后台服务中仍可作为纵深防御手段：
- 启动时显式启用：
java -Djava.security.manager -Djava.security.policy==/path/to/my.policy MyApp（双等号表示覆盖默认策略） - 最小化策略示例（my.policy）：
grant codeBase "file:/opt/myapp/-" {
permission java.io.FilePermission "/opt/myapp/logs/-", "read,write";
permission java.net.SocketPermission "api.example.com:443", "connect,resolve";
permission java.util.PropertyPermission "user.dir", "read";
};
不给 ALL PERMISSION，不开放 * 通配符路径，按需精确授权。
保持JDK版本更新并精简安装
官方长期支持版本（LTS）如 JDK 8u391+、JDK 11.0.23+、JDK 17.0.9+、JDK 21.0.2+ 已修复大量 CVE 漏洞。配置建议：
- 卸载所有非必需的 JDK/JRE 版本，避免多版本共存导致误用旧版
- 使用
jlink构建最小化运行时镜像（JDK 9+），只包含应用实际需要的模块，缩小攻击面 - 定期扫描：用
java -version和java -XshowSettings:properties -version核对实际生效版本与预期一致
基本上就这些。安全不是一次性开关，而是版本控制、权限收敛、协议收紧、运行隔离四者结合。不复杂但容易忽略。
