Как уже указывалось @jake, вы должны использовать токен, привязанный только к пользователю, вместо ключа Api для всех пользователей, но могут быть сделаны другие усовершенствования для дополнительной защиты вашего приложения при выполнении запросов http.
Пользовательский токен может быть подписанным токеном JWT, и тогда вы сможете повысить безопасность связи между вашим сервером и приложением с помощью закрепления сертификата для защиты от атак «Человек посреди».
Другие методы, такие как использование OAUTH2 и сокрытие секретов, могут быть использованы для повышения безопасности вашего приложения, и вы можете прочитать больше об этом здесь .
Имейте в виду, что закрепление сертификата может быть обойдено путем перехвата платформ, таких как Xposed , которые содержат модули, специально предназначенные для обхода закрепления, но все же это еще один уровень безопасности, от которого не следует отказываться как только это увеличит усилия, необходимые для взлома вашего приложения на устройстве, и защитит ваше приложение от атак «Человек в середине».
В конечном итоге для обеспечения безопасности между вашим приложением и внутренним сервером вы должны использовать службу подтверждения целостности приложения, которая во время выполнения гарантирует, что ваше приложение не было подделано или не запущено на корневом устройстве с помощью SDK, встроенного в приложение и служба, работающая в облаке.
При успешной аттестации целостности приложения выдается токен JWT, который подписывается с секретом, о котором знают только серверная часть вашего приложения и служба аттестации в облаке, а при сбое JWT подписывается с фальшивым секретом, который бэкэнд приложения не знает, что позволяет бэкэнду приложения таким образом обслуживать запросы только тогда, когда он может проверить подпись в маркере JWT и отклонить их в случае неудачной проверки.
Поскольку секретный ключ, используемый службой аттестации в облаке, не известен приложению, то невозможно восстановить его во время выполнения, даже когда приложение подделано, работает на корневом устройстве или осуществляет связь через соединение, которое цель человека в средней атаке.
Вы можете найти такую службу в Approov , в которой есть SDK для нескольких платформ, включая IOS. Для интеграции также потребуется небольшая проверка в коде сервера приложений для проверки токена JWT, чтобы сервер мог защитить себя от мошеннического использования.
токен JWT
Аутентификация на основе токена
JSON Web Tokens - это открытый промышленный стандарт RFC 7519 для безопасного представления заявок между двумя сторонами.
Закрепление сертификата
Пиннинг - это процесс связывания хоста с его ожидаемым сертификатом X509 или открытым ключом. Когда сертификат или открытый ключ известен или виден для хоста, сертификат или открытый ключ связывается или «закрепляется» на хосте. Если допустимо более одного сертификата или открытого ключа, программа хранит набор выводов (по словам Джона Ларимера и Кенни Рута из Google I / O talk). В этом случае рекламируемый идентификатор должен соответствовать одному из элементов в наборе символов.
oauth2
Инфраструктура авторизации OAuth 2.0 позволяет сторонним
приложение для получения ограниченного доступа к службе HTTP, либо на
от имени владельца ресурса путем организации взаимодействия утверждения
между владельцем ресурса и службой HTTP, или разрешив
стороннее приложение для получения доступа от своего имени. это
спецификация заменяет и отменяет описанный протокол OAuth 1.0
в RFC 5849.
Отказ от ответственности: я работаю в Approov.