Привет, сегодня речь пойдет о безопасности.

Безопасность мобильных приложений очень важна, так как сегодня бизнес выносит львиную часть работы с клиентом в мобильные приложения, а это подразумевает наличие и обработку персональных данных клиента.

Основные проблемы и уязвимости стары как мир и описаны на www.owasp.org
Кратенько это:

• Improper platform usage;
• Insecure data storage; 
• Insecure communication;  
• Insecure Authentication;  
• Insufficient Cryptography;  
• Insecure Authorization; 
• Client Code Quality;
• Code Tampering;
• Reverse engineering.

Отлично, теперь все понятно. Но постойте, что это на самом деле это значит для Android-проекта?

1. Начните с выключения логов, которые идут в logcat в production-приложении.
2. Создайте безопасное хранилище с использованием KeyStore – это такой компонент для получения ключей для последующего шифрования данных.
3. Не полагайтесь на SharedPreferences и MODE_PRIVATE, храните там только зашифрованные данные.
4. Используйте Permissions в динамике, не полагайтесь на полученные разрешения во время старта или настройки приложения.
5. Используйте и создавайте свои собственные Permissions, проверяйте их наличие при работе компонентов.
6. Ограничивайте функционал Services и ContentProviders, которые выставлены в систему, проверяйте то, что ими пользуются «доверенные» программные пакеты: по подписи, имени пакета и порой даже при наличии определенного Permission.
7. Не передавайте никакую Sensitive-информацию в  Intent’ах.
8. Добавьте обфускацию кода, просто но уже доступно.
9. Защитите сетевое взаимодействие:
• a. Используйте NetworkConfig;
• b. Или ограничьтесь самостоятельно реализованным SSL Pinning’ом.
10. Используйте SQLCipher, не надо городить собственные велосипеды.
11. Запретите backup вашего приложения, поменяйте значение allowBackup в false, пусть «мамкин хакер» хоть чуть-чуть потрудится над тем, чтобы слить ваше приложение перед тем, как приступить к взлому.
12. В случае возможности пользуйтесь Google Attestation API.
13. Ограничивайте использование приложения в моменты, когда что-то идет не так, вашу активити вызывает не тот пакет или подпись не совсем та, что вы ожидали. Предусматривайте возможность информирования пользователя о том, что что-то не так на его телефоне или же просто не давайте пользоваться приложением.

К сожалению, как таковой супер системы безопасности на конечном клиентском устройстве не существует, потому как программный код может быть скомпроментирован, последний и единственный рубеж обороны – сервер, но и на клиенте необходимо создавать достаточное количество препятствий всем хакерам, от мала до велика.

P.S.: не забывайте делать «экранирование» пользовательского ввода ;)