# Common Security Flaws in Android Applications: A Reverse Engineering Analysis

> Discover common security flaws in Android apps like hard-coded keys and insecure endpoints. This analysis uses reverse engineering to identify vulnerabilities in APKs.

- Repository: [Simone Avogadro/android-reverse-engineering-skill](https://github.com/SimoneAvogadro/android-reverse-engineering-skill)
- Tags: deep-dive
- Published: 2026-04-17

---

**The android-reverse-engineering skill identifies seven critical security vulnerabilities—including hard-coded API keys, clear-text HTTP endpoints, and missing certificate pinning—by decompiling APK files and analyzing Retrofit interfaces, OkHttp configurations, and WebView JavaScript bridges.**

The **SimoneAvogadro/android-reverse-engineering-skill** repository provides a structured framework for analyzing Android application binaries to surface common security flaws in Android applications. By automating decompilation and pattern matching against extracted source code, this skill enables security researchers to rapidly identify embedded secrets, insecure network configurations, and authentication weaknesses that static analysis tools often miss.

## Hard-Coded Secrets and API Keys

Embedding credentials directly into application binaries represents one of the most prevalent common security flaws in Android applications. When developers include API keys, authentication tokens, or client secrets as string literals, these values survive compilation and remain accessible to anyone who decompiles the APK.

### How the Skill Detects Embedded Credentials

The [`api-extraction-patterns.md`](https://github.com/SimoneAvogadro/android-reverse-engineering-skill/blob/main/api-extraction-patterns.md) reference file documents specific grep patterns designed to locate hard-coded secrets. Lines 86-88 define a comprehensive regex that matches common secret identifiers:

```bash
grep -rni 'api[_-]\?key\|api[_-]\?secret\|auth[_-]\?token\|bearer\|access[_-]\?token\|client[_-]\?secret' sources/

```

This pattern catches variations like `api_key`, `api-key`, `authToken`, and `clientSecret` regardless of obfuscation, since string literals remain readable even when class names are scrambled.

## Insecure Network Transport

### Clear-Text HTTP Vulnerabilities

Transmitting sensitive data over unencrypted HTTP channels exposes user credentials and application data to network eavesdropping. The skill specifically targets this vulnerability by extracting all URL literals from decompiled sources and flagging those using insecure protocols.

According to [`api-extraction-patterns.md`](https://github.com/SimoneAvogadro/android-reverse-engineering-skill/blob/main/api-extraction-patterns.md) lines 82-85, the following command identifies clear-text HTTP endpoints:

```bash
grep -rn '"http://[^"]*"' sources/

```

This pattern matches any string literal beginning with `http://`, immediately surfacing endpoints that should have been migrated to HTTPS.

### Missing Certificate Pinning

Without **certificate pinning**, Android applications remain vulnerable to Man-in-the-Middle (MITM) attacks where attackers substitute valid TLS certificates with compromised ones. The skill analyzes OkHttp builder configurations to determine whether pinning is implemented.

The [`api-extraction-patterns.md`](https://github.com/SimoneAvogadro/android-reverse-engineering-skill/blob/main/api-extraction-patterns.md) reference (lines 44-48) documents the grep pattern for CertificatePinner:

```bash
grep -rn 'CertificatePinner' sources/

```

When this search returns no results while OkHttp usage is detected, analysts can conclude the application lacks certificate pinning—a critical security gap.

## Insecure Authentication Flows

Poorly implemented authentication mechanisms represent severe common security flaws in Android applications. The [`call-flow-analysis.md`](https://github.com/SimoneAvogadro/android-reverse-engineering-skill/blob/main/call-flow-analysis.md) guide demonstrates how to trace authentication flows from UI components through to network requests, revealing where tokens are generated, stored, or transmitted insecurely.

Lines 55-66 of [`call-flow-analysis.md`](https://github.com/SimoneAvogadro/android-reverse-engineering-skill/blob/main/call-flow-analysis.md) outline the methodology for tracing a login endpoint:

```bash

# 1. Find the login string

grep -rni '"auth/login"' sources/

# 2. Locate the Retrofit interface

grep -rn '@POST("auth/login")' sources/

# 3. Follow usage to repository, ViewModel, and Activity

grep -rn 'c.a.b.d' sources/

```

This tracing exposes whether tokens are stored in plaintext `SharedPreferences`, transmitted in custom headers without encryption, or exposed to logging mechanisms.

## WebView JavaScript Interface Exposure

Applications utilizing `WebView` components with `@JavascriptInterface` annotations create potential attack vectors where malicious JavaScript can invoke native Android methods. The skill identifies these exposure points through specific extraction patterns.

According to [`api-extraction-patterns.md`](https://github.com/SimoneAvogadro/android-reverse-engineering-skill/blob/main/api-extraction-patterns.md) lines 72-76, the following patterns detect WebView vulnerabilities:

```bash
grep -rn 'addJavascriptInterface' sources/
grep -rn 'loadUrl' sources/

```

These commands surface bridge configurations that may allow unauthorized access to device functionality or data leakage through JavaScript execution.

## Obfuscation Limitations and String Exposure

Many developers mistakenly believe that ProGuard or R8 obfuscation protects their application logic. However, **string literals are never obfuscated** by standard Android build tools, leaving URLs, API keys, and error messages fully readable in the compiled binary.

The [`call-flow-analysis.md`](https://github.com/SimoneAvogadro/android-reverse-engineering-skill/blob/main/call-flow-analysis.md) reference emphasizes this critical point in lines 36-41:

> Even when class and method names are obfuscated to meaningless labels like [`a.b.c`](https://github.com/SimoneAvogadro/android-reverse-engineering-skill/blob/main/a.b.c), the string literals remain unchanged. This makes them the primary entry point for reverse engineering efforts.

Attackers can therefore grep for specific error messages, URL patterns, or JSON keys to rapidly locate sensitive logic within obfuscated applications.

## Automated Detection Scripts

The repository provides the [`find-api-calls.sh`](https://github.com/SimoneAvogadro/android-reverse-engineering-skill/blob/main/find-api-calls.sh) script to automate the detection of these common security flaws in Android applications. This script executes the documented grep patterns against decompiled sources, generating reports on Retrofit interfaces, OkHttp configurations, and embedded secrets.

To run a comprehensive security analysis including authentication patterns:

```bash
bash plugins/android-reverse-engineering/skills/android-reverse-engineering/scripts/find-api-calls.sh \
    output/sources/ --auth

```

The script leverages the patterns defined in [`api-extraction-patterns.md`](https://github.com/SimoneAvogadro/android-reverse-engineering-skill/blob/main/api-extraction-patterns.md) to surface HTTP endpoints, certificate configurations, and potential hard-coded credentials.

## Summary

The **android-reverse-engineering-skill** targets the most prevalent common security flaws in Android applications through systematic binary analysis:

- **Hard-coded credentials** exposed via string literals that survive obfuscation
- **Clear-text HTTP transport** identified through URL extraction patterns
- **Missing certificate pinning** detected by analyzing OkHttp builder configurations
- **Insecure authentication flows** traced from UI components to network layers
- **WebView JavaScript injection** vectors surfaced through interface analysis
- **Obfuscation gaps** exploited via unprotected string literals

By combining automated decompilation with targeted grep patterns documented in [`api-extraction-patterns.md`](https://github.com/SimoneAvogadro/android-reverse-engineering-skill/blob/main/api-extraction-patterns.md) and [`call-flow-analysis.md`](https://github.com/SimoneAvogadro/android-reverse-engineering-skill/blob/main/call-flow-analysis.md), the skill provides a repeatable methodology for identifying security weaknesses that static analysis tools frequently overlook.

## Frequently Asked Questions

### How does the skill detect hard-coded API keys in obfuscated applications?

The skill relies on the fact that **string literals are never obfuscated** by ProGuard or R8. According to [`call-flow-analysis.md`](https://github.com/SimoneAvogadro/android-reverse-engineering-skill/blob/main/call-flow-analysis.md) lines 36-41, even when class names are scrambled to meaningless labels like [`a.b.c`](https://github.com/SimoneAvogadro/android-reverse-engineering-skill/blob/main/a.b.c), strings remain unchanged. The [`api-extraction-patterns.md`](https://github.com/SimoneAvogadro/android-reverse-engineering-skill/blob/main/api-extraction-patterns.md) file provides regex patterns at lines 86-88 that search for identifiers like `api_key`, `auth_token`, and `client_secret` within these exposed string literals.

### Can the skill identify if an app uses certificate pinning to prevent MITM attacks?

Yes. The skill analyzes OkHttp configurations to detect the presence or absence of `CertificatePinner`. As documented in [`api-extraction-patterns.md`](https://github.com/SimoneAvogadro/android-reverse-engineering-skill/blob/main/api-extraction-patterns.md) lines 44-48, the skill uses `grep -rn 'CertificatePinner' sources/` to locate pinning implementations. If OkHttp is present but this search returns no results, the application likely lacks certificate pinning and remains vulnerable to Man-in-the-Middle attacks.

### What is the difference between clear-text HTTP detection and secret extraction?

Clear-text HTTP detection focuses on **transport security**, while secret extraction targets **credential storage**. The skill identifies clear-text HTTP by searching for URL literals starting with `http://` using the pattern `grep -rn '"http://[^"]*"' sources/` (as shown in [`api-extraction-patterns.md`](https://github.com/SimoneAvogadro/android-reverse-engineering-skill/blob/main/api-extraction-patterns.md) lines 82-85). Secret extraction uses broader regex patterns to find API keys and tokens embedded in the code (lines 86-88). Both represent distinct attack vectors: network eavesdropping versus binary reverse engineering.

### How does the skill trace insecure authentication flows?

The skill implements **call-flow analysis** to track authentication from user interface to network layer. According to [`call-flow-analysis.md`](https://github.com/SimoneAvogadro/android-reverse-engineering-skill/blob/main/call-flow-analysis.md) lines 55-66, analysts first locate login endpoint strings (e.g., `"auth/login"`), then find the corresponding Retrofit interface methods, and finally trace usage through repository classes, ViewModels, and Activities. This exposes whether tokens are stored in plaintext, transmitted in custom headers, or logged insecurely during the authentication process.