search menu icon-carat-right cmu-wordmark

Top 10 Coding Guidelines for Java

Top 10 Coding Guidelines for Java
September 25, 2013 • Media Coverage

September 25, 2013—Java has become a vital component of mission-critical tasks for organizations around the world. To help highlight and remedy poor practices not addressed in the secure coding standard for Java, the SEI Secure Coding Team, with collaborators from outside the institute, have produced a second book, Java Coding Guidelines: 75 Recommendations for Reliable and Secure Programs. From among these 75 guidelines, authors Robert C. Seacord, senior member of the SEI technical staff and technical manager of the CERT Secure Coding Initiative, and Fred Long, senior lecturer in the Department of Computer Science, Aberystwyth University, U.K., selected 10 guidelines as particularly important for programmers working in Java.

The top 10 are

  • Guideline 18: Do not expose methods that use reduced-security checks to untrusted code. Certain methods use a reduced-security check that checks only that the calling method is authorized rather than checking every method in the call stack. Any code that invokes these methods must guarantee that they cannot be invoked on behalf of untrusted code.
  • Guideline 10: Do not use the clone()method to copy untrusted method parameters. Inappropriate use of the clone() method can allow an attacker to exploit vulnerabilities by providing arguments that appear normal but subsequently return unexpected values. Such objects may consequently bypass validation and security checks.
  • Guideline 25: Document thread-safety and use annotations where applicable. The Java language annotation facility is useful for documenting design intent. Source code annotation is a mechanism for associating metadata with a program element and making it available to the compiler, analyzers, debuggers, or Java Virtual Machine (JVM) for examination. Several annotations are available for documenting thread-safety or the lack thereof.
  • Guideline 29: Be aware of numeric promotion behavior. Promotions in which the operands are converted from an int to a float or from a long to a double can cause a loss of precision.
  • Guideline 43: Use a try-with-resources statement to safely handle closeable resources. Using the try-with-resources statement prevents problems that can arise when closing resources with an ordinary try-catch-finally block, such as failing to close a resource because an exception is thrown as a result of closing another resource, or masking an important exception when a resource is closed.
  • Guideline 45: Use the same type for the second and third operands in conditional expressions. The complexity of the rules that determine the result type of a conditional expression can result in unintended type conversions. Consequently, the second and third operands of each conditional expression should have identical types.
  • Guideline 57: Avoid inadvertent wrapping of loop counters. Unless coded properly, a while or for loop may execute forever, or until the counter wraps around and reaches its final value.
  • Guideline 64: Strive for logical completeness. Software vulnerabilities can result when a programmer fails to consider all possible data states.
  • Guideline 69: Do not confuse abstract object equality with reference equality. Naïve programmers often confuse the intent of the == operation with that of the Object.equals() method. This confusion is frequently evident in the context of processing of String objects.
  • Guideline 71: Understand how escape characters are interpreted when strings are loaded. Many classes allow inclusion of escape sequences in character and string literals. Correct use of escape sequences in string literals requires understanding how the escape sequences are interpreted by the Java compiler, as well as how they are interpreted by any subsequent processor.

In 2011, to help programmers eliminate insecure coding practices that can lead to exploitable vulnerabilities in Java, a team of SEI researchers on the CERT Secure Coding Team, in collaboration with experts at Oracle Corporation, produced The CERT® Oracle® Coding Standard for Java. While conducting the research that produced this secure coding standard, the team identified other poor Java coding practices that did not warrant inclusion but nevertheless could lead to unreliable or insecure programs.

"Although they are not included in The CERT® Oracle® Coding Standard for Java, these guidelines should not be considered less important," said Seacord. "Coding rules included in the standard must be narrowly defined. For instance, we had to exclude guidelines for which it was not possible to form a requirement strictly related to the standard. This is often the case when a rule depends on programmer intent, which cannot always be known. We also had to exclude guidelines for which compliance is a good idea, but noncompliance does not necessarily result in an error."

For each coding guideline presented in the book, the authors specify conformance requirements; for most, the authors offer noncompliant code examples and compliant solutions. The authors explain when to apply each guideline and provide references to even more detailed information. Java Coding Guidelines also presents updated techniques for protecting against deliberate attacks and other unexpected events, and best practices for improving code reliability and clarity. Intended primarily for software professionals working in Java Standard Edition (SE) 7 Platform environments, this guide is also useful to those working with Java Micro Edition (ME), Java Enterprise Edition (EE), and other contemporary Java-language platforms.

Writing in the book's introduction, James A. Gosling, the father of the Java programming language, said, "This set of Java™ Coding Guidelines, a follow-on to the earlier The CERT® Oracle® Secure Coding Standard for Java™, is invaluable. This book could almost be retitled Reliable Java™ Coding Guidelines…. There are all sorts of explicit security tools—cryptography, authentication, and others—but most break-ins are exploitations of bugs: coding that was badly done or that was insufficiently defensive. Building a reliable system is, in many ways, equivalent to building a secure system. The work you do in reliability pays off in security, and vice versa."

For more information about The CERT® Oracle® Coding Standard for Java, to review sample content, or to order, please visit

To learn more about the work of the CERT Secure Coding Team, please visit