All Guidelines with Classification

Guidelines

Security

This chapter contains guidelines that are concerned specifically with ensuring security of Java-based applications. They are concerned with issues such as

1. Dealing with sensitive data.
2. Avoiding common injection attacks.
3. Language features that can be misused to compromise security.
4. Details of Java's fine-grained security mechanism.

• FIO52-J. Do not store unencrypted sensitive information on the client side
• IDS51-J. Properly encode or escape output
• IDS52-J. Prevent code injection
• IDS53-J. Prevent XPath Injection
• IDS54-J. Prevent LDAP injection
• IDS56-J. Prevent arbitrary file upload
• MET52-J. Do not use the clone() method to copy untrusted method parameters
• MET56-J. Do not use Object.equals() to compare cryptographic keys
• MSC59-J. Limit the lifetime of sensitive data
• MSC61-J. Do not use insecure or weak cryptographic algorithms
• MSC62-J. Store passwords using a hash function
• MSC63-J. Ensure that SecureRandom is properly seeded
• OBJ56-J. Provide sensitive mutable classes with unmodifiable wrappers
• OBJ57-J. Do not rely on methods that can be overridden by untrusted code
• SEC50-J. Avoid granting excess privileges
• SEC51-J. Minimize privileged code
• SEC52-J. Do not expose methods that use reduced-security checks to untrusted code
• SEC53-J. Define custom security permissions for fine-grained security
• SEC54-J. Create a secure sandbox using a security manager
• SEC55-J. Ensure that security-sensitive methods are called with validated arguments
• SEC57-J. Do not let untrusted code misuse privileges of callback methods

Defensive Programming

This chapter contains guidelines for defensive programming. Defensive programming is carefully guarded programming that helps you to construct reliable software by designing each component to protect itself as much as possible, for example, by checking that undocumented assumptions remain valid [ Goodliffe 2006 ] . These guidelines address areas of the Java language that can help to constrain the effect of an error or help to recover from an error.

• CON52-J. Document thread-safety and use annotations where applicable
• DCL53-J. Minimize the scope of variables
• DCL56-J. Do not attach significance to the ordinal associated with an enum
• DCL58-J. Enable compile-time type checking of variable arity parameter types
• DCL59-J. Do not apply public final to constants whose value might change in later releases
• DCL60-J. Avoid cyclic dependencies between packages
• ERR51-J. Prefer user-defined exceptions over more general exception types
• ERR53-J. Try to gracefully recover from system errors
• FIO51-J. Identify files using multiple file attributes
• MET54-J. Always provide feedback about the resulting value of a method
• MSC50-J. Minimize the scope of the @SuppressWarnings annotation
• MSC53-J. Carefully design interfaces before releasing them
• NUM52-J. Be aware of numeric promotion behavior
• OBJ51-J. Minimize the accessibility of classes and their members
• OBJ52-J. Write garbage-collection-friendly code

Best Practices

This chapter includes guidelines that

1. Are essential for ensuring correctness of Java code.
2. Contain specific, implementation-level Java coding advice.
3. Have a higher normative requirement than the defensive programming category.

The guidelines deal with generally low-level Java language features that can easily be misused by the unwary.

• DCL51-J. Do not shadow or obscure identifiers in subscopes
• DCL52-J. Do not declare more than one variable per declaration
• DCL54-J. Use meaningful symbolic constants to represent literal values in program logic
• DCL55-J. Properly encode relationships in constant definitions
• ERR50-J. Use exceptions only for exceptional conditions
• ERR54-J. Use a try-with-resources statement to safely handle closeable resources
• EXP55-J. Use the same type for the second and third operands in conditional expressions
• MET55-J. Return an empty array or collection instead of a null value for methods that return an array or collection
• MSC58-J. Prefer using iterators over enumerations
• MSC60-J. Do not use assertions to verify the absence of runtime errors
• OBJ53-J. Do not use direct buffers for short-lived, infrequently used objects
• OBJ55-J. Remove short-lived objects from long-lived container objects
• SEC56-J. Do not serialize direct handles to system resources

Program Understandability

Program understandability is the ease with which the program can be understood—that is, the ability to determine what a program does and how it works by reading its source code and accompanying documentation [ Grubb 2013 ]. Another term used to describe this property of source code is readability . Understandable code is easier to maintain because software maintainers are less likely to introduce defects into code that is clear and comprehensible. Understandability helps in manual analysis of source code because it allows the auditor to more easily spot defects and vulnerabilities.

The guidelines in this chapter are mainly stylistic in nature; they will help a Java programmer to write clearer, more readable code.

• DCL50-J. Use visually distinct identifiers
• DCL57-J. Avoid ambiguous overloading of variable arity methods
• ERR52-J. Avoid in-band error indicators
• EXP51-J. Do not perform assignments in conditional expressions
• EXP52-J. Use braces for the body of an if, for, or while statement
• EXP53-J. Use parentheses for precedence of operation
• FIO50-J. Do not make assumptions about file creation
• MET53-J. Ensure that the clone() method calls super.clone()
• MSC51-J. Do not place a semicolon immediately following an if, for, or while condition
• MSC52-J. Finish every set of statements associated with a case label with a break statement
• MSC54-J. Avoid inadvertent wrapping of loop counters
• MSC55-J. Use comments consistently and in a readable fashion
• MSC56-J. Detect and remove superfluous code and values
• MSC57-J. Strive for logical completeness
• NUM50-J. Convert integers to floating point for floating-point operations

Programmer Misconceptions

This chapter contains guidelines that address

1. Misconceptions about Java APIs and language features.
2. Assumptions and ambiguity-laced programs.
3. Situations in which the programmer wanted to do x but ended up doing y.

They address areas where developers often make unwarranted assumptions about how Java works or where ambiguities can easily be introduced.

• CON50-J. Do not assume that declaring a reference volatile guarantees safe publication of the members of the referenced object
• CON51-J. Do not assume that the sleep(), yield(), or getState() methods provide synchronization semantics
• EXP50-J. Do not confuse abstract object equality with reference equality
• EXP54-J. Understand the differences between bitwise and logical operators
• FIO53-J. Use the serialization methods writeUnshared() and readUnshared() with care
• IDS55-J. Understand how escape characters are interpreted when strings are loaded
• MET50-J. Avoid ambiguous or confusing uses of overloading
• MET51-J. Do not use overloaded methods to differentiate between runtime types
• NUM51-J. Do not assume that the remainder operator always returns a nonnegative result for integral operands
• OBJ50-J. Never confuse the immutability of a reference with that of the referenced object
• OBJ54-J. Do not attempt to help the garbage collector by setting local reference variables to null