Skip to main content




The SEI CERT® Oracle® Secure Coding Standard for Java™ provides rules designed to eliminate insecure coding practices that can lead to exploitable vulnerabilities. This standard, published in 2011, covers security issues.


DRD15-J. Consider privacy concerns when using Geolocation API213. Allow geographic location
DRD19-J. Properly verify server certificate on SSL/TLS336. Disable insecure TLS versions
ENV02-J. Do not trust the values of environment variables159. Obfuscate code
ENV06-J. Production code must not contain debugging entry points078. Disable debugging events
ERR01-J. Do not allow exceptions to expose sensitive information359. Avoid using generic exceptions
FIO00-J. Do not operate on files in shared directories046. Manage the integrity of critical files
280. Restrict service root directory
FIO01-J. Create files with appropriate access permissions186. Use the principle of least privilege
341. Use the principle of deny by default
FIO03-J. Remove temporary files before termination036. Do not deploy temporary files
177. Avoid caching and temporary files
FIO13-J. Do not log sensitive information outside a trust boundary083. Avoid logging sensitive data
FIO14-J. Perform proper cleanup at program termination183. Delete sensitive data securely
IDS00-J. Prevent SQL injection169. Use parameterized queries
173. Discard unsafe inputs
IDS01-J. Normalize strings before validating them172. Encrypt connection strings
IDS03-J. Do not log unsanitized user input080. Prevent log modification
IDS06-J. Exclude unsanitized user input from format strings083. Avoid logging sensitive data
IDS14-J. Do not trust the contents of hidden form fields030. Avoid object reutilization
032. Avoid session ID leakages
181. Transmit data using secure protocols
IDS16-J. Prevent XML injection173. Discard unsafe inputs
342. Validate request parameters
IDS17-J. Prevent XML External Entity attacks324. Control redirects
LCK11-J. Avoid client-side locking when using classes that do not commit to their locking strategy026. Encrypt client-side session information
320. Avoid client-side control enforcement
MET02-J. Do not use deprecated or obsolete classes or methods325. Protect WSDL files
MET03-J. Methods that perform a security check must be declared private or final158. Use a secure programming language
MSC00-J. Use SSLSocket rather than Socket for secure data exchange181. Transmit data using secure protocols
MSC02-J. Generate strong random numbers223. Uniform distribution in random numbers
MSC04-J. Do not leak memory164. Use optimized structures
MSC11-J. Do not let session information leak within a servlet026. Encrypt client-side session information
NUM00-J. Detect or prevent integer overflow345. Establish protections against overflows
OBJ10-J. Do not use public static nonfinal fields227. Display access notification
SEC04-J. Protect sensitive operations with security manager checks378. Use of log management system
380. Define a password management tool
SER02-J. Sign then seal objects before sending them outside a trust boundary151. Separate keys for encryption and signatures
178. Use digital signatures
SER12-J. Prevent deserialization of untrusted data321. Avoid deserializing untrusted data
STR31-C. Guarantee that storage for strings has sufficient space for character data and the null terminator044. Define an explicit charset
TSM00-J. Do not override thread-safe methods with methods that are not thread-safe337. Make critical logic flows thread safe
TSM02-J. Do not use background threads during class initialization346. Use initialization vectors once