Нет способа гарантировать это.Клиент контролирует все, что происходит на стороне клиента.Если приложение содержит механизмы защиты от вмешательства клиента, оно может быть подвергнуто обратному проектированию.
Способ защиты неавторизованных клиентов от подключения к бэкэнду состоит в создании внутренних запросов с ключом API, который передается в виде зашифрованной (хешированной) строки.и проверено на стороне сервера.Злоупотребленные ключи API должны быть помещены в черный список.
Поскольку хешированные ключи могут быть извлечены из запросов API, способ сделать это более сложным состоит в том, чтобы сделать хешированный ключ API зависимым от конкретных запросов, например:
fetchData(url + '&api_key_hash=' + md5(SALT + url + SECRET_API_KEY))
api_key_hash все еще может быть проверено на стороне сервера, но бесполезно для клиента, который хочет получить несанкционированный доступ к внутреннему API.Единственный способ для клиента - получить SECRET_API_KEY.
Поскольку клиентское приложение может быть подвергнуто обратному проектированию для получения незашифрованного ключа API, способ усложнить обратный инжиниринг состоит в том, чтобы не хранить ключ в виде простой строки.и запутывайте приложение.
Обратите внимание, что хотя эти меры не гарантируют, что приложение не будет подвергнуто обратному проектированию для извлечения ключа API, запутывание может усложнить разработку приложения, например, отладку и анализ отчетов о сбоях.Насколько мне известно, обратное проектирование приложения React Native, которое не использует никакой защиты, кроме обфускации JS, тривиально.