In OO programming courses, teachers always tells us to set class members to private unless there is a good reason because it is more "secured".

How does setting members to private makes the program more secure? What are the potential threats for setting class members public?

  • 2
    This has nothing to do with security. Object-oriented programming relies on hiding implementation details from those who re-use code (other legit programmers), leaving those who implemented the original classes free to change the implementation without breaking compile-time compatibility. An evil blackhat who reverse-engineered the code and found a buffer overflow will not pay any heed to the distinction between public and private. There may be corner cases when the system is written in several languages, and vulnerable scripts are exploited to get at an OO-based library through a binding. Commented Mar 10, 2013 at 8:42
  • 4
    The only time private might have a security effect is if you run managed code with different privileges withing a single process, where the privileged code needs to protect itself against low trust code. The reason typical reason for using private is encapsulation, not security. Commented Mar 10, 2013 at 8:44

3 Answers 3


Actually putting a class member on public or private has nothing to do with security. This answer on stackoverflow covers it quite well:

What are public, private and protected in object oriented programming?

Also note that there are languages like Python where there is just a convention to start private methods with an underscore. However every programmer can still access this method from another class. This Stackoverflow question covers this pretty well: Why are Python's 'private' methods not actually private?


There are limited, specific situations where field visibility has an impact. I am talking about Java applets. An unsigned Java applet can only do limited system interactions (no access to local files, no connection to external servers except the one which served the applet code, and so on). These restrictions are enforced through a complex framework of "permissions" which is implemented... in the Java code of the standard library.

If an applet could access private fields of arbitrary Java objects from other packages, then it could fiddle with the objects and tables which define the current permissions for the applet itself. In effect, the right to use the reflection API on all classes (including system classes) technically grants all rights to the applet.

This does not mean that the field visibility keywords like private or protected are a security feature; it means that the designers at Sun/Oracle used field visibility to implement and support a security framework (and, in my opinion, they should have done it otherwise, because doing it that way is like trying to maintain a black list of "dangerous calls" on thousands of possible calls, and it is very hard work, and the recurrent apparition of Java 0-day exploits is a testimony to the hardness of such an approach).

For most other situations, object fields should be made private because it promotes better software engineering practices, making for code which is easier to maintain (like all rules, that one has exceptions; occasionally, a public field is a better idea). There is nothing about security here; it is about usability and maintainability.


If we declare class members as private it can be accessed only inside the class. So if we look through the view-point of security, declaring it as private secures the class members.

  • Member methods cannot be accessed using the objects if they are declared as private.

  • Member variables cannot be accessed if they are private.

So in programs if you have to keep some values as secret, like encryption-keys, others credentials, it has to declared as private. In some cases if you are writing method for authentication, making them as private will add-up a little level of security.

  • 1
    Maximin welcome to Information Security! I am guessing from your answer that you are new to the field of security... Have you read the other answers here? Directly contradictory to yours, this is very wrong. I suggest you read a bit more around the site to learn the subject, and always read the other answers before adding your own. Good luck!
    – AviD
    Commented Mar 12, 2013 at 9:51
  • @AviD I am extremely sorry. I was just pointing only on the access security alone.
    – Maximin
    Commented Mar 12, 2013 at 9:56
  • No need to be sorry, we're all here to learn :-). But my point is that it still doesnt help the access security either at all. Other classes can still use reflection to easily access any member (method or property), even private ones, and can steal the secret values. There is no security value in marking members private.
    – AviD
    Commented Mar 12, 2013 at 10:45
  • Thank you. Helped me to learn something new. I was wrong.
    – Maximin
    Commented Mar 12, 2013 at 11:21
  • Maximin that makes it a good day. :-)
    – AviD
    Commented Mar 12, 2013 at 11:34

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .