Какие меры безопасности вы заложите при проектировании публичного REST API с личным кабинетом пользователя?
- Как обеспечить безопасность REST API?
- Какие меры защиты нужны личному кабинету?
По слоям: контроль доступа → аутентификация → ввод и транспорт → что отдаём наружу → эксплуатация.
- Доступ: проверка владения в каждом запросе, запрет по умолчанию, различие 401 и 403
- Аутентификация: argon2/bcrypt, короткий access и отзываемый refresh, лимит попыток входа, 2FA
- Ввод: параметризованные запросы, валидация, лимиты размера и частоты, TLS
А ещё Наружу — код ошибки и correlation id вместо стектрейса; одинаковое сообщение при неверном логине и пароле
Подробно
Контроль доступа — самая частая уязвимость. Проверка владения ресурсом на сервере в каждом запросе (лучше в выборке из базы), модель запрета по умолчанию, централизованные политики для ролей. 401 — не аутентифицирован, 403 — нет прав (а для чужих ресурсов часто 404).
Аутентификация: пароли — argon2id или bcrypt с солью; короткоживущие access-токены и отзываемые refresh; фиксированный алгоритм подписи; ограничение попыток входа и защита от перебора (задержки, капча); двухфакторная аутентификация; безопасное восстановление пароля (одноразовые токены с коротким сроком).
Ввод и транспорт: параметризованные запросы против инъекций; валидация схемы и размера тела; ограничение частоты по ключу и IP; только HTTPS, HSTS; внутри периметра — mTLS; CORS только для своих источников; защита cookie: HttpOnly, Secure, SameSite.
Что отдаём: ошибки без стектрейсов и SQL — код и correlation id; одинаковый ответ на «нет пользователя» и «неверный пароль»; не отдавать лишние поля (массовое присвоение и раскрытие данных — явные DTO).
Эксплуатация: секреты в менеджере с ротацией; проверка зависимостей в сборке; журналирование событий безопасности (входы, смены пароля, отказы доступа) и алерты на аномалии; регулярные тесты на проникновение.
Что хотят услышать
- Структурированный ответ по слоям.
- Контроль доступа как главный риск.
- Конкретные меры аутентификации и защиты ввода.
- Утечки через ошибки и эксплуатационные меры.
Частые ошибки
- Перечислять OWASP Top 10 без привязки к API.
- Забыть про контроль доступа к объектам.
Проверьте себя
Один верный вариант. Подумайте, потом откройте ответ.
Показать варианты и ответ
- ✓Проверка владения ресурсом в каждом запросе, надёжная аутентификация, валидация ввода, без утечек в ошибках
- ✗Достаточно HTTPS
- ✗Скрыть идентификаторы, заменив их на UUID
- ✗Отдавать подробный стектрейс в ответе, чтобы клиент мог понять причину ошибки и повторить запрос
Что спросят дальше
- Как вы обнаружите, что API уже атакуют?
- Что такое zero trust и зачем mTLS внутри периметра?
Разбор темы
- Безопасность приложения: OWASP, доступ и секреты
OWASP Top 10 в редакции 2025, разница аутентификации и авторизации, ловушки JWT против сессий, хранение паролей и секретов, безопасность цепочки поставок.
Связанные вопросы
- Эндпоинт GET /orders/{id} проверяет, что пользователь аутентифицирован, и возвращает заказ по идентификатору. Что здесь не так? Middle
- Что верно про использование JWT для аутентификации? Middle
- Чем bcrypt и argon2 принципиально отличаются от SHA-256 применительно к хранению паролей? Middle
- Что такое SQL-инъекция и как от неё защититься? Junior
- Что такое XSS и как от неё защищаться? Junior
- Что такое CSRF и как он связан с CORS? Middle
- Какие алгоритмы ограничения частоты запросов вы знаете? Middle
Разбор собеседования с sotto
После собеседования sotto разбирает разговор: оценка, каждый вопрос — хорошо, частично или слабо, чего не хватило в ответе и над чем поработать к следующему разу. Первые 30 минут бесплатно.