Как определить что запрос к api пришел с клиента?

Question

[alestro]

Есть фронт на js, как на api сервере можно определить, что запрос пришел именно с фронта?
Бэкенд и фронт находятся на одно домене, при этом сервер рендерит фронт.

Comments

[Василий Банников]

А зачем нужно это проверять?

[alestro]

Василий Банников, Для аутентификации клиента сервером api

[Василий Банников]

alestro, а почему для процесса аутентификсации важно, откуда пришёл запрос,?

[alestro]

Василий Банников, фронт рендерит данные, полученный от апи, который закрытый. Не хотелось бы отдать данные куда-либо, кроме фронта

[Василий Банников]

alestro, клиент имеет полный доступ ко всему, что ты ему отдаёшь.

Почему отдать данные напрямую страшнее, чем просто отдать данные в браузер, из которого точно также данные можно прочитать

В принципе, ты можешь сильно усложнять жизнь всякими капчами, например, но это всё равно не спасёт от человека, который хочет.

Можно проверять всё что приходить в запросе, что он похож на браузерный (юзерагент, например), но это опять же можно автоматизировать и обойти.

Answer 1

[Василий Банников]

Никак.

Answer 2

[Дмитрий Еремин]

да никак.
вы хотите убедиться, что запрос пришел с конкретного девайса или с конкретного типа устройства (мобилка, веб, часы)?

• Существует заголовок User-Agent (https://developer.mozilla.org/en-US/docs/Web/HTTP/...). В нем содержится инфа об ОС и браузере, с которого пришел запрос
  
• Вы можете прокидывать какой-то свой специальный заголовок в запросах. Например сделать заголовок client-device-name и передавать какое-то спец.имя
  
• Вы можете гененрить на стороне бэка какой-нибудь токен и передвать его в ответе, в куках. Потом, при следующем запросе, проверять наличие этого токена
  

И да, все эти варианты можно имитировать в Postman или просто cURL. Так что методов нет

Comments

[alestro]

Я хочу убедиться, что запрос пришел с фронта и отдать ему данные. По сути дела аутентифицировать клиент

[Denis Melnikov]

alestro, ну так для этого и придумали токены ( token \ jwt )

[Василий Банников]

alestro, а что плохого случится, если запрос сделан не из браузера?

Answer 3

[Сергей Соколов]

Отдавая фронт, сервер может установить в нём уникальное значение ключа, и требовать именно это же значение в запросах к api. Скажем, в HTTP-заголовках запроса. Если нет ключа – запрос отклонять.

Значение это может быть привязано ко времени и считаться действительным только в течение часа, например.

Но и это никак не защищает от того, что получив код фронта, «злодей» не станет выполнять запросы с этим ключом из своих скриптов. Уточните вашу задачу, чего хочется добиться.

Авторизация пользователя — этот вариант вполне. Чел логинится на бэке и получает уникальный временный ключ, ассоциированный с его аккаунтом.

Ограничение по частоте запросов к API тоже с ключом решается.

Comments

[alestro]

Сейчас я клиент определяю по хттп онликуке, но как быть, если в браузере пользователя отключины куки. Я думал вычмслять код челендж при каждом запросе для определения клиента, но мб есть еще какие варианты.

[Василий Банников]

alestro, куки можно и без браузера отсылать, так что не сработает.
Челендж тоже можно посчитать - ведь у потенциального злодея уже есть открытый код с примером