Как обеспечить безопасность при обмене данными через ContentProvider в Android

Что проверяют

Знаете ли вы, какие рычаги у ContentProvider есть в манифесте и в коде, и понимаете ли, что главная защита это закрытый по умолчанию провайдер, а не шифрование. Следом обычно спрашивают, как отдать другому приложению один файл, не открывая провайдер целиком.

Как отвечать

Идите от манифеста к коду:

• android:exported: если провайдер не нужен другим приложениям, ставьте false. При targetSdkVersion 17 и выше это и так дефолт, но лучше писать явно;
• разрешения: android:readPermission и android:writePermission отдельно на чтение и запись или общий android:permission. Своё разрешение объявляйте с android:protectionLevel="signature", тогда доступ получат только приложения, подписанные вашим ключом;
• <path-permission>: отдельные разрешения для отдельных путей URI;
• временные гранты: android:grantUriPermissions="true" и флаг FLAG_GRANT_READ_URI_PERMISSION в интенте дают доступ к одному URI без постоянного разрешения. Для файлов готовое решение это FileProvider из AndroidX: ссылка file:// наружу начиная с Android 7 вызывает FileUriExposedException;
• проверки в коде: getCallingPackage(), Binder.getCallingUid() и checkCallingPermission() внутри query(), insert() и openFile();
• защита от инъекций: selection с плейсхолдерами ? и массивом selectionArgs, никакой конкатенации строк в SQL. Проекцию и сортировку сверяйте с белым списком, у SQLiteQueryBuilder включайте setStrict(true) и setProjectionMap().

Шифрование данных на диске это отдельная задача: от приложения, которому вы сами выдали разрешение, оно не спасает.

Где спотыкаются

Экспортируют провайдер «на всякий случай» без разрешений. Любое приложение на устройстве читает и пишет данные через ContentResolver.

Объявляют своё разрешение с уровнем normal. Такое разрешение система выдаёт любому приложению, которое просто указало его в манифесте, то есть защиты нет.

В openFile() строят путь к файлу из сегмента URI без нормализации. Запрос с ../ выводит за пределы разрешённого каталога, поэтому канонический путь нужно сравнивать с корневым каталогом провайдера.