Secure Coding Practices in Java

These secure coding practices were picked from the list maintained by Carnegie Mellon University Software Engineering Institute:
  1. DCL00-J. Prevent class initialization cycles
  2. DCL01-J. Do not reuse public identifiers from the Java Standard Library
  3. DCL02-J. Do not modify the collection's elements during an enhanced for statement

  4. DCL51-J. Do not shadow or obscure identifiers in subscopes
  5. DCL52-J. Do not declare more than one variable per declaration
  6. DCL53-J. Minimize the scope of variables
  7. DCL54-J. Use meaningful symbolic constants to represent literal values in program logic
  8. DCL55-J. Properly encode relationships in constant definitions
  9. DCL56-J. Do not attach significance to the ordinal associated with an enum

  10. EXP00-J. Do not ignore values returned by methods
  11. EXP01-J. Do not use a null in a case where an object is required
  12. EXP02-J. Do not use the Object.equals() method to compare two arrays
  13. EXP03-J. Do not use the equality operators when comparing values of boxed primitives
  14. EXP06-J. Expressions used in assertions must not produce side effects

  15. EXP50-J. Do not confuse abstract object equality with reference equality
  16. EXP51-J. Do not perform assignments in conditional expressions
  17. EXP52-J. Use braces for the body of an if, for, or while statement
  18. EXP53-J. Use parentheses for precedence of operation
  19. EXP55-J. Use the same type for the second and third operands in conditional expressions

  20. NUM00-J. Detect or prevent integer overflow
  21. NUM01-J. Do not perform bitwise and arithmetic operations on the same data
  22. NUM02-J. Ensure that division and remainder operations do not result in divide-by-zero errors
  23. NUM03-J. Use integer types that can fully represent the possible range of unsigned data
  24. NUM07-J. Do not attempt comparisons with NaN
  25. NUM08-J. Check floating-point inputs for exceptional values
  26. NUM09-J. Do not use floating-point variables as loop counters
  27. NUM10-J. Do not construct BigDecimal objects from floating-point literals
  28. NUM11-J. Do not compare or inspect the string representation of floating-point values
  29. NUM12-J. Ensure conversions of numeric types to narrower types do not result in lost or misinterpreted data
  30. NUM13-J. Avoid loss of precision when converting primitive integers to floating-point
  31. NUM14-J. Use shift operators correctly

  32. NUM50-J. Convert integers to floating point for floating-point operations

  33. STR01-J. Do not assume that a Java char fully represents a Unicode code point
  34. STR02-J. Specify an appropriate locale when comparing locale-dependent data

  35. OBJ01-J. Limit accessibility of fields
  36. OBJ04-J. Provide mutable classes with copy functionality to safely allow passing instances to untrusted code
  37. OBJ05-J. Do not return references to private mutable class members
  38. OBJ06-J. Defensively copy mutable inputs and mutable internal components
  39. OBJ07-J. Sensitive classes must not let themselves be copied
  40. OBJ09-J. Compare classes and not class names
  41. OBJ10-J. Do not use public static nonfinal fields
  42. OBJ11-J. Be wary of letting constructors throw exceptions
  43. OBJ13-J. Ensure that references to mutable objects are not exposed

  44. OBJ51-J. Minimize the accessibility of classes and their members

  45. MET00-J. Validate method arguments
  46. MET01-J. Never use assertions to validate method arguments
  47. MET03-J. Methods that perform a security check must be declared private or final
  48. MET04-J. Do not increase the accessibility of overridden or hidden methods
  49. MET05-J. Ensure that constructors do not call overridable methods
  50. MET06-J. Do not invoke overridable methods in clone()
  51. MET07-J. Never declare a class method that hides a method declared in a superclass or superinterface
  52. MET08-J. Preserve the equality contract when overriding the equals() method
  53. MET09-J. Classes that define an equals() method must also define a hashCode() method

  54. MET50-J. Avoid ambiguous or confusing uses of overloading
  55. MET51-J. Do not use overloaded methods to differentiate between runtime types
  56. MET53-J. Ensure that the clone() method calls super.clone()
  57. MET54-J. Always provide feedback about the resulting value of a method
  58. MET55-J. Return an empty array or collection instead of a null value for methods that return an array or collection

  59. ERR00-J. Do not suppress or ignore checked exceptions
  60. ERR01-J. Do not allow exceptions to expose sensitive information
  61. ERR03-J. Restore prior object state on method failure
  62. ERR04-J. Do not complete abruptly from a finally block
  63. ERR05-J. Do not let checked exceptions escape from a finally block
  64. ERR07-J. Do not throw RuntimeException, Exception, or Throwable
  65. ERR08-J. Do not catch NullPointerException or any of its ancestors

  66. ERR50-J. Use exceptions only for exceptional conditions
  67. ERR51-J. Prefer user-defined exceptions over more general exception types
  68. ERR52-J. Avoid in-band error indicators

  69. MSC02-J. Generate strong random numbers
  70. MSC03-J. Never hard code sensitive information
  71. MSC04-J. Do not leak memory
  72. MSC05-J. Do not exhaust heap space
  73. MSC06-J. Do not modify the underlying collection when an iteration is in progress

  74. MSC50-J. Minimize the scope of the @SuppressWarnings annotation
  75. MSC51-J. Do not place a semicolon immediately following an if, for, or while condition
  76. MSC54-J. Avoid inadvertent wrapping of loop counters
  77. MSC56-J. Detect and remove superfluous code and values
  78. MSC57-J. Strive for logical completeness
  79. MSC58-J. Prefer using iterators over enumerations
  80. MSC60-J. Do not use assertions to verify the absence of runtime errors
  81. MSC63-J. Ensure that SecureRandom is properly seeded