Android components
Intents, storage, permissions, WebView and inter-app communication.
Trust boundaries in Android Intent redirection
Launching an Intent received from another application can process external input with your application's privileges.
Read the guideContentProvider access and data exposure
ContentProvider can expose application data to other processes. Excessive access can disclose personal information despite strong code protection.
Read the guideNarrowly scoped file sharing with FileProvider
Sharing should expose the document a recipient needs, not the application's entire filesystem. FileProvider helps manage that boundary.
Read the guideBroadcastReceiver and incoming-message validation
Receiving a broadcast does not make its content trustworthy. Receivers that initiate sensitive work need source and authorization checks.
Read the guideBound Service security and caller authorization
Bound services expose functions across applications. Exporting a service creates a need for access checks on its methods too.
Read the guideSignature-based trust with Android custom permissions
Custom permissions restrict component access under defined conditions. Naming a permission does not establish the correct protection level.
Read the guideLimiting sensitive data in the Android clipboard
Copied content leaves the application's screen boundary. The clipboard is unsuitable storage for session tokens, secret keys or persistent credentials.
Read the guideMinimizing data in Android notifications
Notifications may appear on lock screens, connected devices or history. Protecting the application screen does not protect every copy.
Read the guideHow scoped storage affects application data
Storage location determines which applications and user actions can reach data. Scoped storage is part of that access model.
Read the guideDocument permissions with the Storage Access Framework
Selecting a document grants access to a resource, not unrestricted trust in its contents. Treat the returned URI as external input.
Read the guideProtection boundaries in Room databases
Room organizes data access; it does not automatically encrypt the database. Assess why each sensitive field must be stored.
Read the guideIs DataStore a secure secrets vault?
DataStore manages small application datasets. Convenient preference storage does not automatically make it suitable for tokens or cryptographic keys.
Read the guideChecking Logcat for sensitive information
Logs aid development but create another exposure surface when they contain headers or personal data. Define production logging policy explicitly.
Read the guideChecking debuggable in release packages
Development settings can broaden inspection and tampering access if shipped. Check the final manifest, not only the source file.
Read the guideReducing Android cleartext traffic exceptions
Unencrypted connections expose data to observation or modification. One legacy endpoint can affect a sensitive flow.
Read the guideWebView file access and local content
Combining local files and remote content in a WebView can blur trust boundaries. Restrict file settings to actual needs.
Read the guideOrigin validation for WebView messages
Web content that can call native functions has substantial power. Missing origin validation can expose that power to unintended content.
Read the guidePackage visibility and Android security SDKs
Android limits what applications can query about other installed packages. These rules affect security SDK detection coverage.
Read the guideSafe, usable behavior after permission denial
Permission refusal requires both a security decision and a usable product flow. Refusal alone is not an attack signal.
Read the guideBinding BiometricPrompt to a cryptographic operation
A successful biometric dialog and biometric authorization of key use provide different security properties. That distinction matters for sensitive actions.
Read the guideData boundaries between work and personal profiles
Work profiles help separate enterprise applications and data from personal use. Sharing flows must preserve that boundary.
Read the guideSecurity in Android tasks and activity flows
Task stacks and activity launches affect which screen users see and in what context. Review more than the contents of individual screens.
Read the guideSafe paths when extracting archives
ZIP entry names are not trusted filesystem paths. Extraction must remain within the application's permitted destination.
Read the guideTrust boundaries in Android data parsing
Turning files, Intents or network data into application objects creates an attack surface. Constrain input before it reaches the parser.
Read the guideMemory safety in Android native code
JNI and native libraries can improve performance while introducing memory-management risks. Managed-code checks do not automatically cover them.
Read the guide