PCI DSS and Mobile Apps: A Simple Guide | Oversecured Blog

What it is

An Oversecured guide to PCI DSS v4.0.1 for Android and iOS apps. It supplies what the standard omits: which in-app flaws put which requirement at risk. The standard states outcomes (unreadable stored data, strong cryptography in transit, access control) and never names mobile weak points.

How it works

The page maps finding types from mobile scans to requirements:

• Req 3 (stored data): backup allowed, sensitive data in logs, passwords stored on the device. Hardcoded keys and weak algorithms hit 3.5.1 and 3.6.1.
• Req 4.2.1 (transit): cleartext HTTP, and flawed host validation or address substitution, where encryption protects a connection to the wrong endpoint.
• Req 7 (access): arbitrary content provider access, implicit activity and broadcast intents that disclose data, exported activities. A malicious app with no special permissions can read your files, and no server-side control sees it.
• Req 6.2.4 and 6.3.2 (code): code loaded from third-party package contexts, WebView XSS, file access from file URLs, intent redirection, unsafe FileProvider paths.
• Req 2.2.1 and 2.2.4 (build): a release build with the debuggable attribute set to true. This matters most for APKs distributed outside app stores.

Three cases show that vendor code is still your finding:

• Cleartext in a native library. http:// endpoints were string constants inside a vendor .so (lib/arm64-v8a/lib<vendor>.so). They appeared in neither Java code nor the network security configuration, so source review misses them. Traffic to them also requires the cleartext check to be disabled.
• Hardcoded key and IV in SDK code. Analytics and payment SDKs passed literals to CryptoUtils.encrypt(input, key, iv). A variant used an embedded byte array as an HMAC secret.
• Implicit Intent. new Intent(action, uri) passed to startActivity is offered to every installed app with a matching filter, along with the URI and extras.

Preconditions / Affected

Scope is wider than storing card numbers. The page puts an app in scope if it:

• renders a card entry screen;
• passes card data to an SDK or backend;
• shows a saved card, even masked;
• holds the session for an account where cards are stored.

Redirecting to a provider's hosted page or an external wallet keeps card data out of the app process. The code stays in scope under Req 6.

What to do

• Test the binary customers install, not a source snapshot or an old build.
• Keep the 6.3.2 inventory of bespoke software and third-party components, including every SDK, current with each release.
• Identify and rank new vulnerabilities in those components (6.3.1).
• Exclude sensitive files with backup rules.
• Hand payment off to a hosted page or wallet where possible.

Caveats

• Version 4.0 was retired at the end of 2024, and all future-dated requirements became mandatory on 31 March 2025.
• The page says an annual assessment cycle cannot keep up with an app that ships every two weeks.
• The cases are anonymized, with no app or library names.
• The page gives no commands, detection queries or tool configuration.