Log in

Spaces

Hit enter to search
Help
Log in

Pages

Space shortcuts

Dashboard
Secure Coding Home
Android
C
C++
Java
Perl

Page tree

Browse pages

- Attachments (0)
- Page History

Pages
Android Secure Coding Standard
4 By Language
Java Coding Language

Jira links

Applicable to Android (Java Rules/Recomendations)

Created by Barbara White, last updated by Sandy Shrum on May 07, 2015 1 minute read

Rules

Page:

DCL00-J. Prevent class initialization cycles
Page:

DCL01-J. Do not reuse public identifiers from the Java Standard Library
Page:

DCL02-J. Do not modify the collection's elements during an enhanced for statement
Page:

ERR00-J. Do not suppress or ignore checked exceptions
Page:

ERR01-J. Do not allow exceptions to expose sensitive information
Page:

ERR02-J. Prevent exceptions while logging data
Page:

ERR03-J. Restore prior object state on method failure
Page:

ERR04-J. Do not complete abruptly from a finally block
Page:

ERR05-J. Do not let checked exceptions escape from a finally block
Page:

ERR06-J. Do not throw undeclared checked exceptions
Page:

ERR07-J. Do not throw RuntimeException, Exception, or Throwable
Page:

ERR08-J. Do not catch NullPointerException or any of its ancestors
Page:

EXP00-J. Do not ignore values returned by methods
Page:

EXP02-J. Do not use the Object.equals() method to compare two arrays
Page:

FIO02-J. Detect and handle file-related errors
Page:

FIO03-J. Remove temporary files before termination
Page:

FIO05-J. Do not expose buffers or their backing arrays methods to untrusted code
Page:

FIO07-J. Do not let external processes block on IO buffers
Page:

FIO09-J. Do not rely on the write() method to output integers outside the range 0 to 255
Page:

FIO10-J. Ensure the array is filled when using read() to fill an array
Page:

FIO12-J. Provide methods to read and write little-endian data
Page:

IDS03-J. Do not log unsanitized user input
Page:

IDS06-J. Exclude unsanitized user input from format strings
Page:

IDS08-J. Sanitize untrusted data included in a regular expression
Page:

IDS11-J. Perform any string modifications before validation
Page:

JNI00-J. Define wrappers around native methods
Page:

JNI02-J. Do not assume object references are constant or unique
Page:

JNI04-J. Do not assume that Java strings are null-terminated
Page:

LCK01-J. Do not synchronize on objects that may be reused
Page:

LCK02-J. Do not synchronize on the class object returned by getClass()
Page:

LCK03-J. Do not synchronize on the intrinsic locks of high-level concurrency objects
Page:

LCK04-J. Do not synchronize on a collection view if the backing collection is accessible
Page:

LCK06-J. Do not use an instance lock to protect shared static data
Page:

LCK07-J. Avoid deadlock by requesting and releasing locks in the same order
Page:

LCK08-J. Ensure actively held locks are released on exceptional conditions
Page:

LCK09-J. Do not perform operations that can block while holding a lock
Page:

LCK10-J. Use a correct form of the double-checked locking idiom
Page:

MET00-J. Validate method arguments
Page:

MET04-J. Do not increase the accessibility of overridden or hidden methods
Page:

MET05-J. Ensure that constructors do not call overridable methods
Page:

MET06-J. Do not invoke overridable methods in clone()
Page:

MET07-J. Never declare a class method that hides a method declared in a superclass or superinterface
Page:

MET08-J. Preserve the equality contract when overriding the equals() method
Page:

MET09-J. Classes that define an equals() method must also define a hashCode() method
Page:

MET10-J. Follow the general contract when implementing the compareTo() method
Page:

MET11-J. Ensure that keys used in comparison operations are immutable
Page:

MET12-J. Do not use finalizers
Page:

MSC00-J. Use SSLSocket rather than Socket for secure data exchange
Page:

MSC01-J. Do not use an empty infinite loop
Page:

MSC02-J. Generate strong random numbers
Page:

MSC04-J. Do not leak memory
Page:

