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

Очевидно нет. Всегда можно запустить браузер из своей программы и сделать всё, что угодно. Можно пытаться с переменным успехом отличать софт от браузера, хотя и тут это всё из разряда гонки между вирусом и антивирусом. Вот что можно делать в порядке от простого к сложному. Причём каждый пункт будет давать ложные срабатывания на необычных конфигурациях и недовольных пользователей.

1. Проверять User-Agent.
2. Проверять все заголовки.
3. Проверять особенности реализации сетевого стека (например если сетевой стек похож на линуксовый, а заголовки приходят вендовые, возможно что-то не так).
4. Посылать клиенту жаваскрипт, который должен выполниться.
5. Посылать клиенту очень хитрый жаваскрипт, причём генерируемый каждый раз заново, закодированный вусмерть и тд. Который будет проверять всякие хитрые фишки, которые эмулировать не факт, что догадаешься. Примерно так работает гугловая рекапча.
6. Собственно показывать капчу. От автоматизированных сервисов немного защитит путём усложнения жизни юзеру.
7. Проверять поведение пользователя, порядок запросов и тд. В общем статистика. Типа если кнопка нажимается, а мышка не шевелится или если мышка равномерно по прямой ездит, что-то тут не так.

Здравствуйте, zverjuga, Вы писали:

Z>имеется официальный сайт, обращающий к серверу через определенное апи. панель разработчика в веб-браузере дает возможность посмотреть, какие методы сервера дергаются и какие параметры туда передаются, что дает возможность постороннему человеку изучить и понять апи, и использовать его вне работы сайта (написать свой софт, который будет обращаться к апи и получать данные от сервера).
Z>есть ли возможность как то ограничить возможность написания такого стороннего приложения и использования апи сервера вне официального сайта?

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

Но можно ограничить доступ к API, например, с помощью логина и пароля. Тогда сервер сможет игнорировать запросы от злоумышленника.

Z>есть ли возможность как то ограничить возможность написания такого стороннего приложения и использования апи сервера вне официального сайта?
Есть. Авторизация/аутентификация называется.
Варианты реализации могут быть самые разные. Например:
1. Если API и сайт висят на одном домене — то банально кука с ограниченным временем жизни. При первом заходе пользователя — выдаем сессионную куку, при обращениях к API, смотрим, что кука на месте и не протухла.
2. Самодельные токены — при рендеринге страницы на сервере добавляем в нее токен для доступа к API. JS читает этот токен и ходит с ним к API-шке.
Либо добавляем в API метод для запроса API-токена (e.g. по логину/паролю, по SMS, etc). Тогда JS рисует форму для ввода cridentials, запрашивает токен, ходит с ним к API-шке.
3. Взрослое решение — смотрим готовую реализацию OpenID под твою платформу. Ставим, интегрируем с базой пользователей. Далее пользователи ходят к сервису авторизации за токенами, передают их в апишку, апишка проверяет токены.

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

Z>а апи, который раздается для приложений (как у гугла или фэйсбука с контролем через девелоперовскую консоль) обычно отличается от апи, который используется на сайте?
Это довольно неоднозначный вопрос.

С одной стороны, если форма и содержание API (т.е. роуты, модели данных и т.п.) для мобильного и для сайта одинаковые, то и смысла их разделять нет.
Правильней и дешевле будет сделать общую API-шку.
А то, о чем ты говоришь на примере google, в OpenID называется client/flow.
Client/flow — это как внешний мир стучится в твою API-шку.
Т.е. вещи вроде: что используется для доступа к API: браузер, мобильное приложение, десктопное приложение или вообще сервис без UI, который дергает голый REST?
Вовлечен ли пользователь в этот процесс или это service-to-service коммуникация без участия пользователя? Каков механизм получения токена для доступа к API?
Информация о client передается в токене, т.е. если в API-шке тебе нужно вести себя немного по разному в зависимости от client'a — это можно сделать.

