Sample Security Assessment

Target Information

CONFIDENTIAL

This report and its contents are confidential and intended solely for the addressee. Distribution outside Sample Client Ltd. requires written authorization.

Table of Contents

1. Executive Summary
2. Scope & Methodology
3. Findings Summary
4. Detailed Findings
5. Business Impact

1. Executive Summary

Sample Client Ltd. commissioned this assessment to evaluate the security posture of SampleApp, a consumer Android application that automatically tracks personal expenses by reading payment notifications from banking and wallet apps installed on the user's device. Because SampleApp processes financial transaction data and offers a paid subscription tier, testing focused on three questions that matter to the business, not only to engineering: can an attacker read, corrupt, or inject a user's financial data without consent; can the subscription revenue model be bypassed; and does the app's data handling create regulatory or reputational exposure.

Eight findings were identified, summarized below. Three are rated High and are directly exploitable by any unprivileged app installed on the same device — two of them without root access. All are reproducible with standard, publicly available tooling; none required custom exploit development.

The two most significant issues compound each other. A leftover debugging interface (F-01) shipped in the production build remains externally reachable by any app on the device, allowing arbitrary financial entries to be injected into a user's ledger with no user interaction. Separately, the premium subscription check (F-02) trusts a value stored unencrypted on the device rather than validating entitlement against Google Play, meaning the paid tier can be unlocked without payment.

Overall application risk: HIGH — driven primarily by F-01 and F-02. Remediating those two findings alone moves the application to a Medium overall rating.

2. Scope & Methodology

Testing followed a methodology aligned with the OWASP Mobile Application Security Testing Guide (MASTG): manifest/attack-surface mapping, static analysis of decompiled code (data flow, secrets, crypto, logging), dynamic instrumentation on a physical device, local storage and IPC review, network-layer review, and business-logic review of the subscription/entitlement path. Every finding below was manually reproduced with a proof-of-concept before inclusion in this report.

3. Findings Summary

4. Detailed Findings

F-01 — Exported Debug/Test Broadcast Receiver Allows Arbitrary Financial-Data Injection

The notification-listener service responsible for auto-tracking expenses registers a secondary broadcast receiver intended for internal QA that was left exported in the production build. Any other application on the device — no special permissions required — can send it a directed broadcast carrying attacker-controlled merchant, amount, and category values, which are written directly into the user's expense ledger, bypassing the normal notification-parsing pipeline entirely.

adb shell am broadcast -a com.example.sampleapp.TEST_PAYMENT \
  --es merchant "Fake Merchant" --es amount "9999.99"

Impact: zero-permission, zero-interaction corruption of the user's financial records; a direct hit to the app's core value proposition and a highly demonstrable finding for any external researcher.

Remediation:

• Remove the test/debug receiver from release builds, gated behind a debug build flavor.
• If a QA hook must remain, register it as non-exported with a signature-level permission.
• Add a CI check that fails the release build on exported components matching debug/test naming.

F-02 — Client-Side Premium Entitlement Enforcement — Subscription Bypass

Access to paid features is decided entirely by a boolean flag persisted locally, trusted for up to 7 days without re-validation against Google Play. Because the application also ships with full data backup enabled (F-05), the flag can be flipped using only adb, without root or device compromise.

adb backup -f b.ab -noapk com.example.sampleapp
# edit is_premium -> true inside the extracted preferences file
adb restore b.ab

Impact: unauthenticated bypass of the subscription revenue model, exploitable by any user with USB debugging enabled — a short, widely-documented setting change.

Remediation:

• Validate the Play purchase token server-side rather than trusting the on-device flag as sole source of truth.
• Re-validate entitlement on every app foreground event where connectivity is available.
• Exclude the entitlement store from the auto-backup set as an immediate, low-effort mitigation.

F-03 — Hardcoded Backend API Key Committed to the Application Package

Static analysis of the decompiled APK recovered a fully-formed backend API key embedded as a string constant and referenced directly from network-layer client code, rather than being retrieved from a backend-issued, user-scoped session token. Any party who downloads the APK can extract and reuse the key against the production backend.

