Are private members really more “secure” in Java?

问题:

Learning Java I was sometimes taught to use the private access modifier so as not to expose "sensitive information" to other classes, as if this could open a legitimate security hole. But I've never encountered a situation in which restricting member visibility was more than a convenience for modelling a program in an object-oriented fashion.

Are private fields and functions in Java classes actually more "secure" than otherwise?

---

EDIT -- Compilation of best answers.

Why private does not mean "secure":

• decompilers allow static look at bytecode
• reflection library allows runtime access to private members

What private is good for:

• maintainability of code due to forcing method-level access
• modularity of code by hiding implementation details

回答1:

I've never heard of it -- in any serious sense -- as a security issue. I mean, decompilers work. You can use them to figure out what's going on inside the bytecode.

Having private members is a maintainability issue. If I only give you method-level access to my internals, then my only responsibility is to ensure that my API methods continue to work. I'm not locked into using a Double versus a BigDecimal on the insides, so long as my methods continue to return Doubles (for instance).

回答2:

No, they are not more "secure" in that sense, though some (very poor) books on Java try to explain private in that way. If an attacker had the ability to cause arbitrary Java code to be run in your process, all "security" is already gone. And as another answer already mentioned, reflection can bypass the private access modifier.

回答3:

private isn't really for security, since reflection can bypass it (modulo classloader/secure classloader stuff). It serves as an indication of intent, and as barrier to one type of programming error.

But consider a third-party API--API users don't even see the private properties or methods. It's not just about your own code, it's about what code is exposed to others. (Again looking at it from a "I'm not trying to break in to the code" standpoint.)

回答4:

As far as security goes, the answer is "not really": determined hackers could get to your private fields and call your private functions with a little bit of reflection; all they need is a JAR with your code in it.

Although hiding "sensitive" information does not make your class more secure, it makes it (along with systems built from it) a lot more maintainable. So this answer is not an excuse for making all members of your classes public.

回答5:

I agree in general with the answers so far (i.e. that private is really for code hygiene not real security). Various answers have pointed out that you can bypass private using reflection. Note that you can, in turn, disable reflection if you enable a Java SecurityManager. See particularly the ReflectPermission. However, security managers are rarely used (outside the normal browser sandboxing).

回答6:

Obviously the principles of making everything private where possible only apply if you adhere to the open-closed principle otherwise if people get used to the idea of editing the internals of existing classes instead of extending them they may well change the encapsulation of private member variables be it through making them accessible through mutators and accessors or changing the access modifier.

回答7:

I think the meaning of "security" by your instructor was not about keeping hackers out, but rather keeping bugs out. By making everything as private as possible, you limit the ways that one class can mess with another class without it knowing. This is an example of Modular Programming.

回答8:

Btw: reflection in Java actually allows you to override access modifiers of fields of objects. See javadoc and an example.