Какие подходы по обеспечению безопасности мобильного приложения и инфраструктуры применить

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

Знаете ли вы штатные механизмы iOS и понимаете ли, что клиенту доверять нельзя: всё, что лежит в приложении, можно достать. Следом обычно спрашивают, где вы храните токен и что будет на устройстве с джейлбрейком.

Как отвечать

Разложите ответ на устройство, сеть, аутентификацию и сервер:

• хранение: токены и секреты только в Keychain с атрибутом вроде kSecAttrAccessibleWhenUnlockedThisDeviceOnly, в UserDefaults и plist они лежат открыто. Файлы защищает Data Protection, класс .complete закрывает их при заблокированном устройстве;
• ключи и биометрия: ключи генерируют в Secure Enclave через CryptoKit, они не покидают чип. Биометрию привязывают к элементу Keychain через SecAccessControl, а не к булеву ответу LAContext, который обходится на взломанном устройстве;
• сеть: App Transport Security по умолчанию требует HTTPS и TLS не ниже 1.2. Для чувствительных приложений добавляют pinning публичного ключа с запасным ключом на случай ротации;
• аутентификация: OAuth 2.0 с PKCE через ASWebAuthenticationSession, короткий access token, ротация refresh token, passkeys там, где возможно;
• целостность: App Attest из фреймворка DeviceCheck даёт серверу проверить, что запрос пришёл от настоящей копии приложения;
• утечки: без персональных данных в логах, скрытый экран в переключателе приложений, никаких API-ключей в бандле.

Со стороны инфраструктуры: права проверяет только сервер, есть rate limiting и мониторинг аномалий. Как чек-лист удобно назвать OWASP MASVS.

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

Предлагают шифровать данные своим AES с ключом в коде. Ключ достают из бинарника за минуты, правильный путь это Keychain, Data Protection и Secure Enclave.

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

Верят в детект джейлбрейка как в защиту. Его обходят, поэтому он годится только как дополнительный сигнал, а решение о доступе принимает сервер.