Insecure Storage and Comms
Common flaws.
Insecure Storage and Comms is a free Ethical Hacking Academy lesson on CoddyKit — lesson 4 of 4. You can read the complete lesson below for free — then practise it hands-on in the browser with a built-in code editor and a 24/7 AI tutor. It is part of the Ethical Hacking Academy learning path, one of 4 lessons in the course, and your progress syncs across the web and the CoddyKit app.
The Two Classic Flaws
Two of the most common mobile vulnerabilities are insecure data storage and insecure communication. They appear in the OWASP Mobile Top 10.
Both stem from developers trusting the device too much and protecting data poorly.
Where Apps Store Data
Apps keep data in /data/data/<package>/:
- SharedPreferences: XML key-value files.
- SQLite databases.
- Internal and external files.
Pentesters inspect each for secrets stored in the clear.
/data/data/com.app/shared_prefs/prefs.xmlPlaintext Secrets
A frequent flaw is storing passwords, tokens, or PII in plaintext in SharedPreferences or a database.
On a rooted device, via backup, or with Objection, an attacker reads these directly. Sensitive data should be encrypted or kept in secure hardware.
<string name="auth_token">eyJhbGci...plaintext...</string>External Storage Risks
Data written to external storage (the SD card area) is world-readable on older Android and accessible to any app with storage permission.
Saving sensitive files there exposes them to other apps. Logs written to disk are a related leak.
The Right Way to Store Secrets
Secure options include the Android Keystore (keys stored in hardware, never exposed to the app) and EncryptedSharedPreferences.
The Keystore can perform crypto operations without revealing the key, which is far safer than a hardcoded key in code.
Insecure Communication
Insecure communication means data travels without proper protection. The worst case is cleartext HTTP, where anyone on the network reads or modifies traffic.
All sensitive traffic must use HTTPS/TLS.
http://api.app.com/login # cleartext, credentials exposedIntercepting Traffic
To inspect traffic, route the device through an intercepting proxy like Burp Suite. You install Burp's CA certificate on the device so HTTPS can be read.
This reveals API endpoints, parameters, and any sensitive data in transit.
Certificate Pinning
Well-built apps use certificate pinning to reject any certificate but their own, defeating a basic proxy.
As you learned, a Frida SSL-pinning bypass disables this so you can still intercept and assess the actual API security.
Weak TLS and Validation
Even with HTTPS, flaws include trusting all certificates, accepting expired ones, or disabling hostname verification, often hacked in to make development easier.
These let an attacker perform a man-in-the-middle attack despite TLS being present.
Backups and Logs
Two more leaks:
android:allowBackup="true"lets anyone with the device extract app data viaadb backup.- Verbose logcat output may print tokens or PII.
Both should be disabled or sanitized in production.
adb backup -f data.ab com.appClipboard and Screenshots
Two often-overlooked leaks: copying sensitive data to the clipboard (readable by other apps on older Android) and the system screenshot taken when an app backgrounds.
Banking apps mitigate this with the FLAG_SECURE window flag, which blocks screenshots and the task-switcher preview.
Quick Check
Recall the safest place to keep cryptographic keys on Android.
Recap
You now understand insecure storage and comms:
- Apps leak plaintext secrets in SharedPreferences, databases, external storage, and logs.
- Store secrets in the Android Keystore or EncryptedSharedPreferences.
- Insecure comms range from cleartext HTTP to weak TLS validation; intercept with Burp.
- Defeat certificate pinning with Frida; disable allowBackup and sanitize logs.
You have completed the Mobile App Pentesting course.
Frequently asked questions
Is the “Insecure Storage and Comms” lesson free?
Yes — the full text of “Insecure Storage and Comms” is free to read here on the web, and the Ethical Hacking Academy course includes 4 lessons in total. To practise it interactively (a built-in code editor and a 24/7 AI tutor) and unlock the rest of the Ethical Hacking Academy course, upgrade to CoddyKit PRO.
What will I learn in “Insecure Storage and Comms”?
Common flaws. You practise Ethical Hacking Academy with hands-on code you run directly in the browser, and a 24/7 AI tutor answers your questions as you work through the lesson.
Do I need any experience to start Ethical Hacking Academy?
No prior experience is required. Ethical Hacking Academy on CoddyKit is structured for beginners through advanced learners; this is — lesson 4 of 4, so you can start here or from the beginning and move at your own pace.
How long does the “Insecure Storage and Comms” lesson take?
Most CoddyKit lessons take about 5–10 minutes. Each one is bite-sized and interactive, so you make steady progress and pick up exactly where you left off across the web and the app.
Can I write and run code in this Ethical Hacking Academy lesson?
Yes. Every Ethical Hacking Academy lesson includes a built-in code editor, so you write and run real code right in your browser and get instant AI feedback — no local setup required.
All lessons in this course
- Android App Structure
- Static Analysis of APKs
- Dynamic Analysis with Frida
- Insecure Storage and Comms