Most methods perform no lack security manager checks because they do not cannot provide access to sensitive parts of the system, such as the file system. Most methods that do provide security manager checks verify that every class and method in the call stack is authorized before it proceeds. This security model allows restricted programs, such as Java applets, to have full access to the core Java library. It also prevents a sensitive method from acting on behalf of a malicious method that hides behind a trusted method in the call stack.
...
Class loaders allow a Java application to be dynamically extended at runtime by loading classes. For each class that is loaded, the JVM tracks the class loader that was used to load the class. When a loaded class first refers to another class, the virtual machine requests that the referenced class be loaded by the same class loader used to load the referencing class. Java's class loader architecture controls interaction between code loaded from different sources by allowing the use of different class loaders. This separation of class loaders is fundamental to the separation of code: it prevents malicious code from gaining access to and subverting trusted code.
Several methods , which are charged with loading classes , delegate their work to the class loader of the class of the method that called them. The security checks associated with loading classes are often performed by class loaders. Consequently, any method that invokes one of these class-loading methods must guarantee that these methods are not acting on behalf of untrusted code. These methods are listed in the following table.
...
Classes that have the same defining class loader will exist in the same namespace but can have different privileges, depending on the security policy. Security vulnerabilities can arise when trusted code coexists with untrusted code (or less-privileged code) that was loaded by the same class loader. In this case, the untrusted or less-privileged code can freely access members of the trusted code according to itsdeclared its declared accessibility. When the trusted code uses any of the tabulated APIs, it bypasses security manager checks (with the exception of loadLibrary() and load()).
...
In this noncompliant code example, a call to System.loadLibrary() is embedded in a doPrivileged block. It is insecure because it could load a library can be loaded on behalf of untrusted code. In essence, the untrusted code's class loader may be able to indirectly load a library even though it lacks sufficient permissions to do so directly. After loading the library, untrusted code can call native methods from the library, if those methods are accessible, because the doPrivileged block stops any security manager checks being applied to callers further up the execution chain.
...
Although this method is called in the context of an applet, it uses Class.forName() to obtain the requested class. And Class.forName() delegates the search to the calling method's class loader. In this case, the calling class (com.sun.beans.finder.ClassFinder) is part of core Java, so the trusting class loader is used instead in place of the more paranoid applet class loader.
...