Как безопасно связать front и back приложения по api?

Question

[myspace]

Как защитить бекенд от доступа к api с другого домена? Если на бекенде обрабатывать такие запросы

https://backend.site.ru/handler?method=get.all.news&page=2

и возвращать json, то с любого домена можно будет обратиться к серверу и получить информацию. Токен тоже вариант бесполезный, так как запросы идут с клиента. Если делать проверку по ip на сервере, на котором работает nodejs, насколько тяжело подменить ip?

Comments

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

от чего вы хотите защититься: от клиентов-клонов, раздаваемых с другого домена? (CORS заголовок поможет). От парсинга данных, запускаемых с левых серверов?

[myspace]

Сергей Соколов: хочу что бы бекенд сервер не могли парсить. А с фронта пусть парсят на здоровье

Answer 1

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

На сервере генерировать токен, привязанный ко времени и секрету, известному только вашему серверу. Например time=12345&hash=abcdef.

Можно в хэш включить ещё и IP адрес, с которого зашёл очередной клиент, и его User-agent.

Тогда клиенты, запущенные с вашего сервера будут иметь в коде верный токен, свежий, не старше, скажем, 15 минут. И будут его прикладывать к каждому запросу к API.

Злодеям придётся как-то узнавать каждый новый токен каждые 15 минут.

Comments

[Михаил Серенков]

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

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

Следующий виток гонки вооружений – обязательная регистрация клиентов и аналитика их запросов для классификации «нормальный юзер / парсер» для бана аккаунтов и IP парсеров. Не мы начали эту войну )

[myspace]

Сергей Соколов: да можно хоть каждый запрос новый токен отдавать

[Виталий]

Сергей Соколов: если хочешь бороться с ботами, апи самое слабое звено.

[myspace]

Виталий: в смысле по нему долбить будут?

[Виталий]

myspace: ну если есть цель защититься от парсинга, то апи самое слабое звено, ибо к нему достаточно отправить несколько запросов и получить результат

Answer 2

[xmoonlight]

Проверьте A-запись DNS по IP-шнику. Если есть - значит это домен/сайт. Ну и дальше - решайте.

Comments

[myspace]

Пожалуй загуглю про данный способ. Спасибо!

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

не вариант. У большинства провайдеров IP резолвятся в что-то типа broadband-123-123-123-123.moscow.rt.ru – под каждый IP есть A-запись.

[xmoonlight]

Сергей Соколов: да не вопрос, ещё туча есть вариантов: NS, MX, PTR

[xmoonlight]

Сергей Соколов: ещё, вот, забыл: ну а домены провайдеров внести в чёрный список (*.rt.ru), даже если прорезолвится - вообще не проблема.

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

xmoonlight: тогда уж в Белый список. broadband* это динамические ip домашнего интернета – легитимные частные клиенты, а не скрипты-парсеры на сервере.

[xmoonlight]

Сергей Соколов: не всегда....

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

xmoonlight: похоже.... если...... призадуматься...... многозначительно.... ваш...... метод.... не работает.

[xmoonlight]

Сергей Соколов: тогда... обоснуйте ваше бездоказательное заключение...

Answer 3

[Михаил Серенков]

Гуглите cors заголовки.

Comments

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

это не защитит от парсинга

Answer 4

[GrimJack]

Возможно подойдет
htaccess.net.ru/doc/htaccess/order.php

Comments

[myspace]

апач к сожалению не рассматриваю

[GrimJack]

myspace: нгинкс
allow ip;
deny all;

Answer 5

[Viktor_P]

Не уверен на 100%, но я бы начал копать в эту сторону:
1. Перевести https://backend.site.ru/ на https://site.ru/backend и отключить CORS
2. Либо же указывать строго Access-Control-Allow-Origin