Security Advanced

SecurityManager checks to explicit authorization

Replace disabled SecurityManager checks with explicit application authorization and deployment isolation.

✕ JDK 23 and earlier
SecurityManager manager = System.getSecurityManager();
if (manager != null) {
    manager.checkRead(path.toString());
}
return Files.readString(path);
✓ JDK 24+
// Untrusted users must not be able to modify this tree
Path root = allowedRoot.toRealPath();
Path resolved = root.resolve(requested)
    .normalize()
    .toRealPath();
if (!resolved.startsWith(root)) {
    throw new SecurityException(
        "Path is outside the allowed root");
}
return Files.readString(resolved);
See a problem with this code? Let us know.
🔍

Explicit policy

Authorization is visible and testable in application logic.

🛡️

Real isolation

Process, container, and operating-system boundaries protect the whole application.

🚫

Required migration

Removes checks that can no longer enforce policy on JDK 24 and later.

Old Approach
SecurityManager checks
Modern Approach
Explicit authorization
Since JDK
24
Difficulty
Advanced
SecurityManager checks to explicit authorization
Available

Required on JDK 24 and later, where JEP 486 permanently disables the Security Manager.

JEP 486 permanently disabled the Security Manager in JDK 24, so checks through System.getSecurityManager() can enforce policy only on JDK 23 and earlier. Applications must authorize access explicitly in domain logic; resolving real filesystem paths prevents existing symbolic links from escaping an allowed root when untrusted users cannot modify that tree concurrently. For attacker-writable trees, use race-resistant, handle-relative access such as SecureDirectoryStream. Use process, container, or operating-system boundaries for isolation. JDK 24 retains the deprecated API temporarily, but it cannot be enabled and is not replaced by another in-process sandbox.