What is the security risk of object reflection?

1 - Reflection (as a concept) is indeed orthogonal to safety/security.

There was a big emphasis in the design of java to make it a safe platform, with static typing, security manager, disciplined usage of class loader, and no way to screw pointers/memory. You can read the interview of James Gosling in Masterminds of programming, which is interesting about that.

But the more reflective power you have the harder it is to ensure things are safe as they should. Reflection defeat notably static typing and can lead to run-time errors.

But more subtle things can happen as well. For instance class loaders -- which can be considered as reflective hook in the system -- were not designed properly in the early version of Java leading to potential type replacement. The article Dynamic class loading in the JVM, by Gilad Bracha, is insightful on such issues.

Reflection can not be turned off altogether; it's always possible to reflect on its own public fields/methods. Reflection on private structures with AccessibleObject.setAccessible can however be disabled, because it breaks encapsulation. With access to private fields, etc. inspection and modification of internal data is possible. It can lead to various malicious exploits, e.g.

• strings are not immutable anymore and can be changed (see this question)
• you can reveal sensible information of objects you don't own
• ... other exploits ...

Finally there are other mechanism that put security in jeopardy, notably sun.misc.Unsafe which gives direct access to the memory -- pointers are back.

2 - Now, the question is whether reflection (in practice) leads to that many risks.

I've read the link pointed by @dbyrne but it's mostly about .net. Also I don't know exactly what is disabled for Google App. Is it the ReflectPermission only, or other permission of the security manager? One danger is clearly to get access to the file system and mess around.

The problem of access to private data and breaking encapsulation can be argued in practice. Writing secure code is indeed extremely hard, and even without changing the access modifier you can subclass classes in an inappropriate way -- unless they are final, or even better, sealed -- and pass them around. This is for instance what defensive copying try to protect against.

Type-safety is also anyway threatened by run-time error because of downcast, so this point can also be argued.

In a shared/hosted environment, the security is relative. At the language level, you can for instance not prevent a module form consuming 100% of CPU or consuming all memory up to a OutOfMemoryException. Such concerns need to be addressed by other means, typically at the OS level, with virtualization and quotas.

So my personal answer, would be: reflection is a security risk, but not that big in practice if compared to other potential attack vectors.

An application can use the Java reflection APIs to access and update fields, and execute methods that are forbidden by normal Java access / visibility rules. With a bit of ingenuity, this is sufficient to:

• access information that is supposed to be hidden,
• subvert the Java security sandbox so that you can interfere with other things running in the JVM, access files on the local machine, and so on.

Under certain circumstances, it might even allow the injection of malicious native code.