Home / Attacks & tests / Inter-Process Communication (IPC) Security Testing for Mobile Applications
10 test cases
Inter-Process Communication (IPC) Security Testing for Mobile Applications
IPC testing examines the application's boundary with everything else on the device. Android applications are built from components that can be addressed by other applications, and each exported component is an entry point with the same standing as a network endpoint — but frequently without the same scrutiny.
What an attacker is trying to achieve
The attacker's code is already on the device, in an application the user installed for an unrelated reason and granted nothing special. They want to call the target's components directly, read what it broadcasts, feed it data it will trust, and reach the state it believes only its own interface can produce.
Test cases
10 test cases in this category. Each states what the test proves, how it is carried out, what has to be in place beforehand, what a positive result looks like, and whether the work is manual, automated or a mixture.
AND-IPC-01 User Data in the System Log
Objective — Determine whether personal or account data belonging to the user is written to the system log during ordinary operation.
How it is tested — Capture the log while driving each workflow that handles personal data — profile, messaging, payment, location, contacts — and search for that data in the capture. Include background operation and synchronisation, which log outside any user action. Establish whether logging is suppressed in release builds and whether bundled components log independently of the application's own calls.
Prerequisites — A device with log access; the release build; an account populated with recognisable personal data.
Indicators — Personal data in the log; background synchronisation logging record content; a bundled component logging independently; logging present in a release build.
Coverage — MASVS-PRIVACY-1MASVS-STORAGE-2CWE-532CWE-359
Depth — Hybrid Capture and search automate; exercising the background paths does not.
AND-IPC-02 Technical Data in the System Log
Objective — Determine whether the log discloses technical material that assists an attack: tokens, endpoints, keys, internal identifiers and stack traces.
How it is tested — Capture the log across authentication, error and retry paths, and search for session material, request and response bodies, and internal detail. Provoke failures deliberately, since exception handlers log most fully. Establish whether any logged value is directly reusable — a bearer token in the log is a credential available to anything that can read it.
Prerequisites — A device with log access; the ability to provoke error paths, including by interrupting connectivity; a proxy for correlating logged values against real traffic.
Indicators — A session token or key in the log; full request or response bodies logged; stack traces disclosing internal structure; a logged value that can be replayed against the server.
Coverage — MASVS-STORAGE-2MASVS-AUTH-1CWE-532CWE-522
Depth — Hybrid Searching automates; establishing that a logged value is still valid requires replaying it.
AND-IPC-03 Exposed Components and Cross-Application Authorization
Objective — Determine which of the application's components can be invoked by other applications, and whether each enforces its own authorisation rather than relying on being unreachable.
How it is tested — Enumerate exported components from the manifest, including those exported implicitly by declaring a filter. From an unprivileged test application, invoke each with the parameters the decompiled code shows it expects. Establish whether the component verifies the caller's identity or permission, and what state it can be driven into. Pay particular attention to components that continue an authenticated flow.
Prerequisites — The manifest and decompiled code; a device; a second application holding no relevant permissions.
Indicators — An exported component invoked by an unprivileged caller; a component continuing an authenticated flow without verifying the caller; a state reachable externally that the interface guards.
Coverage — MASVS-PLATFORM-1MASVS-AUTH-1CWE-926CWE-862
Depth — Manual Requires building a caller that supplies what each component expects.
AND-IPC-04 Permission and Signature Data Sharing
Objective — Determine whether the permissions guarding the application's components and shared data are strong enough to exclude an arbitrary application on the device.
How it is tested — Review each custom permission the application defines and the protection level assigned to it. Establish whether components rely on a permission any application may request rather than one restricted to matching signatures. Test whether a permission can be defined first by another application, and whether components shared with the vendor's other applications assume a trust relationship the platform does not enforce.
Prerequisites — The manifest; a device; a test application able to declare permissions and to be installed before the target.
Indicators — A custom permission at a level any application may hold; a component protected only by such a permission; a permission definable by another application first; cross-application trust assumed without signature verification.
Coverage — MASVS-PLATFORM-1MASVS-AUTH-1CWE-276CWE-732
Depth — Manual Protection levels have to be read against what each guards; the install-order case needs deliberate sequencing.
AND-IPC-05 Clipboard Separation
Objective — Determine whether the application places sensitive values on the system clipboard, where any application on the device can read them.
How it is tested — Exercise every path that copies — explicit copy actions, one-time code auto-fill, share flows, and fields the application populates for convenience — and read the clipboard from a separate application afterwards. Establish whether sensitive fields are excluded from copy at all, whether clipboard content is cleared after a period, and whether pasted content is trusted when read back.
Prerequisites — A device; a second application able to read the clipboard; an account with sensitive values such as codes or credentials.
Indicators — A credential, token or code readable from the clipboard by another application; clipboard content persisting indefinitely; sensitive fields copyable without restriction.
Coverage — MASVS-PLATFORM-3MASVS-STORAGE-2CWE-200CWE-359
Depth — Manual Confirmation requires reading the clipboard from outside the application.
AND-IPC-06 Public Intents and Unauthenticated Data Sources
Objective — Determine whether data arriving through inter-application messaging is validated, or trusted because it arrived through a channel the application assumes only its own components use.
How it is tested — For each component accepting external messages, send payloads whose fields are absent, malformed, oversized or of unexpected types, and observe handling. Send values that would be trusted if they came from the application's own flow — identifiers, destinations, state markers — and establish whether the receiving code re-validates them. Include messages sent while the application is in an unexpected state.
Prerequisites — A test application able to send arbitrary messages; the expected payload structure from the decompiled code; a device with log access to observe handling.
Indicators — A crash from a malformed message; an externally supplied identifier or destination acted on without validation; state changed by a message the application assumed came from itself.
Coverage — MASVS-PLATFORM-1MASVS-CODE-4CWE-20CWE-940
Depth — Manual Payloads have to be constructed to match what each component expects, which comes from reading the code.
AND-IPC-07 Public Intents and Authorization Flaws
Objective — Determine whether inter-application messaging can be used to reach functionality that the application's own interface protects.
How it is tested — Identify components that perform or continue privileged operations and invoke them directly from an unprivileged caller, supplying the state the interface would have established. Establish whether authorisation is checked at the component or only earlier in the interface flow. Test whether messages the application sends can be intercepted by another application registering the same filter, and whether sensitive data travels in them.
Prerequisites — A test application able both to send messages and to register competing filters; the component inventory; a device.
Indicators — A privileged operation reached by direct invocation; authorisation checked in the interface but not the component; a message intercepted by a competing receiver; sensitive data in an interceptable message.
Coverage — MASVS-PLATFORM-1MASVS-AUTH-1CWE-926CWE-285
Depth — Manual The interception case requires a second application competing for the same messages, which is not something a static review shows.
AND-IPC-08 Code Puzzling and Application State Abuse
Objective — Determine whether the application can be driven into a state its own navigation cannot reach, by invoking its components out of the intended order.
How it is tested — Map the states the interface can produce and the component sequence that produces each. Then invoke components directly in orders the interface never uses: a post-authentication screen before authenticating, a confirmation before its preceding step, a resumption without an originating session. Establish whether each component verifies the preconditions it depends on or assumes them from the navigation that normally precedes it.
Prerequisites — The component inventory and expected parameters; a test application able to invoke them in arbitrary order; a device.
Indicators — An authenticated screen reachable without authenticating; a confirmation completing without its preceding step; state assembled by direct invocation that the interface guards.
Coverage — MASVS-PLATFORM-1MASVS-AUTH-2CWE-841CWE-287
Depth — Manual The whole test is ordering, which requires understanding the intended sequence before it can be broken.
AND-IPC-09 Race Conditions and Concurrency
Objective — Determine whether the application behaves correctly when its components are invoked concurrently rather than in the sequence its interface produces.
How it is tested — Invoke the same component repeatedly and simultaneously from a test application, and invoke components that share state in parallel. Concentrate on operations that should be exclusive — consuming a one-time value, completing a payment, applying a state transition — and establish whether exclusivity is enforced or merely implied by the interface's ordering. Observe for deadlocks and unresponsiveness as well as duplicated effects.
Prerequisites — A test application able to issue genuinely concurrent invocations; a device; the ability to observe the resulting state.
Indicators — An exclusive operation completing twice; state inconsistent after concurrent invocation; the application deadlocking or becoming unresponsive; a one-time value consumed more than once.
Coverage — MASVS-PLATFORM-1MASVS-CODE-4CWE-367CWE-662
Depth — Manual Concurrency has to be arranged deliberately; nothing in ordinary use produces it.
AND-IPC-10 On-Device Denial of Service
Objective — Determine whether another application on the device can render the target application unusable through the interfaces it exposes.
How it is tested — Send malformed, oversized and unexpected payloads to each exported component and observe whether the application crashes rather than rejecting them. Invoke components repeatedly at volume to establish whether resource use is bounded. Test whether a component can be made to hold a lock, occupy the main thread, or leave persistent state that prevents the application from starting cleanly afterwards.
Prerequisites — A test application; a device where the target can be reinstalled after being rendered unusable; the exported component list.
Indicators — A crash from an external message; the application failing to start after receiving one; unbounded resource use under repeated invocation; a persistent state that prevents recovery.
Coverage — MASVS-PLATFORM-1MASVS-CODE-4CWE-400CWE-20
Depth — Manual The persistent-state case is only visible if the application is restarted after the attack, which is a deliberate step.
What we need from you
A device or emulator; the manifest and decompiled package; a second unprivileged application under the tester's control to act as the caller; and log access for the disclosure cases.
Standards this category maps to
Every identifier below is quoted from the published control list it belongs to. Where a test has no defensible mapping, none is given rather than an approximate one.
- MASVS-PRIVACY-1 — The app minimizes access to sensitive data and resources.
- MASVS-STORAGE-2 — The app prevents leakage of sensitive data.
- CWE-532 — Insertion of Sensitive Information into Log File
- CWE-359 — Exposure of Private Personal Information to an Unauthorized Actor
- MASVS-AUTH-1 — The app uses secure authentication and authorization protocols and follows the relevant best practices.
- CWE-522 — Insufficiently Protected Credentials
- MASVS-PLATFORM-1 — The app uses IPC mechanisms securely.
- CWE-926 — Improper Export of Android Application Components
- CWE-862 — Missing Authorization
- CWE-276 — Incorrect Default Permissions
- CWE-732 — Incorrect Permission Assignment for Critical Resource
- MASVS-PLATFORM-3 — The app uses the user interface securely.
- CWE-200 — Exposure of Sensitive Information to an Unauthorized Actor
- MASVS-CODE-4 — The app validates and sanitizes all untrusted inputs.
- CWE-20 — Improper Input Validation
- CWE-940 — Improper Verification of Source of a Communication Channel
- CWE-285 — Improper Authorization
- MASVS-AUTH-2 — The app performs local authentication securely according to the platform best practices.
- CWE-841 — Improper Enforcement of Behavioral Workflow
- CWE-287 — Improper Authentication
- CWE-367 — Time-of-check Time-of-use (TOCTOU) Race Condition
- CWE-662 — Improper Synchronization
- CWE-400 — Uncontrolled Resource Consumption
Tell us what the system does and what worries you.
If a penetration test is not what you need yet, we will say so.