可通过启用java安全管理器并配置自定义策略文件限制system.setproperty等敏感操作，但该方案仅适用于java 8–17；java 21已移除该机制，应转向模块化、容器隔离或应用层封装等现代防护方式。
可以通过启用Java安全管理器并配置自定义策略文件，限制代码对System.setProperty等敏感操作的权限，从而防止非法修改系统属性。
启用安全管理器并指定策略文件
启动JVM时必须显式启用安全管理器，并通过-Djava.security.manager和-Djava.security.policy参数加载策略文件。注意：从Java 17起，安全管理器已被标记为deprecated，但仍在运行时有效；Java 21已完全移除该机制，因此该方案仅适用于Java 8–17（含）版本。
- 启动命令示例：
java -Djava.security.manager -Djava.security.policy==/path/to/my.policy MyApp - 使用双等号
==表示**完全替换**默认策略（避免与系统策略叠加导致权限过宽） - 确保策略文件路径可读，且JVM进程有访问权限
在policy文件中精确限制PropertyPermission
系统属性操作受java.util.PropertyPermission保护。需明确声明哪些属性可读/写，未声明的默认禁止。
- 只允许读取特定属性：
permission java.util.PropertyPermission "user.home", "read"; - 禁止所有写操作（最常用防护）：
permission java.util.PropertyPermission "*", "read";
（不授予write，任何System.setProperty调用将抛出SecurityException） - 若需有限写权限，应白名单化，例如：
permission java.util.PropertyPermission "myapp.config.*", "write";
验证策略是否生效
仅配置策略文件不等于安全生效，必须确认安全管理器已激活且权限检查被触发。
- 在代码中检查：
System.getSecurityManager() != null应返回true - 主动测试敏感操作：
System.setProperty("foo", "bar");在无对应write权限时应立即抛出java.lang.SecurityException - 注意：部分框架（如Spring、Log4j）可能内部调用
System.setProperty，需提前识别并授权，否则导致启动失败
替代方案（面向Java 17+及未来）
因安全管理器已被弃用并最终移除，生产环境建议转向更现代的隔离与管控方式：
- 使用模块系统（Java 9+）控制包导出与服务访问，减少攻击面
- 通过容器（如Docker）或OS级限制（seccomp、capabilities）禁止进程修改全局环境/属性
- 在应用层封装
System.setProperty调用，统一校验键名、值内容及调用栈，记录审计日志 - 借助字节码增强工具（如Byte Buddy）在类加载期织入检查逻辑，拦截非法属性设置