С другой стороны, бывает так, что смотришь на use-кейсы для мобильного и для сайта и понимаешь, что они настолько разные, что свести их в универсальную апишку не выйдет.
Тогда выделяют два разных API и адаптируют каждое из них под потребности конкретного клиента.
Для этого умный дядька Сэм Ньюман даже описал специальный паттерн Backend For Frontend.
Но и в этом случае защита апишки обычно реализуется через тот же механизм с токенами.


> собственно, у меня вопрос отсюда и возник. хочу в некотором будущем дать возможность расшарить апи для сторонних приложений с контролем через дев консоль. но возник вопрос, а что помешает приложение не пользоваться этим апи, а использовать апи самого сайта?

Это называется сlient сredentials flow: через dev-консоль ты выдаешь client id / client secret (credentials).
Их знает только конкретный клиент (безопасность).
Клиент использует их для получения токена доступа .
С токеном клиент идет в API-шку.
Запросы без токена — просто отбиваются (защита).
В API-шке дополнительно можно извлечь из токена информацию о клиенте и сделать какую-то дополнительную валидацию (e.g. проверить права доступа).

Здравствуйте, zverjuga, Вы писали:
Z>есть ли возможность как то ограничить возможность написания такого стороннего приложения и использования апи сервера вне официального сайта?
По большому счёту — только с помощью reCaptcha.
Но для этого надо сначала понять, с чем именно вы хотите бороться. Что именно будет плохо в том, что кто-то пользуется вашим API минуя официальный сайт?
Потому что самый простой ответ — забить на это, и, наоборот, радоваться тому, что кто-то приносит вам пользу, не создавая нагрузки на фронт-енд.
Если вас беспокоит перспектива, скажем, клонирования каталога — то реализуете throttling на стороне сервера так, чтобы честному пользователю было комфортно, а клонеру — нет.
Примерно то же самое применимо к случаю "хочу навязывать пользователям просмотр назойливой рекламы" — современные браузеры не дадут злоумышленнику напрямую лезть в ваш API со страниц в его домене, а проксирование запросов через его сервер порежется благодаря throttling-у (запросы с честных пользователей размазаны по всем, запросы через прокси приходят ровно с одного прокси).
Можно просто смотреть за тем, что происходит, и активно банить подсетки тем, кто вас интенсивно вызывает напрямую.

Это всё — для случая, когда API предоставляется анонимным пользователям.
Если пользователи авторизованы, то, как правило, всё гораздо проще — есть простые метрики, которые позволяют отличить агнцев от козлищ, и вы можете просто блокировать ключики тем, кто ведёт себя не так как вам надо.

Z>имеется официальный сайт, обращающий к серверу через определенное апи. панель разработчика в веб-браузере дает возможность посмотреть, какие методы сервера дергаются и какие параметры туда передаются, что дает возможность постороннему человеку изучить и понять апи, и использовать его вне работы сайта (написать свой софт, который будет обращаться к апи и получать данные от сервера).
Z>есть ли возможность как то ограничить возможность написания такого стороннего приложения и использования апи сервера вне официального сайта?

почему не придумать какой-то механизм, который кодирует и декодирует Routes, тем самым пряча апи от сторорниих наблюдателей ( Capability-based security)? Кажется вот тут, минуты с 40 -ой что-то было https://vimeo.com/162209391

Здравствуйте, zverjuga, Вы писали:

Z>имеется официальный сайт, обращающий к серверу через определенное апи. панель разработчика в веб-браузере дает возможность посмотреть, какие методы сервера дергаются и какие параметры туда передаются, что дает возможность постороннему человеку изучить и понять апи, и использовать его вне работы сайта (написать свой софт, который будет обращаться к апи и получать данные от сервера).
Z>есть ли возможность как то ограничить возможность написания такого стороннего приложения и использования апи сервера вне официального сайта?

У тебя же только один официальный сайт и один "сервер"? Вот и пропиши на нем белый список IP адресов: адрес сайта и адрес рабочий где ты или кто "сервер" обслуживает и тестирует.

Никто не написал

Здравствуйте, VladCore, Вы писали:

VC>У тебя же только один официальный сайт и один "сервер"? Вот и пропиши на нем белый список IP адресов: адрес сайта и адрес рабочий где ты или кто "сервер" обслуживает и тестирует.

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