Какие best practices по защите API?

Question

[Влад Т.]

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

Answer 1

[Philipp]

Обычные практики описаны тут https://www.owasp.org/index.php/REST_Security_Chea...

Подлинность запроса проверить возможно лишь при передаче данных через сервер.
В противном случае можно полагаться на стандартные механизмы защиты от кросс-сайт скриптинга или банальные проверки referrer. Однако такие мелочи подделываются на раз.

Comments

[Влад Т.]

Однако такие мелочи подделываются на раз.

Ну да, согласен.

Answer 2

[xmoonlight]

Есть 3 вида API:
1. Публичные - доступные публично с известными параметрами при запросе.
2. Приватные (авторизованное обращение) - доступные публично с известными параметрами при запросе, но с ключом(токеном по паролю) или сертификатом.
3. Закрытые - проприетарные клиенты со своим закрытым протоколом обмена с серверным API.

JS в браузере - это только 1.
Если не 2 и не 3 - значит остаётся 1.

Если МЕГА-тупо (для п.1): можно проверить длительность сессии в момент POST-запроса на сервер и, если длительность меньше времени самого быстрого заполнения формы человеком в ручном режиме, считать данные недостоверными.

Comments

[Влад Т.]

А длительность сессии будет проверяться тем же сервером, на котором хостится сайт с формой? Тогда не проще ли этому серверу самому отправить данные (с токеном), как предложил Philipp

P.S.

JS в браузере - это только 1.

В браузере, но не обязательно с помощью JS, просто обычная форма с адресом API в action.

[xmoonlight]

Влад Т.: ничего не понял... что предложил Philipp ? Там явно речи про браузер - не было...

[Влад Т.]

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

Philipp , я правильно понял Вашу идею? :)

[Philipp]

Влад Т.: да, вы правильно меня поняли.
Я так понимаю у вас нечто вроде формы обратной связи (упрощенно), вы хотите удостовериться, что данные к вашему сервису приходят именно с этого сайта.
Если форма будет отправлять данные с веб-страницы напрямую к вашему сервису, то нет никакой гарантии того, что запрос нельзя подделать.
Если данные формы отправить на сервер сайта, там можно добавить цифровую подпись (обычный hmac digest), которая будет выдана вашим сервисом владельцу сайта, то сервис сможет у себя проверить, что подпись совпадает и принадлежит владельцу сайта.
В таком случае, любые данные, которые попали на сайт, где установлена форма, будут считаться принадлежащими владельцу сайта.
Плюс моего подхода в том, что третьей стороне технически невозможно прикинуться другим сайтом без непосредственного взаимодействия с ним.

[Влад Т.]

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

Да, примерно так по сути.

[xmoonlight]

Влад Т.: понятно. тогда это п.3 из моего ответа. т.е. серверная сторона (back-end) промежуточного сайта выступает в роли закрытого клиента.
Тогда всё верно и я согласен с Philipp