Как защитить конечную точку API для сообщения об ошибках JS на стороне клиента от спама (если даже необходимо)? - PullRequest
1 голос
/ 19 марта 2019

Я занимаюсь разработкой веб-приложения с использованием Spring Boot и React.js SPA, но мой вопрос не относится к этим библиотекам / средам, так как я предполагаю, что сообщение об ошибках JS на стороне клиента на сервер (для регистрации и анализа) должно быть обычной операцией для многих современных веб-приложений.

Итак, предположим, что у нас есть клиентское приложение JS, которое ловит ошибку, и конечная точка REST /errors, которая принимает объект JSON, содержащий соответствующую информацию о том, что произошло. Клиентское приложение отправляет данные на сервер, оно сохраняется в базе данных (или где-либо еще), и все счастливы, верно?

Теперь я не такой. Потому что теперь у меня есть открытая (как в , разрешающая неаутентифицированные операции создания / записи ) конечная точка API, и каждый, кто имеет немного знаний, может легко спамить.

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

В таких вопросах, как « Открыть REST API, подключенный к базе данных - что мешает плохому действующему лицу спамить мою базу данных? » или « Secure Rest-Service перед аутентификацией пользователя », есть предложения, такие как:

  • квоты доступа (но я не хочу сохранять IP-адреса или что-либо еще для идентификации клиентов)
  • Captchas (очевидно, бесполезно для сообщений об ошибках)
  • подтверждение по электронной почте (то же самое, только представьте себе)

Итак, мои вопросы:

  1. Существует ли элегантная, обычно используемая стратегия для защиты такой конечной точки?
  2. Достаточно ли на практике простого решения, такого как проверка структуры данных?
  3. Все ли это вообще необходимо? В конце концов, я не буду рекламировать свою конечную точку API обработки ошибок с помощью баннера в приложении ...

1 Ответ

0 голосов
/ 19 марта 2019

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

  1. Предполагается, что вы используете OAuth 2 для защиты своего API. Встать два конечные точки ошибок.

    • Для вошедшего в систему пользователя, если произойдет ошибка, вы бы нажать на конечную точку / error и выполнить аутентификацию, используя существующую токен пользователя
    • Для посетителя вы можете выставить / clientError (или назван таким образом, что имеет смысл для вас) конечная точка, которая принимает токен client_credentials для клиентского приложения.
  2. Защитите конечную точку / error с помощью ключа API, который будет охватывать доступ только к конечной точке ошибки.

    • Этот ключ будет специфичным для клиент и будет передан в заголовке.
  3. Используйте сторонний инструмент, такой как Raygun.io , или любой инструмент APM, такой как New Relic .

...