Security Cases : Android Development

This time, I would like to discuss some of the common security issues that Android developers often face. These problems are more frequent among junior developers, but even senior developers may encounter them if they are not careful.

For example:
When storing app data in local storage, encryption, decryption, and authentication should be carefully managed. While storing data this way may improve app performance, it can also attract hackers and put users at risk.

Developers should also pay attention to the way APIs are handled.

Another issue is reverse engineering. This method is very useful for hackers, so developers must be extra cautious. When releasing an app, it is always recommended to use obfuscation methods.

Developers should also be careful when using outdated SDKs and libraries, as they can introduce vulnerabilities.

These are just some of the common issues. In this blog, I am sharing insights and experiences related to Android security.

 

Case 1: Sideloaded APK Disaster

In early 2025, a fintech startup distributed a sideloaded APK for internal testing, which unintentionally exposed sensitive user data. The app was intended only for QA (Quality Assurance), but it lacked basic security measures — no encryption, no obfuscation, and no access controls. When the APK leaked, attackers reverse‑engineered it and exploited its vulnerabilities to steal user credentials and transaction logs. This incident is still ongoing today, which makes it a serious reminder to stay vigilant.

 

Real‑World Parallel: CVE‑2025‑22442
A major vulnerability was discovered in the Android Work Profile setup process. During initialization, sideloading restrictions were not enforced, allowing malicious actors to inject unauthorized apps before enterprise policies were applied. This flaw affected all Android versions prior to Android 16 and was especially dangerous in corporate environments.

 

Why Sideloading Is Risky in 2025
According to the 2025 Global Mobile Threat Report, 23.5% of enterprise devices contain sideloaded apps. Most of these are repackaged versions of legitimate apps with malicious code embedded. Since they bypass Play Store vetting, they are commonly used for:

• Data exfiltration
• Credential harvesting
• Surveillance and spyware injection
• Privilege escalation attacks

If you are handling an enterprise app, this is something you must pay close attention to.

 

Developer Mistakes That Lead to Disasters

• Hardcoded API keys and tokens
• Verbose logging of sensitive data
• Unencrypted local storage
• No certificate pinning or HTTPS enforcement
• Lack of runtime permission checks

Example of what not to do:

`java
// Dangerous logging
Log.d(“UserInfo”, “Email: ” + userEmail + “, Password: ” + userPassword);

// Hardcoded secret
String apiKey = “sklive1234567890abcdef”;
`

 

Best Practices to Prevent Sideloading Risks

• Use the Play Integrity API to verify app authenticity
• Encrypt all sensitive data with AES or Keystore
• Obfuscate code with ProGuard or R8
• Avoid sideloading use Google Play internal testing tracks instead
  – Implement runtime permission checks and secure logging

Secure code example:

`java
// Secure logging
if (BuildConfig.DEBUG) {
Log.d(“AppStatus”, “User authenticated”);
}

// Secure storage
SharedPreferences prefs = getSharedPreferences(“secure”, MODE_PRIVATE);
prefs.edit().putString(“access_token”, encryptedToken).apply();
`

These points highlight the problems caused by sideloaded APKs and the ways to prevent them. In reality, sideloaded APKs should not be used for internal testing. It is strongly recommended to use Google Play Testing instead.

 

Case 2: AI-Driven Malware — FireScam

How a Fake Telegram Premium App Became a Global Surveillance Tool

In January 2025, cybersecurity researchers from Cyfirma uncovered a sophisticated Android malware campaign dubbed FireScam a multi-stage, AI-enhanced threat masquerading as a legitimate Telegram Premium app. Distributed via a phishing site hosted on GitHub.io and falsely branded as the Russian RuStore App Store, FireScam quickly spread beyond its initial target region, exploiting the trust users place in popular messaging platforms.

Key Characteristics of FireScam

AI-Powered Evasion: FireScam uses machine learning to adapt its behavior based on device environment, delaying execution until sandbox detection is bypassed.
Dropper Mechanism: The fake app installs a secondary payload that activates surveillance features only after initial trust is gained.
Firebase Abuse: It leverages legitimate services like Firebase to exfiltrate data, making detection harder.
Notification Hijacking: It reads and forwards user notifications, including OTPs, messages, and app alerts.
Persistent Control: Once installed, it maintains access through background services and disguised permissions.

 

What Developers Must Learn

FireScam isn’t just a clever disguise it’s a blueprint for future malware. It shows how attackers now use AI to:

• Delay execution until safe conditions are detected
• Mimic legitimate app behavior to avoid suspicion
• Exploit trusted SDKs and cloud services
• Harvest data silently through notification listeners and accessibility services

Here’s a simplified example of how malicious apps might misuse notification access:

`html

// Dangerous use of NotificationListenerService
public class FireScamListener extends NotificationListenerService {
    @Override
    public void onNotificationPosted(StatusBarNotification sbn) {
        String content = sbn.getNotification().extras.getString("android.text");
        sendToFirebase(content); // ❌ Exfiltrating user data
    }
}

`

Defensive Measures for Developers

To protect users and your app’s reputation, implement these best practices:

• Use Play Integrity API to verify app authenticity and block modified APKs
• Restrict permissions don’t request access unless absolutely necessary
• Avoid third-party SDKs from unknown sources
• Monitor app behavior using runtime checks and anomaly detection
• Encrypt all sensitive data and use secure channels for transmission

`html

// Secure Firebase transmission example
DatabaseReference ref = FirebaseDatabase.getInstance().getReference("secureData");
ref.setValue(encrypt(content)); // ✅ Encrypt before sending

`

