Как закрывать бекенд API от «левого» доступа?

Question

[danforth]

При создании Single Page Application, фронтенд обращается к бекенду посредством API. Появляется проблема: Если API публичный, то есть рассчитан на отдачу контента для гостей (не авторизованных пользователей), то проверить авторизацию мы уже не можем, а значит любой злоумышленник сможет спарсить сайт, отправив запрос на site.ru/api/ с вызовом метода getLatestPosts. Понимаю, что спарсить можно все, но не хочу, чтобы для злоумышленника эта задача была такой простой. Хочу понять, как в таких случаях определить реально ли клиентский запрос, или он идет от какого-то PHP парсера, должны же быть какие то способы проверки?

Спасибо!

Comments

[Илья]

А какая разница? Если бы формировали html на сервере, его бы точно так же могли бы парсить "гости". От этого невозможно закрыться.

[danforth]

Илья: Разница в том, что парсить можно одним запросом, и ты получаешь расфасованный JSON: вот тебе "title", а вот тебе "content", в случае с html, нужно заморачиваться с регулярками или DOM, также при смене верстки парсер сломается.

[Илья]

danforth: для всех популярных языков уже сделаны отличные библиотеки, при помощи которых можно написать парсер за пару минут. И да, в случае апи тоже можно ломать, запрашивая разные заголовки. Но это не помешает снова за пару минут наладить парсер, как и в случае с html-парсером.

[xtalen]

Никак, даже с авторизацией. Ничего не спасет. Нет 100% способа защитить использование api со сторонних клиентов. Это не только WEB, любые клиенты, в том числе и мобильные.

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

Answer 1

[Илья Караваев]

Вы можете делать как это делают платежные сервисы. Имеется секретный ключ, известный Вашего публичному и Вашему "приватному" серверу с API. Передаваемые данные собираются в кучу и хэшируются с секретным ключом. Это хэш для проверки отправляется дополнительным параметром для валидации на стороне приватного сервера. Кто не знает секретный ключ, не сможет правильно составить запрос.

Ну или Вам вполне можно разместить API сервер во внутренней сети с публичным сервером, если на приватный не нужен доступ из вне.

Comments

[_ _]

Речь идет о фронтенде - приложении в браузере. Никакого тольку от подобных алгоритмов в таком случае нет.

[danforth]

Александр Марченко: согласен, это не совсем то, что нужно.

[Илья Караваев]

danforth: без какого либо способа идентификации пользователя Вы API не закроете, тем более публичное.

Answer 2

[_ _]

Правильно вам ответил DevMan - ограничение количества запросов, синтетическое увеличение времени ответа сервера при подозрительной активности. В основном все упирается в поведенческий анализ - если кто-то (IP-адрес или можно поискать библиотеки для более сложной эвристики определения уникальных пользователей) целенаправленно стучится по одному и тому же API endpoint, перебирая параметр пагинации, то вас, скорей всего, парсят - ставим этот IP-адрес в список подозрительных и добавляем ему синтетическую задержку ответа в 3 секунды и лимит одновременных соединений. А если он настойчивый, то и вовсе баним

Answer 3

[catanfa]

В общем случае правильный ответ на этот вопрос никак. Если у вас публичное апи, доступное любому браузеру, то несложным софтом его можно простучать. Если вы будете ставить какие-то преграды, вроде ограничения на частоту запросов с одного айпи, какие-то куки-шмуки и т.д., но при этом из браузера всё будет работать, то и из парсера, после несложной подкрутки со стороны злоумышленника, тоже всё будет работать. В конце концов, что мне мешает просто человеческими руками "прокликать" весь ваш сайт и сохранить все страницы через File -> Save Web Page As.. ?
Между прочим, поисковые роботы Яндекса и Гугла тоже парсят ваш сайт, и вы скорее всего не хотели бы их банить.

Answer 4

[Alex]

Для авторизации в API можно использовать JWT.

Answer 5

[Rou1997]

А это очень надо - защищать?
А почему сразу злоумышленник?
Вот вы вообще пишете, что у вас публичное API, и тут же пишете, что хотите запретить им пользоваться. :)

как в таких случаях определить реально ли клиентский запрос, или он идет от какого-то PHP парсера

Если хотите проверить идет ли запрос от браузера или от парсера, то проверяйте HTTP-заголовки, если парсер "кривой" то это поможет, еще лучше примените HTTPS с HSTS, а еще лучше перейдите с HTTP на другой протокол, вот это серьезно повысит "планку" для квалификации так называемого "злоумышленника".

должны же быть какие то способы проверки?

Кроме IP-адреса все остальное подделывается, вообще весь этот стек IP-TCP-HTTP мало что "должен", в прошлом веке о таких вещах не думали, в протоколе TCP нет и гораздо более нужных возможностей.