Why is java secure coding important?

I'm having trouble understanding why java secure coding is important. For example, why is it important to declare variables private? I mean I get that it will make it impossible to access those variables from outside the class, but I could simply decompile the class to get the value. Similarly, defining a class as final will make it impossible to subclass this class. When would subclassing a class be dangerous for security? Again if necessary, I could decompile the original class and reimplement it with whatever malicious code I could want. Does the problem come when applications are "trusted" by the user? And people could then abuse this trust somehow? Basically what I'm looking for is a good example as to why secure coding guidelines should be followed.

From stackoverflow

• Programming is hard.

  If you define strict APIs, that don't expose variables that are not supposed to be exposed (we like to call this encapsulation), you help users of your APIs, and thus make programming easier. This is considered a good thing.

  The reasons are not primarily "security", as in keeping secret things secret, as much as clarity, simplicity, and understandability.

  As a bonus, it's far easier to make things work correctly if you can know that the user of the API is not changing "your" variables behind your back, of course.

• It is "secure" meaning that a class internal working are hidden to whoever uses it.

  The term secure is not used as in "securing a server" is used to intend the fact that a user of one class does not have to worry about how the class will perform the task he wants it to.

  Taking your example:

  Exposing variables of a class would let the user of your class know of their existance, which is something you don't want, for example: you just press a button to turn on the light, you don't need to now that inside there is copper or whater it needs to perform the task.

• Just to add to what others have already said: Some of these features can also simply be viewed as a way to state intend. If I make a member private I make it "impossible" for others to access it (it is possible, but that's besides the point here), but more importantly I tell the users that this is an implementation detail, that they should not rely upon.

• There are two issues here.

  The first when declaring variables as protected or private, they won't become part of your public API. Other classes may depend on your class in the future, and it is important that you are free to change as much as possible if you want to include new features, improve performance, etc. If all of your values are public than all of your internal values and mechanisms are public. Changing them may break other classes which depend on yours.

  The second, is that when exposing variables it allows other classes to change your values. If they change your internal values if may break your program, and create strange unexpected behavior. If you create a system which relies on the accurate performance of one your classes, and the internal values are changed, than you can no longer rely on that system. Subclassing makes this more complicated. Your system may rely on a class of a certain type to perform expected actions. By subclassing it is possible to create a new class that appears to be the same type but does not perform the expected actions.

  For example, if you have a class square with a protected function getArea(), you expect to to return the area of a square. However, a new class can be made which extends square, say class rectangle extends square. Now rectange can override getArea(), but it is still of type square, which may break something which depends on that functionality of square. By making your class final you are asserting that this can never occur in your system.

  This type of "secure coding" will not prevent someone from seeing your source code, but it helps to make your code more reliable and usable in the future.

  Tom Hawtin - tackline : protected variables are part of the public API. Use private or, if you must, some "package private" default access variables.

• Java is an object-oriented programming langauge, and one of the key concepts in object-oriented programming is encapsulation.

  The idea behind encapsulation is to "hide away" the implementation details such as internal variables which hold the state of the object and the internal workings such as algorithms, and only provide an interface that other objects can use in order to perform functions with the object.

  Using that concept, one would like to hide internal states by using private variables to prevent other objects from directly affecting the internal states. In Java, it is common to see getters and setters (e.g. getColor and setColor) in order to work with objects.

  Also, encapsulation can increase the robustness of code as well.

  For example, by restricting access to the internal states, it would be possible to perform some sanity checks before an object is altered.

  As a solid example, say there was a Score object that was to have a percent value between 0 and 100. By providing a setPercent(int) method which validates that the specified value was within the permissible range, it would prevent the Score object from being set into an unacceptable state.

  So, trying to directly manipulate the internal state by writing a statement like score.percent = 150 could be prevented, if the setPercent method causes an error or throws an Exception if the specified value is unacceptable.

• just imagine if your object has internal property which is not private (hidden) and your code accessing this property happen to be run in multithreading environment, so N threads would start to access it simultaneously, 5 threads would like to change this property, 4 to read. There is no way you make sure things will run neatly, neither thread will know which data it holds in the moment and did it successfully changed property of that object.

  You will have to program special piece of code which will be responsible to handle synchronous access and still that will no be guarrantee your code will work right since you still have to check rest of 680 classes in your program accessing that property not to access it directly.

  In short, you are in a huge problem, and debugging is a nightmare since you do not know when the data was chagned, which thread did that, from where it happend etc.

  Just one scenario of what is happening if you do not encapsulate...

  Good thing, your code runs 1% faster, there is less load on stack, you've achieved probably negligible performance gains which you will pay with periodic crashes of system and minor chances for successfull debugging.

• The term "secure coding" refers to construction of software that clearly attempts to avoid security vulnerabilities, whether in C, Java, Ruby, assembly language, or anything else. Perhaps the most central part of that, after selecting a secure language system, is to keep to good programming practices. If a program is unclear, then you have little chance of it being worthy of any confidence.

  For Java there are two notable guides:

  • Secure Coding Guidelines for the Java Programming Language, version 2.0. Updated two years ago, and in need of an update.
  • The CERT Sun Microsystems Secure Coding Standard for Java. A new wiki supported by both CERT and Sun which can be updated with whatever you feel is important. This takes a much broader view than the Sun guidelines. For instance, the Sun guidelines aren't really concerned with integer overflow because all array bounds are checked, but the wiki does because it can still cause program errors.

  In Java there are two distinct modes of secure coding.

  In one you are dealing with code that may not have all the privileges that your code does. For instance if you are writing a library or signing code you need to be doing this. It should be impossible for malicious code to take advantage of your permissions in unintended ways. This is difficult!

  More commonly you are dealing with programs that are dealing with only untrusted data. For instance, web servers (think XSS and SQL injection) and desktop application programs dealing with untrusted files (usually the problem is with C code having buffer overflows - genuine C++ is better). In some situations denial of service (DoS) can be a severe issue.

  There is some overlap. For instance interpreters run with the permissions of the interpreter code and may be quite "powerful".