CODEWITHSUNDEEP
javaoop
calebds
calebds

Reputation: 26228

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":

What private is good for:

Upvotes: 16

Views: 3618

Answers (8)

DNA
DNA

Reputation: 42597

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).

Upvotes: 1

david a.
david a.

Reputation: 5291

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

Upvotes: 0

Brian
Brian

Reputation: 76

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.

Upvotes: 0

Sergey Kalinichenko
Sergey Kalinichenko

Reputation: 726509

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.

Upvotes: 1

alex.p
alex.p

Reputation: 2739

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.

Upvotes: 0

Alex D
Alex D

Reputation: 30445

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.

Upvotes: 3

Dave Newton
Dave Newton

Reputation: 160191

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.)

Upvotes: 1

Jim Kiley
Jim Kiley

Reputation: 3652

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).

Upvotes: 9

Related Questions