Impact: depending on backend-side authorization, ranges from unauthorized data access to abuse of paid third-party services billed to the company. Because the key is static and shared across every install, it cannot be revoked for one abusive user without breaking the app for everyone.

Remediation:

• Never ship long-lived, broadly-scoped secrets inside the client binary; issue short-lived, user-scoped tokens from an authenticated backend session.
• Add a pre-release CI secret-scanning step against the built artifact, not only the source repository.

F-04 — Unencrypted Local Storage of Financial Transaction Data

Parsed transaction data — merchant names, amounts, categories — is persisted in plaintext across a local preferences store and the application's SQLite database, neither encrypted at rest. A diagnostic log additionally retains raw, unparsed notification text for entries the parser failed to interpret.

Impact: any actor with filesystem access — a rooted device, a lost/resold phone, or a device backup — can read a complete history of the user's spending behavior.

Remediation:

• Replace plaintext preferences for sensitive data with androidx.security EncryptedSharedPreferences.
• Encrypt the local database at rest (e.g., SQLCipher).
• Cap the diagnostic log's retention and strip raw notification text before persisting it.

F-05 — Full Application Backup Enabled Without Data-Exclusion Rules

android:allowBackup is set to true with no accompanying dataExtractionRules to exclude sensitive files. Combined with USB debugging, this allows the entire application sandbox — including the stores covered in F-02 and F-04 — to be extracted and modified using only standard Android SDK platform tools, no root required.

Impact: this finding is a force-multiplier — it is what turns F-02 and F-04 from "requires root" into "requires only a USB cable."

Remediation:

• Set allowBackup="false", or define explicit dataExtractionRules excluding the entitlement store and transaction database.

F-06 — Verbose Production Logging of Personally Identifiable and Financial Data

Extensive logging calls throughout the notification-processing pipeline emit full transaction details in cleartext to the system log — parsed amounts, merchant names, and in several places the complete raw source notification text — with no build-time stripping for release builds.

Impact: any connected debugging session or device with adb access enabled can passively capture a live stream of the user's financial activity without touching app storage directly.

Remediation:

• Strip or no-op logging calls in release builds via R8/ProGuard rules.
• Never log raw notification content, parsed amounts, or merchant data in code paths shipped to production.

F-07 — Uncontrolled Resource Consumption When Importing Shared Images

The screenshot-import share target decodes attacker-supplied images with no prior bounds check and no maximum-dimension enforcement, allowing a crafted image shared from any other app to force a large in-memory allocation and crash the application.

Remediation:

• Decode bounds first, enforce a maximum resolution, and use inSampleSize to downscale before full decode.

F-08 — Exported Widget Broadcast Receiver — Reviewed, No Exploitable Data Exposure

The home-screen widget provider is exported, which is required by the platform and not a defect by itself. Its custom actions were reviewed in detail: neither reads attacker-controlled Intent extras, and the only externally triggerable effect is cycling the widget's displayed view, gated behind the app's own premium-status check. Included to document that the component was specifically analyzed, not flagged by pattern-matching alone.

Remediation:

• No action required.

5. Business Impact

Revenue

F-02, compounded by F-05, is a direct and reproducible bypass of SampleApp's only monetization mechanism. Subscription-bypass methods for popular apps circulate quickly once discovered, typically packaged as a one-tap tool, and measurably suppress conversion once public.

Regulatory & Legal Exposure

SampleApp processes data that qualifies as sensitive personal data under GDPR. F-04 and F-05 together mean this data is not encrypted at rest and is extractable without root — a specific, named factor regulators weigh under Article 32 (security of processing) when assessing fines after a breach disclosure.

Trust & Distribution Risk

F-01 is the kind of finding that, if independently discovered, produces a public write-up with a working proof-of-concept in a single command — reputationally disproportionate to the engineering effort required to fix it. Google Play's Data Safety and policy review processes increasingly scrutinize this exact issue class.

Cost Asymmetry

Every finding in this report was fixable in hours to a few days of engineering work once identified. The cost of finding these issues proactively is a small fraction of the cost of an incident response or a regulatory inquiry after the fact.