There a number of aspects to security, including:
 o Ensuring data is cryptographically secure.
 o Ensuring privileged code (for instance java.* classes) can run
alongside untrusted code (for instance unsigned applets).
 o Ensuring an application cannot be successfully attacked through
network access or viewing malicious files.

The Sun Java security index is at [1]. I'll ignore the first, point you
to the rather short [2] for the second, and concentrate on the third.

Apparently, there have been forty or fifty incidents of flaws in JRE
security. Although I don't know how you would count them.

Stack and heap overflows are caught with StackOverflowError and
OutOfMemoryError, respectively. However, certainly for OOME, there are
corner cases where the JVM will crash.

You probably mean buffer overflows. In C and similar language systems,
an overflowing buffer can overwrite a return address on the stack and
point it to within the buffer. This cannot happen with standard APIs in
Java (although obviously you can if you mix native C code, or use the
likes of sun.misc.Unsafe).

There can be problems dealing with external data, notably with servers.
From the top of my head.

 o In order to make code secure, first make it good.

 o Public servers should be kept in a DMZ, so if they are compromised
you haven't lost all security.

 o The server itself should be secure. Locked down with minimal
services running, and patched.

 o The software should run as a user with minimal privileges.

 o Never trust data from the user.

 o Never trust the user to hold secure data (often in hidden HTML fields).

 o Don't give hints to sensitive data. For instance varying error
message on proximity to a sensitive hit.

 o Never put sensitive information in URLs (for instance using URL
rewriting for session IDs).

 o Do not think that hiding will keep things hidden.

 o Don't trust security through obscurity.

 o SQL injection attacks. Avoid dynamic SQL. Use PreparedStatement.
Someone who is as unwise to insert user data into SQL will almost
certainly do it wrong.

 o Cross Server Scripting (XSS). Putting unescaped user data back into
HTML pages may allow malicious JavaScript to be inserted, compromising
the user's access.

 o Avoid executing other programs.

 o Avoid using user supplied file names (for instance a file name may
be terminated by a NUL character, rather than the end of the String).

 o Do not assume multiple operations will be atomic unless you can
prove it.

 o If you can, restrict hosts that can access sensitive parts.

 o Usual stuff to do with passwords...

 o Log - so at least you can find out if something goes wrong, or
someone is attempting an attack.

That was supposed to be short. And it doesn't deal with Denial of
Service attacks.

Tom Hawtin

[1] http://java.sun.com/security/
[2] http://java.sun.com/security/seccodeguide.html