<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Mobile Pentesting on Florence Njeri</title>
    <link>https://florencenjeri.com/tags/mobile-pentesting/</link>
    <description>Recent content in Mobile Pentesting on Florence Njeri</description>
    <generator>Hugo -- gohugo.io</generator>
    <language>en</language>
    <lastBuildDate>Fri, 24 Apr 2026 09:00:00 +0000</lastBuildDate><atom:link href="https://florencenjeri.com/tags/mobile-pentesting/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Pentesting Android Content Providers</title>
      <link>https://florencenjeri.com/posts/android_content_providers/</link>
      <pubDate>Fri, 24 Apr 2026 09:00:00 +0000</pubDate>
      
      <guid>https://florencenjeri.com/posts/android_content_providers/</guid>
      <description>Pentesting Content Providers # Content Providers are one of Android&amp;rsquo;s built-in ways for apps to share data with other apps. In practice, many of them sit in front of an SQLite database, but they can also expose files, app-specific actions, or custom logic through a content:// URI.
Why does this matter? Because Android apps are normally sandboxed. App A should not be able to open App B&amp;rsquo;s private database or files directly. A Content Provider is one of the official ways an app can intentionally cross that boundary. If the provider is misconfigured or trusts untrusted input, it can accidentally give another app access to data it should never have had.</description>
    </item>
    
    <item>
      <title>Insecure Storage in Android</title>
      <link>https://florencenjeri.com/posts/android_storage/</link>
      <pubDate>Wed, 15 Apr 2026 09:00:00 +0000</pubDate>
      
      <guid>https://florencenjeri.com/posts/android_storage/</guid>
      <description>Insecure Storage in Android # Insecure storage is still one of the easiest ways to recover sensitive data from an Android app during a pentest. Even when an app has strong network protections, it may still expose tokens, cached responses, credentials, or personal data locally. This post is a quick guide to the main Android storage locations and what they mean from a security testing perspective.
Shared Preferences # A key-value XML file that stores user preferences such as dark mode or light mode. They are also often used to store access tokens or other kinds of secrets. In itself, that is not an issue, but it makes shared preferences a very interesting target for stealing or overwriting internal files.</description>
    </item>
    
  </channel>
</rss>