Case 3: NFC Exploitation  SuperCard X

How Contactless Technology Became a Gateway for Financial Fraud

In April 2025, cybersecurity researchers uncovered a sophisticated Android malware-as-a-service (MaaS) platform called SuperCard X, designed to exploit Near Field Communication (NFC) for fraudulent ATM withdrawals and point-of-sale (PoS) transactions. The malware was distributed through deceptive apps like Verifica Carta, SuperCard X, and KingCard NFC, often promoted via smishing campaigns and fake bank alerts.

How the Attack Works

SuperCard X uses a multi-stage relay technique:
1. Victims are tricked into installing a fake “security” app via phone calls or urgent SMS alerts (TOAD: Telephone-Oriented Attack Delivery).
2. The app requests NFC permissions and instructs users to tap their debit or credit card against the infected device.
3. The malware captures card data and relays it in real time to a second device controlled by the attacker.
4. That second device running a “Tapper” app uses the stolen data to authorize fraudulent transactions at ATMs or PoS terminals.

 

Why This Matters in Android Development

Android’s flexibility allows apps to access NFC hardware with minimal friction. But without strict permission handling and foreground dispatch control, malicious apps can exploit this to:

• Read card data without user awareness
• Relay sensitive information to external servers
• Bypass traditional fraud detection systems

Here’s a simplified example of how NFC access can be misused:

`html

// Malicious use of NFC foreground dispatch
@Override
protected void onResume() {
    super.onResume();
    Intent intent = new Intent(this, getClass()).addFlags(Intent.FLAGRECEIVERREPLACE_PENDING);
    PendingIntent pendingIntent = PendingIntent.getActivity(this, 0, intent, PendingIntent.FLAG_MUTABLE);
    IntentFilter[] filters = new IntentFilter[] { new IntentFilter(NfcAdapter.ACTIONTAGDISCOVERED) };
    nfcAdapter.enableForegroundDispatch(this, pendingIntent, filters, null);
}

`

 

Developer Defense Strategies

To prevent NFC exploitation in your apps:

Use Foreground Dispatch Wisely: Only enable NFC when the app is actively in use and disable it on pause.
Validate NFC Data: Ensure the scanned data matches expected formats and sources.
Restrict Permissions: Avoid requesting NFC unless absolutely necessary.
Monitor for Abuse: Use Play Integrity API and runtime behavior checks to detect tampering.
Educate Users: Warn users not to tap cards against devices unless explicitly required.

`html

// Secure NFC handling
@Override
protected void onPause() {
    super.onPause();
    if (nfcAdapter != null) {
        nfcAdapter.disableForegroundDispatch(this);
    }
}

`

Case 4: Broken API Authentication

How Weak Token Management Led to a Massive Data Leak

In mid-2025, a popular fitness app with over 10 million downloads suffered a major breach due to broken API authentication. The app relied on static API keys embedded directly in the client-side code, lacked token expiration, and failed to validate user sessions properly. Attackers reverse-engineered the APK, extracted the keys, and used them to access user profiles, health data, and even payment information all without triggering alerts.

Real-World Parallel: OWASP & MoldStud Reports
According to OWASP’s 2024 API Security Top 10 and MoldStud’s 2025 case study, over 70% of mobile apps are vulnerable to API abuse due to poor authentication practices. Common issues include:

• Hardcoded API keys
• Lack of token rotation or expiration
• No rate limiting or anomaly detection
• Insecure transmission (e.g., missing HTTPS)
• Predictable or default tokens

 

What Went Wrong in the Fitness App

• Static API Key: Embedded in the app and reused across all users
• No OAuth2 or session validation: Anyone with the key could impersonate any user
• No token expiration: Keys remained valid indefinitely
• No logging or alerts: Breach went undetected for weeks

Here’s a simplified example of what not to do:

`html

//  Hardcoded API key
String apiKey = "skliveABC1234567890"; // Easily extracted from APK

// No session validation
HttpURLConnection conn = (HttpURLConnection) url.openConnection();
conn.setRequestProperty("Authorization", "Bearer " + apiKey);

`

Developer Best Practices for API Security

To prevent broken authentication in Android apps:

Use OAuth2.0: Implement token-based authentication with short lifetimes and refresh logic
Avoid hardcoding secrets: Store tokens securely using Android Keystore or encrypted SharedPreferences
Implement rate limiting: Detect and block abuse patterns
Use HTTPS for all API calls: Encrypt data in transit
Validate tokens server-side: Ensure tokens match user sessions and permissions
Log and monitor API usage: Use anomaly detection and alerting tools

`html

// Secure token storage
SharedPreferences prefs = getSharedPreferences("secure", MODE_PRIVATE);
prefs.edit().putString("access_token", encryptedToken).apply();

// Expiring token logic
if (token.isExpired()) {
    refreshToken();
}

`

Final Thought

In Android security, we can divide concerns into two types: app security and user security. App security means protecting an app’s data, APIs, and permissions so hackers cannot easily access them. User security means protecting the information of the people who use the app.

Example: If a user loses their phone and a hacker gets it, they can access app data stored in local storage. In that case, the app itself may not be compromised, but the user suffers.

Senior-level developers must think carefully and plan around these areas. That’s the responsibility of a trustworthy developer. Regarding permissions, do not request permissions that users don’t truly need. Such requests create doubt and weaken user security. In future posts, I’ll discuss Android development security in more detail. This blog shares my own experience; if additional needs arise, I’ll expand on them in upcoming posts.

---