MSC05-J. Do not exhaust heap space
Page:

MSC06-J. Do not modify the underlying collection when an iteration is in progress
Page:

MSC07-J. Prevent multiple instantiations of singleton objects
Page:

NUM01-J. Do not perform bitwise and arithmetic operations on the same data
Page:

NUM02-J. Ensure that division and remainder operations do not result in divide-by-zero errors
Page:

NUM03-J. Use integer types that can fully represent the possible range of unsigned data
Page:

NUM07-J. Do not attempt comparisons with NaN
Page:

NUM08-J. Check floating-point inputs for exceptional values
Page:

NUM09-J. Do not use floating-point variables as loop counters
Page:

NUM10-J. Do not construct BigDecimal objects from floating-point literals
Page:

NUM12-J. Ensure conversions of numeric types to narrower types do not result in lost or misinterpreted data
Page:

NUM13-J. Avoid loss of precision when converting primitive integers to floating-point
Page:

OBJ01-J. Limit accessibility of fields
Page:

OBJ02-J. Preserve dependencies in subclasses when changing superclasses
Page:

OBJ04-J. Provide mutable classes with copy functionality to safely allow passing instances to untrusted code
Page:

OBJ05-J. Do not return references to private mutable class members
Page:

OBJ06-J. Defensively copy mutable inputs and mutable internal components
Page:

OBJ07-J. Sensitive classes must not let themselves be copied
Page:

OBJ08-J. Do not expose private members of an outer class from within a nested class
Page:

OBJ09-J. Compare classes and not class names
Page:

OBJ10-J. Do not use public static nonfinal fields
Page:

OBJ11-J. Be wary of letting constructors throw exceptions
Page:

SER00-J. Enable serialization compatibility during class evolution
Page:

SER01-J. Do not deviate from the proper signatures of serialization methods
Page:

SER02-J. Sign then seal objects before sending them outside a trust boundary
Page:

SER03-J. Do not serialize unencrypted sensitive data
Page:

SER05-J. Do not serialize instances of inner classes
Page:

SER06-J. Make defensive copies of private mutable components during deserialization
Page:

SER07-J. Do not use the default serialized form for classes with implementation-defined invariants
Page:

SER08-J. Minimize privileges before deserializing from a privileged context
Page:

SER09-J. Do not invoke overridable methods from the readObject() method
Page:

SER10-J. Avoid memory and resource leaks during serialization
Page:

SER11-J. Prevent overwriting of externalizable objects
Page:

STR03-J. Do not encode noncharacter data as a string
Page:

THI01-J. Do not invoke ThreadGroup methods
Page:

TSM03-J. Do not publish partially initialized objects
Page:

VNA00-J. Ensure visibility when accessing shared primitive variables
Page:

VNA01-J. Ensure visibility of shared references to immutable objects
Page:

VNA02-J. Ensure that compound operations on shared variables are atomic
Page:

VNA03-J. Do not assume that a group of calls to independently atomic methods is atomic
Page:

VNA04-J. Ensure that calls to chained methods are atomic
Page:

VNA05-J. Ensure atomicity when reading and writing 64-bit values

Recommendations

Page:

CON50-J. Do not assume that declaring a reference volatile guarantees safe publication of the members of the referenced object
Page:

CON51-J. Do not assume that the sleep(), yield(), or getState() methods provide synchronization semantics
Page:

CON52-J. Document thread-safety and use annotations where applicable
Page:

DCL50-J. Use visually distinct identifiers
Page:

DCL51-J. Do not shadow or obscure identifiers in subscopes
Page:

DCL52-J. Do not declare more than one variable per declaration
Page:

DCL53-J. Minimize the scope of variables
Page:

DCL54-J. Use meaningful symbolic constants to represent literal values in program logic
Page:

DCL55-J. Properly encode relationships in constant definitions
Page:

DCL56-J. Do not attach significance to the ordinal associated with an enum
Page:

DCL57-J. Avoid ambiguous overloading of variable arity methods
Page:

DCL58-J. Enable compile-time type checking of variable arity parameter types
Page:

