<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Content Providers on Florence Njeri</title>
    <link>https://florencenjeri.com/tags/content-providers/</link>
    <description>Recent content in Content Providers 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/content-providers/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>
    
  </channel>
</rss>
