Как мне убедиться, что к конечным точкам бэкэнда получают доступ только мой собственный интерфейс, а не кто-нибудь еще?
Позвольте мне сказать вам здесь жестокую правду ... это невозможно для веб-приложения, из-за
природа, как сеть была разработана для работы.
Давайте попробуем немного глубже понять проблему,
Разница между WHO и WHAT имеет доступ к вашему серверу API, и почему частные
API не существует.
КТО И ЧТО ДОСТУПАЕТ К СЕРВЕРУ API
WHO является пользователем веб-приложения, которое можно аутентифицировать, авторизовывать и идентифицировать несколькими способами, например, используя потоки OAUTH и / или OpenID.
OAuth
Как правило, OAuth предоставляет клиентам «безопасный делегированный доступ» к ресурсам сервера от имени владельца ресурса. Он определяет процесс для владельцев ресурсов, чтобы разрешить сторонний доступ к своим ресурсам сервера без совместного использования своих учетных данных. Разработанный специально для работы с протоколом гипертекстовой передачи (HTTP), OAuth, по сути, позволяет выдавать маркеры доступа сторонним клиентам с помощью сервера авторизации с разрешения владельца ресурса. Затем третья сторона использует токен доступа для доступа к защищенным ресурсам, размещенным на сервере ресурсов.
OpenID
OpenID Connect 1.0 - это простой уровень идентификации поверх протокола OAuth 2.0. Это позволяет клиентам проверять подлинность конечного пользователя на основе аутентификации, выполняемой сервером авторизации, а также получать базовую информацию о профиле конечного пользователя взаимодействующим и REST-подобным образом.
Теперь вам нужен способ определить, ЧТО вызывает ваш API-сервер, и здесь все становится сложнее, чем может подумать большинство разработчиков. ЧТО - это то, что делает запрос к серверу API, это действительно ваше подлинное веб-приложение или это робот, автоматизированный скрипт или злоумышленник, который вручную ковыряет ваш сервер API с помощью такого инструмента, как Postman?
Хорошо, чтобы определить ЧТО разработчики, как правило, прибегают к API-ключу, который обычно они отправляют в заголовке, в cookie-файле или скрывают в коде JavaScript своего веб-приложения, а некоторые идут на дополнительные усилия. вычисляет его во время выполнения в веб-приложении, таким образом, становится динамическим секретом в отличие от прежнего подхода, который представляет собой статический секрет, встроенный в код или в заголовок.
ЧАСТНЫЕ API
Независимо от того, если у API нет общедоступной документации или если оно защищено какими-либо механизмами секретности или аутентификации, однажды доступен
из Интернета больше не является частным, поэтому любой может получить к нему доступ
знает, где он живет, и перечисление каждой конечной точки легко, как использование сети
вкладка в инструментах разработки.
ВОЗМОЖНЫЕ РЕШЕНИЯ
Все, что работает на стороне клиента и нуждается в секрете для доступа к API
злоупотреблять по-разному, и вы можете узнать больше о
этой серии из
статьи о технике безопасности мобильного API. Хотя эта статья была сделана в
В контексте мобильного приложения они все еще используют общие методы с веб-приложениями.
Они научат вас, как можно использовать ключи API, токены доступа пользователей, HMAC и TLS Pinning.
используется для защиты API и как их можно обойти.
Ваш Javascript-код может быть затруднен для понимания, если его запутать, что затруднит его реинжиниринг, но имейте в виду, что это невозможно, поэтому не полагайтесь на него, чтобы скрыть конфиденциальные данные, а только как на другой уровень затрудняет понимание происходящего.
Вы также можете взглянуть на reCaptcha V3 от Google, который позволит отличить реальных пользователей
из автоматизированных сценариев без необходимости взаимодействия с пользователем. Вам нужно будет добавить его на каждую страницу вашего веб-приложения.
reCaptcha V3
reCAPTCHA - это бесплатный сервис, который защищает ваш сайт от спама и злоупотреблений. reCAPTCHA использует усовершенствованный механизм анализа рисков и адаптивные задачи, чтобы автоматизированное программное обеспечение не использовалось для злоупотреблений на вашем сайте. Это делает это, позволяя вашим действительным пользователям легко проходить через них.
Еще один более изощренный способ - использовать инструменты UBA (User Behavior Anlytics), которые используют машинное обучение и искусственный интеллект в бэкэнде для предотвращения злоупотребления API, но они не могут блокировать его на 100%.
Для решения проблемы ЧТО обращается к вашему API-серверу, вам нужно использовать одно или все решения, упомянутые в серии статей о технологиях безопасности Mobile API, reCaptcha V3 и решение UBA, и согласиться с тем, что они могут только сделать несанкционированный доступ к вашему серверу API труднее, но не невозможным.
РЕЗЮМЕ
Таким образом, вы можете затруднить поиск и доступ к своему API, но по-настоящему заблокировать его в своем веб-приложении вы не сможете.