CERT JAVA Rule Enforcement
(website 28 April 2020)
Android Rules are not included.
ENFORCEMENT FOR KW 2023.3
Total Number of Rules
Total Number of ‘Not Statically Enforceable’ Rules (Assisted/Unassisted)
Total Number of Enforceable Rules (a-b)
Total Number of Enforced Rules
Total Number of Unenforced Rules
Enforce Rules Percentage (d/c)
Unenforced Rules Percentage (e/c)
Input Validation and Data Sanitization (IDS)
Prevent SQL injection.
Normalize strings before validating them.
Canonicalize path names before validating them.
Do not log unsanitized user input.
Safely extract files from ZipInputStream.
Use a safe subset of ASCII for file and path names.
Exclude unsanitized user input from format strings.
Sanitize untrusted data passed to the Runtime.exec() method.
Sanitize untrusted data included in a regular expression.
Specify an appropriate locale when comparing locale-dependent data.
Don't form strings containing partial characters.
Perform any string modifications before validation.
Use compatible character encodings on both sides of file or network IO.
Do not trust the contents of hidden form fields.
Do not allow sensitive information to leak outside a trust boundary.
Prevent XML Injection.
Prevent XML External Entity Attacks.
Declarations and Initialization (DCL)
Prevent class initialization cycles.
Do not reuse public identifiers from the Java Standard Library.
Do not modify the collection's elements during an enhanced for statement.
Do not ignore values returned by methods.
Do not use a null in a case where an object is required.
Do not use the Object.equals() method to compare two arrays.
Do not use the equality operators when comparing values of boxed primitives.
Do not pass arguments to certain Java Collections Framework methods that are a different type than the collection parameter type.
Do not follow a write by a subsequent write or read of the same object within an expression.
Expressions used in assertions must not produce side effects.
Prevent loss of useful data due to weak references.
Numeric Types and Operations (NUM)
Detect or prevent integer overflow.
Do not perform bitwise and arithmetic operations on the same data.
Ensure that division and remainder operations do not result in divide-by-zero errors.
Use integer types that can fully represent the possible range of unsigned data.
Do not use floating-point numbers if precise computation is required.
Do not attempt comparisons with NaN.
Check floating-point inputs for exceptional values.
Do not use floating-point variables as loop counters.
Do not construct BigDecimal objects from floating-point literals.
Do not compare or inspect the string representation of floating-point values.
Ensure conversions of numeric types to narrower types do not result in lost or misinterpreted data.
Avoid loss of precision when converting primitive integers to floating-point.
Use shift operators correctly.
Characters and Strings (STR)
Don't form strings containing partial characters from variable-width encodings.
Do not assume that a Java char fully represents a Unicode code point.
Specify an appropriate locale when comparing locale-dependent data.
Do not encode noncharacter data as a string.
Use compatible character encodings when communicating string data between JVMs.
Object Orientation (OBJ)
Limit accessibility of fields.
Preserve dependencies in subclasses when changing superclasses.
Prevent heap pollution.
Provide mutable classes with copy functionality to safely allow passing instances to untrusted code.
Do not return references to private mutable class members.
Defensively copy mutable inputs and mutable internal components.
Sensitive classes must not let themselves be copied.
Do not expose private members of an outer class from within a nested class.
Compare classes and not class names.
Do not use public static nonfinal fields.
Be wary of letting constructors throw exceptions.
Respect object-based annotations.
Ensure that references to mutable objects are not exposed.
Do not use an object that has been freed.
Validate method arguments.
Never use assertions to validate method arguments.
Do not use deprecated or obsolete classes or methods.
Methods that perform a security check must be declared private or final.
Do not increase the accessibility of overridden or hidden methods.
Ensure that constructors do not call overridable methods.
Do not invoke overridable methods in clone().
Never declare a class method that hides a method declared in a superclass or superinterface.
Preserve the equality contract when overriding the equals() method.
Classes that define an equals() method must also define a hashCode() method.
Follow the general contract when implementing the compareTo() method.
Ensure that keys used in comparison operations are immutable.
Do not use finalizers.
Do not assume that reassigning method arguments modifies the calling environment.
Exceptional Behavior (ERR)
Do not suppress or ignore checked exceptions.
Do not allow exceptions to expose sensitive information.
Prevent exceptions while logging data.
Restore prior object state on method failure.
Do not complete abruptly from a finally block.
Do not let checked exceptions escape from a finally block.
Do not throw undeclared checked exceptions.
Do not throw RuntimeException, Exception, or Throwable.
Do not catch NullPointerException or any of its ancestors.
Do not allow untrusted code to terminate the JVM.
Visibility and Atomicity (VNA)
Ensure visibility when accessing shared primitive variables.
Ensure visibility of shared references to immutable objects.
Ensure that compound operations on shared variables are atomic.
Do not assume that a group of calls to independently atomic methods is atomic.
Ensure that calls to chained methods are atomic.
Ensure atomicity when reading and writing 64-bit values.
Use private final lock objects to synchronize classes that may interact with untrusted code.
Do not synchronize on objects that may be reused.
Do not synchronize on the class object returned by getClass().
Do not synchronize on the intrinsic locks of high-level concurrency objects.
Do not synchronize on a collection view if the backing collection is accessible.
Synchronize access to static fields that can be modified by untrusted code.
Do not use an instance lock to protect shared static data.
Avoid deadlock by requesting and releasing locks in the same order.
Ensure actively held locks are released on exceptional conditions.
Do not perform operations that can block while holding a lock.
Use a correct form of the double-checked locking idiom.
Avoid client-side locking when using classes that do not commit to their locking strategy.
Thread APIs (THI)
Do not invoke Thread.run().
Do not invoke ThreadGroup methods.
Notify all waiting threads rather than a single thread.
Always invoke wait() and await() methods inside a loop.
Ensure that threads performing blocking operations can be terminated.
Do not use Thread.stop() to terminate threads.
Thread Pools (TPS)
Use thread pools to enable graceful degradation of service during traffic bursts.
Do not execute interdependent tasks in a bounded thread pool.
Ensure that tasks submitted to a thread pool are interruptible.
Ensure that tasks executing in a thread pool do not fail silently.
Ensure ThreadLocal variables are reinitialized when using thread pools.
Thread-Safety Miscellaneous (TSM)
Do not override thread-safe methods with methods that are not thread-safe.
Do not let the this reference escape during object construction.
Do not use background threads during class initialization.
Do not publish partially initialized objects.
Input Output (FIO)
Do not operate on files in shared directories.
Create files with appropriate access permissions.
Detect and handle file-related errors.
Remove temporary files before termination.
Release resources when they are no longer needed.
Do not expose buffers or their backing arrays methods to untrusted code.
Do not create multiple buffered wrappers on a single byte or character stream.
Do not let external processes block on IO buffers.
Distinguish between characters or bytes read from a stream and -1.
Do not rely on the write() method to output integers outside the range 0 to 255.
Ensure the array is filled when using read() to fill an array.
Do not convert between strings and bytes without specifying a valid character encoding.
Provide methods to read and write little-endian data.
Do not log sensitive information outside a trust boundary.
Perform proper cleanup at program termination.
Do not reset a servlet's output stream after committing it.
Canonicalize path names before validating them.
Enable serialization compatibility during class evolution.
Do not deviate from the proper signatures of serialization methods.
Sign then seal objects before sending them outside a trust boundary.
Do not serialize unencrypted sensitive data.
Do not allow serialization and deserialization to bypass the security manager.
Do not serialize instances of inner classes.
Make defensive copies of private mutable components during deserialization.
Do not use the default serialized form for classes with implementation-defined invariants.
Minimize privileges before deserializing from a privileged context.
Do not invoke overridable methods from the readObject() method.
Avoid memory and resource leaks during serialization.
Prevent overwriting of externalizable objects.
Prevent deserialization of untrusted data.
Deserialization methods should not perform potentially dangerous operations.
Platform Security (SEC)
Do not allow privileged blocks to leak sensitive information across a trust boundary.
Do not allow tainted variables in privileged blocks.
Do not base security checks on untrusted sources.
Do not load trusted classes after allowing untrusted code to load arbitrary classes.
Protect sensitive operations with security manager checks.
Do not use reflection to increase accessibility of classes, methods, or fields.
Do not rely on the default automatic signature verification provided by URLClassLoader and java.util.jar.
Call the superclass's getPermissions() method when writing a custom class loader.
Trusted code must discard or clean any arguments provided by untrusted code.
Never leak the results of certain standard API methods from trusted code to untrusted code.
Never permit untrusted code to invoke any API that may (possibly transitively) invoke the reflection APIs.
Runtime Environment (ENV)
Do not sign code that performs only unprivileged operations.
Place all security-sensitive code in a single JAR and sign and seal it.
Do not trust the values of environment variables.
Do not grant dangerous combinations of permissions.
Do not disable bytecode verification.
Do not deploy an application that can be remotely monitored.
Production code must not contain debugging entry points.
Java Native Interface (JNI)
Define wrappers around native methods.
Safely invoke standard APIs that perform tasks using the immediate caller's class loader instance (loadLibrary).
Do not assume object references are constant or unique.
Do not use direct pointers to Java objects in JNI code.
Do not assume that Java strings are null-terminated.
Use SSLSocket rather than Socket for secure data exchange.
Do not use an empty infinite loop.
Generate strong random numbers.
Never hard code sensitive information.
Do not leak memory.
Do not exhaust heap space.
Do not modify the underlying collection when an iteration is in progress.
Prevent multiple instantiations of singleton objects.
Do not store nonserializable objects as attributes in an HTTP session.
For OAuth, ensure (a) [relying party receiving user's ID in last step] is same as (b) [relying party the access token was granted to].
Do not use OAuth 2.0 implicit grant (unmodified) for authentication.
Do not let session information leak within a servlet.