DCL59-J. Do not apply public final to constants whose value might change in later releases
Page:

DCL60-J. Avoid cyclic dependencies between packages
Page:

ERR50-J. Use exceptions only for exceptional conditions
Page:

ERR51-J. Prefer user-defined exceptions over more general exception types
Page:

ERR52-J. Avoid in-band error indicators
Page:

ERR53-J. Try to gracefully recover from system errors
Page:

EXP50-J. Do not confuse abstract object equality with reference equality
Page:

EXP51-J. Do not perform assignments in conditional expressions
Page:

EXP52-J. Use braces for the body of an if, for, or while statement
Page:

EXP53-J. Use parentheses for precedence of operation
Page:

EXP54-J. Understand the differences between bitwise and logical operators
Page:

EXP55-J. Use the same type for the second and third operands in conditional expressions
Page:

FIO52-J. Do not store unencrypted sensitive information on the client side
Page:

FIO53-J. Use the serialization methods writeUnshared() and readUnshared() with care
Page:

IDS53-J. Prevent XPath Injection
Page:

IDS55-J. Understand how escape characters are interpreted when strings are loaded
Page:

MET50-J. Avoid ambiguous or confusing uses of overloading
Page:

MET51-J. Do not use overloaded methods to differentiate between runtime types
Page:

MET52-J. Do not use the clone() method to copy untrusted method parameters
Page:

MET53-J. Ensure that the clone() method calls super.clone()
Page:

MET54-J. Always provide feedback about the resulting value of a method
Page:

MET55-J. Return an empty array or collection instead of a null value for methods that return an array or collection
Page:

MET56-J. Do not use Object.equals() to compare cryptographic keys
Page:

MSC50-J. Minimize the scope of the @SuppressWarnings annotation
Page:

MSC51-J. Do not place a semicolon immediately following an if, for, or while condition
Page:

MSC52-J. Finish every set of statements associated with a case label with a break statement
Page:

MSC53-J. Carefully design interfaces before releasing them
Page:

MSC54-J. Avoid inadvertent wrapping of loop counters
Page:

MSC55-J. Use comments consistently and in a readable fashion
Page:

MSC56-J. Detect and remove superfluous code and values
Page:

MSC57-J. Strive for logical completeness
Page:

MSC58-J. Prefer using iterators over enumerations
Page:

MSC61-J. Do not use insecure or weak cryptographic algorithms
Page:

MSC62-J. Store passwords using a hash function
Page:

MSC63-J. Ensure that SecureRandom is properly seeded
Page:

NUM50-J. Convert integers to floating point for floating-point operations
Page:

NUM51-J. Do not assume that the remainder operator always returns a nonnegative result for integral operands
Page:

NUM52-J. Be aware of numeric promotion behavior
Page:

NUM54-J. Do not use denormalized numbers
Page:

OBJ50-J. Never confuse the immutability of a reference with that of the referenced object
Page:

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

OBJ52-J. Write garbage-collection-friendly code
Page:

OBJ53-J. Do not use direct buffers for short-lived, infrequently used objects
Page:

OBJ54-J. Do not attempt to help the garbage collector by setting local reference variables to null
Page:

OBJ55-J. Remove short-lived objects from long-lived container objects
Page:

OBJ57-J. Do not rely on methods that can be overridden by untrusted code
Page:

OBJ58-J. Limit the extensibility of classes and methods with invariants
Page:

SEC56-J. Do not serialize direct handles to system resources

applicability-list
java

Overview

Content Tools

Powered by Atlassian Confluence 9.2.13
Printed by Atlassian Confluence 9.2.13
Report a bug
Atlassian News

Carnegie Mellon University
Software Engineering Institute
4500 Fifth Avenue
Pittsburgh, PA 15213-2612
412-268-5800

Office Locations|
Additional Sites Directory|
Legal|
Privacy Notice|
CMU Ethics Hotline|
www.sei.cmu.edu

©2025 Carnegie Mellon University

{"serverDuration": 172, "requestCorrelationId": "8e6e1df86b134345"}