Guideline | Applicable to Android Application Development? | |
| MSC59-J. Limit the lifetime of sensitive data | Applicable in principle | The non-compliant code example is probably not problematic on Dalvik because each app has its own Dalvik VM and string objects would not be accessible from other apps (?) |
| FIO52-J. Do not store unencrypted sensitive information on the client side | Applicable | |
| OBJ56-J. Provide sensitive mutable classes with unmodifiable wrappers | Unknown | ? |
| SEC55-J. Ensure security-sensitive methods are called with validated arguments | Applicable in principle | On Android, accessControlContext is not available. |
| IDS56-J. Prevent arbitrary file upload | Applicable in principle | |
| IDS51-J. Properly encode or escape output | Applicable in principle | |
| IDS52-J. Prevent code injection | Applicable in principle | ScriptEngineManager is not included in the Android SDK. |
| IDS53-J. Prevent XPath Injection | Applicable | |
| IDS54-J. Prevent LDAP injection | Applicable in principle | Applicable in principle for android apps that tries to implement its own LDAP |
| MET52-J. Do not use the clone method to copy untrusted method parameters | Applicable | |
MET56-J. Do not use Object.equals() to compare cryptographic keys | Applicable | |
| MSC61-J. Do not use insecure or weak cryptographic algorithms | Applicable | |
| MSC62-J. Store passwords using a hash function | Applicable | |
MSC63-J. Ensure SecureRandom is properly seeded | Applicable | |
| OBJ57-J. Do not rely on overridden methods provided by untrusted code | Applicable | |
| SEC50-J. Avoid granting excess privileges | Applicable in principle | The brief phrase for the guideline applies to Android. However, the current extended-text description for the guideline in the hardcopy book does not apply to Android, because Android does not use AccessController. The following text supplements that section, to make it applicable to Android.: An application should use as few "<uses-permission>"s in AndroidManifest.xml as possible. App developers should also avoid signature/system/dangerous permissions, and having a shared system UID. System API calls are code running as system, and apps which make system API calls require standard permissions the app must specify in the application manifest with "<uses-permission>". http://developer.android.com/guide/topics/manifest/uses-permission-element.html |
| SEC51-J. Minimize privileged code | Applicable in principle | The brief phrase for the guideline applies to Android. However, the current extended-text description for the guideline in the hardcopy book does not apply to Android, because Android does not use AccessController. The following text supplements that section, to make it applicable to Android.: Minimize the code running as system, with permissions defined in another app’s manifest, or in shared user ID applications. System API calls are code running as system, and apps which make system API calls require standard permissions the app must specify in the application manifest with "<uses-permission>". Only applications which are signed with the same signature and also request the same sharedUserID are granted a shared user ID. Data/files stored by apps which share a user ID are accessible to all those apps.http://developer.android.com/guide/topics/security/permissions.html http://developer.android.com/guide/topics/manifest/uses-permission-element.html |
| SEC52-J. Do not expose methods that use reduced-security checks to untrusted code | Not applicable | |
| SEC53-J. Define custom security permissions for fine-grained security | Applicable in principle | The brief phrase for the guideline applies to Android. However, the current extended-text description for the guideline in the hardcopy book does not apply to Android. The following text supplements that section, to make it applicable to Android.: Applications are able to define their own new permissions, to restrict access to their components by other applications. Applications indicate the procedure the system should follow when determining whether to grant another app the permission, depending on protectionLevel – e.g., setting protectionLevel to “signature” so it is automatically granted to other applications requesting the permission which are signed with the same key. In addition to defining their own new permissions, applications can declare the requirement for (self-defined, other-app-defined, or system-defined) permissions, to restrict access to their components by other applications. |
| SEC54-J. Create a secure sandbox using a security manager | Not applicable | |
| SEC57-J. Do not let untrusted code misuse privileges of callback methods | Unknown | |
| DCL53-J. Minimize the scope of variables | Applicable | |
MSC50-J. Minimize the scope of the @SuppressWarnings annotation | Applicable | |
| OBJ51-J. Minimize the accessibility of classes and their members | Applicable | |
| CON52-J. Document thread-safety and use annotations where applicable | Applicable | |
| MET54-J. Always provide feedback about the resulting value of a method | Applicable | |
| FIO51-J. Identify files using multiple file attributes | Applicable in principle | On Android, better to use openFileOutput/openFileInput for file I/O. |
| DCL56-J. Do not attach significance to the ordinal associated with an enum | Applicable | |
| NUM52-J. Be aware of numeric promotion behavior | Applicable | |
| DCL58-J. Enable compile-time type checking of variable arity parameter types | Applicable | |
| DCL59-J. Do not apply public final to constants whose value might change in later releases | Applicable | |
| DCL60-J. Avoid cyclic dependencies between packages | Applicable | |
| ERR51-J. Prefer user-defined exceptions over more general exception types | Applicable | |
| ERR53-J. Try to gracefully recover from system errors | Applicable | |
| MSC53-J. Carefully design interfaces before releasing them | Applicable | |
| OBJ52-J. Write garbage-collection-friendly code | Applicable | |
| DCL51-J. Do not shadow or obscure identifiers in subscopes | Applicable | |
| DCL52-J. Do not declare more than one variable per declaration | Applicable | |
| DCL54-J. Use meaningful symbolic constants to represent literal values in program logic | Applicable | |
| DCL55-J. Properly encode relationships in constant definitions | Applicable | |
| MET55-J. Return an empty array or collection instead of a null value for methods that return an array or collection | Applicable | |
| ERR50-J. Use exceptions only for exceptional conditions | Applicable | |
ERR54-J. Use a try-with-resources statement to safely handle closeable resources | Not applicable | The current Android SDK does not support Java7, thus try-with-resource is not available |
| MSC60-J. Do not use assertions to verify the absence of runtime errors | Applicable in principle | On Android, assert() is ignored by default. |
| EXP55-J. Use the same type for the second and third operands in conditional expressions | Applicable | |
| SEC56-J. Do not serialize direct handles to system resources | Applicable | |
| MSC58-J. Prefer using iterators over enumerations | Applicable | |
| OBJ53-J. Do not use direct buffers for short-lived, infrequently used objects | Applicable | |
| OBJ55-J. Remove short-lived objects from long-lived container objects | Applicable | |
| DCL50-J. Be careful using visually misleading identifiers and literals | Applicable | |
| DCL57-J. Avoid ambiguous overloading of variable arity methods | Applicable | |
| ERR52-J. Avoid in-band error indicators | Applicable | |
| EXP51-J. Do not perform assignments in conditional expressions | Applicable | |
| EXP52-J. Use braces for the body of an if, for, or while statement | Applicable | |
| MSC51-J. Do not place a semicolon immediately following an if, for, or while condition | Applicable | |
| MSC52-J. Finish every set of statements associated with a case label with a break statement | Applicable | |
| MSC54-J. Avoid inadvertent wrapping of loop counters | Applicable | |
| EXP53-J. Use parentheses for precedence of operation | Applicable | |
| FIO50-J. Do not make assumptions about file creation | Applicable in principle | On Android, java.nio.file is not available. |
| NUM50-J. Convert integers to floating-point for floating-point operations | Applicable | |
MET53-J. Ensure that the clone() method calls super.clone() | Applicable | |
| MSC55-J. Use comments consistently and in a readable fashion | Applicable | |
| MSC56-J. Detect and remove superfluous code and values | Applicable | |
| MSC57-J. Strive for logical completeness | Applicable | |
| CON50-J. Do not assume that declaring a reference volatile guarantees safe publication of the members of the referenced object | Applicable | |
CON51-J. Do not assume that the sleep(), yield(), or getState() methods provide synchronization semantics | Applicable | |
| NUM51-J. Do not assume that the remainder operator always returns a nonnegative result for integral operands | Applicable | |
| EXP50-J. Do not confuse abstract object equality with reference equality | Applicable | |
| EXP54-J. Understand the differences between bitwise and logical operators | Applicable | |
| IDS55-J. Understand how escape characters are interpreted when strings are loaded | Applicable | |
| MET50-J. Avoid ambiguous or confusing uses of overloading | Applicable | |
| MET51-J. Do not use overloaded methods to differentiate between runtime types | Applicable | |
| OBJ50-J. Never confuse the immutability of a reference with that of the referenced object | Applicable | |
FIO53-J. Use the serialization methods writeUnshared() and readUnshared() with care | Applicable | |
OBJ54-J. Do not attempt to help the garbage collector by setting local reference variables to null | Applicable | |
