Блог

У меня есть угловое приложение, которое не требует входа в систему. Это сайт для регистрации в реальном сервисе, и он должен быть открыт для доступа любого желающего. В рамках процесса регистрации ему необходимо вызвать API-интерфейсы REST. Если бы это было серверное приложение, я бы использовал секретные ключи для защиты доступа к API REST. Но поскольку он угловой, он на стороне клиента, и существует множество способов отслеживать сетевую активность, чтобы захватить секретный ключ. Как только у кого-то есть секретный ключ, он может вызвать REST API из любого места (например, Почтальон). Есть ли способ убедиться, что API-интерфейсы REST вызываются только из приложения Angular? Я читал о службе аутентификации, которая принимает учетные данные для входа и предоставляет токен сеанса (который затем может быть передан с помощью вызовов REST API). Но в моем случае пользователь не выполняет вход в систему. Приложение может иметь свои собственные учетные данные для входа в службу аутентификации, но тогда вызов службы аутентификации становится слабым местом, когда учетные данные для входа в приложение открыты для всех.

Короткий ответ — не совсем так.

Любой код интерфейса (который в конечном итоге загружается и запускается в браузере пользователя) может быть изучен пользователем. Вы можете зашифровать секреты, попробуйте запутать свое шифрование.. но в конце концов, методы, которые вы вызываете для этого, все равно могут быть прочитаны и использованы любым опытным пользователем.

Существует двусторонний подход к снижению легкости, с которой конечные пользователи могут спамить ваш API:

1. [Серверная часть] Реализует ограничение скорости, отслеживание IP-адресов, проверку агента пользователя и т.д. Любой может подделать UA, но кто-то должен изо всех сил стараться изменить его. Ограничение скорости по IP означает, что злоумышленник не мог пройти по определенному маршруту более X раз за Y минут. (Кроме того, в зависимости от вашего приложения, некоторые поставщики DNS/CDN могут предоставлять эту услугу в своем конце — подумайте о Cloudflare).
2. [Внешний интерфейс] Безопасность за счет запутывания, как уже упоминалось. Вы можете использовать пользовательский HTTP-заголовок, добавляемый к вашим запросам с секретным ключом, который создается на переднем конце и проверяется на заднем конце. Легко перехватывается и читается, но это только начало. Используйте какой-нибудь пользовательский алгоритм хэширования для шифрования вашего ключа. Для общедоступной конечной точки лучше всего просто создать как можно больше препятствий на пути злоумышленника. Я видел, как вы упомянули токен сеанса, который абсолютно сработал бы (как своего рода инструмент ограничения скорости), но любой, кто использует Postman или аналогичный, может захватить его и использовать для атаки (в течение любого периода времени, когда ваш токен действителен).