Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migrated to Confluence 4.0

...

** To reference a protected member, the accessing code must be contained in either the class that defines the protected member or in a subclass of that defining class. Subclass access is permitted without regard to the package location of the subclass.

Wiki MarkupClasses and class members must be given the minimum possible access so that malicious code has the least opportunity to compromise security. As far as possible, classes should avoid exposing methods that contain (or invoke) [sensitive code|java:BB. Glossary#sensitive code] through interfaces; interfaces allow only publicly accessible methods, and such methods are part of the public application programming interface (API) of the class. (Note that this is the opposite of Bloch's recommendation to prefer interfaces for APIs \ [[Bloch 2008|AA. References#Bloch 08], Item 16\].) One exception to this is implementing an _unmodifiable_ interface that exposes a public immutable view of a mutable object. (See [OBJ04-J. Provide mutable classes with copy functionality to safely allow passing instances to untrusted code].) Additionally, note that even if a nonfinal class's visibility is default, it can be susceptible to misuse if it contains public methods. Methods that perform all necessary security checks, as well as sanitize all inputs, can also be exposed through interfaces.

Protected accessibility is invalid for top-level classes; nested classes may be declared protected. Fields of nonfinal public classes should rarely be declared protected; untrusted code in another package can subclass the class and access the member. Furthermore, protected members are part of the API of the class and consequently require continued support. When this rule is followed, there is no need to declare a field as protected. OBJ01-J. Declare data members as private and provide accessible wrapper methods recommends declaring fields as private.

...

Secure Coding Guidelines for the Java Programming Language, Version 3.0

Guideline 1-1 Limit the accessibility of classes, interfaces, methods, and fields

Bibliography

<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="815d694d-6fab-47ae-b016-e5df82ea25d3"><ac:plain-text-body><![CDATA [ [[Bloch 2008AA. References#Bloch 08] ]

Item 13: Minimize the accessibility of classes and members; Item 16: Prefer interfaces to abstract classes ]]></ac:plain-text-body></ac:structured-macro><ac:

structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="f5ec75b7-9df6-46ae-b675-a16d339eb20d"><ac:plain-text-body><![CDATA [ [[Campione 1996AA. References#Campione 96] ]

[Access Control

http://www.telecom.ntua.gr/HTML.Tutorials/java/javaOO/accesscontrol.html]

]]></ac:plain-text-body></ac:structured-macro>

<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="edde582c-342e-4519-aa81-860dbba99434"><ac:plain-text-body><![CDATA[

[[JLS 2005AA. References#JLS 05] ]

[§6.6, Access Controlhttp://java.sun.com/docs/books/jls/third_edition/html/names.html#6.6]

]]></ac:plain-text-body></ac:structured-macro>

<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="ba3cff62-d11f-4725-afc1-f8463bf8e411"><ac:plain-text-body><! [CDATA[ [[McGraw 1999AA. References#McGraw 99]]

Chapter 3, Java Language Security Constructs ]]></ac:plain-text-body></ac:structured-macro>

...

OBJ01-J. Declare data members as private and provide accessible wrapper methods      04. Object Orientation (OBJ)      OBJ03-J. Do not mix generic with nongeneric raw types in new code