Editing Java applet (section)

=== Unsigned ===<!-- I didn't really bother with cleaning up the tense of these sections: they need a full rewrite, due to substantial NPOV problems -->
Limits on unsigned applets were understood as "draconian": they have no access to the local filesystem and web access limited to the applet download site; there are also many other important restrictions. For instance, they cannot access all system properties, use their own [[class loader]], call [[native code]], execute external commands on a local system or redefine classes belonging to core packages included as part of a Java release. While they can run in a standalone frame, such frame contains a header, indicating that this is an untrusted applet. Successful initial call of the forbidden method does not automatically create a security hole as an access controller checks the entire [[Call stack|stack]] of the calling code to be sure the call is not coming from an improper location.

As with any complex system, many security problems have been discovered and fixed since Java was first released. Some of these (like the Calendar serialization security bug) persisted for many years with nobody being aware. Others have been discovered in use by malware in the wild.{{citation needed|date=September 2013}}

Some studies mention applets crashing the browser or overusing [[central processing unit|CPU]] resources but these are classified as nuisances and not as true security flaws. However, unsigned applets may be involved in combined attacks that exploit a combination of multiple severe configuration errors in other parts of the system. An unsigned applet can also be more dangerous to run directly on the server where it is hosted because while code base allows it to talk with the server, running inside it can bypass the firewall. An applet may also try [[Denial-of-service attack|DoS attacks]] on the server where it is hosted, but usually people who manage the web site also manage the applet, making this unreasonable. Communities may solve this problem via [[Code review|source code review]] or running applets on a dedicated domain.

The unsigned applet can also try to download malware hosted on originating server. However it could only store such file into a temporary folder (as it is transient data) and has no means to complete the attack by executing it. There were attempts to use applets for spreading Phoenix and Siberia exploits this way,{{citation needed|date=October 2010}} but these exploits do not use Java internally and were also distributed in several other ways.