Как защитить конечную точку API для сообщения об ошибках JS на стороне клиента от спама (если это вообще необходимо)?
Я разрабатываю веб-приложение с Spring Boot и SPA React.js, но мой вопрос не относится к этим библиотекам/фреймворкам, так как я предполагаю, что отчет об ошибках JS на стороне клиента на сервере (для регистрации и анализа) должен быть распространенным работы для многих современных веб-приложений.
Итак, предположим, что у нас есть клиентское приложение JS, которое перехватывает ошибку, и конечная точка REST, которая принимает объект JSON, содержащий соответствующую информацию о том, что произошло. Клиентское приложение отправляет данные на сервер, они сохраняются в базе данных (или где-то еще), и все довольны, верно?
Сейчас нет, правда. Потому что теперь у меня есть открытая (как в разрешение операций создания/записи без проверки подлинности) конечная точка API, и каждый, обладающий небольшими знаниями, может легко спамить.
Я мог бы проверить структуру данных JSON, которые принимает конечная точка, но В самом деле не решит проблему.
В вопросах типа "Открытый REST API, подключенный к базе данных — что мешает злоумышленникам спамить мою базу данных?" или "Secure Rest-Service перед аутентификацией пользователя" есть такие предложения, как:
- квоты доступа (но я не хочу сохранять IP-адреса или что-то еще для идентификации клиентов)
- Капчи (бесполезно для сообщения об ошибках, очевидно)
- подтверждение адреса электронной почты (то же самое, только представьте)
Итак, мои вопросы:
- Существует ли элегантная, широко используемая стратегия для защиты такой конечной точки?
- Будет ли на практике достаточно легковесного решения, такого как проверка структуры данных?
- Все это вообще необходимо? В конце концов, я не буду рекламировать свою конечную точку API обработки ошибок с помощью баннера в приложении...
@DanH Потому что клиентское приложение (js) всегда должно иметь возможность отправлять данные об ошибках на сервер. Меня интересуют любые ошибки в клиентском приложении, как вошедшие в систему пользователи, так и посетители.
Используете ли вы OAuth 2.0 с сервером идентификации для защиты API?
Ответы 1
Я видел, как это делается тремя разными способами…
Предположим, вы используете OAuth 2 для защиты своего API. Встаньте два конечные точки ошибок.
- Для вошедшего в систему пользователя, если возникают ошибки, вы бы попадет в конечную точку /error и будет аутентифицироваться с использованием существующего токен авторизации пользователя.
- Для посетителя вы можете указать /clientError (или имя, которое имеет для вас смысл) конечная точка, которая принимает Токен client_credentials для клиентского приложения.
Защитите конечную точку /error с помощью ключа API, доступного для доступ только к конечной точке ошибки.
- Этот ключ будет специфичным для client и будет передан в заголовке.
Используйте сторонний инструмент, например Raygun.io, или любой инструмент APM, например Новая реликвия.
Почему бы не защитить конечную точку /errors с той же безопасностью, что и в вашем API?