The post has been translated automatically. Original language: Russian
An API often becomes critical before a team has built a mature security process. A mobile app is followed by partner integrations, a dashboard, and public documentation. One backend starts serving users, administrators, and external systems with different privileges but not always different controls.
This review does not replace an audit or penetration test. It is a minimum filter for catching expensive mistakes before production.
1. Authorize access to every object
If an endpoint accepts user_id, order_id, or document_id, the server must not trust the identifier. Verify that the current user may read or modify that specific object.
2. Separate object and function permissions
A user may view an order but may not perform refund. Check both ownership and permission to execute the requested action.
3. Do not treat a token as sufficient protection
Test token lifetime, session revocation, password changes, account suspension, and sign-out from all devices. A disabled account must not retain access through a long-lived token.
4. Validate input and filter output
Use strict schemas for types, length, allowed values, and required fields. Do not return database objects wholesale. Explicit response DTOs reduce accidental exposure of internal fields.
5. Limit more than request count
An IP rate limit is not enough. Add limits per user, token, organization, and expensive operation. Control file size, export volume, query depth, and third-party service cost.
6. Remove secrets from code and logs
Keep keys and passwords in a proper secret store and rotate them. Logs must not contain tokens, full identity numbers, financial data, or sensitive request bodies.
7. Maintain an API inventory
An obsolete endpoint remains an attack surface. Record the owner, environment, version, consumers, and retirement date for each API.
8. Do not blindly trust third-party APIs
Partner data is external input. Validate schemas, timeouts, response sizes, redirects, and allowed destinations. A compromised supplier must not automatically compromise your product.
9. Prepare observability and response
Monitor authorization failures, identifier enumeration, abnormal volume, and error spikes. Know who receives the alert, how access is revoked, how an endpoint is restricted, and how affected users are identified.
A one-hour review
- Select five sensitive endpoints.
- Test them with three roles and without authentication.
- Replace object identifiers.
- Send extra fields, large values, and repeated requests.
- Verify that secrets do not appear in responses or logs.
- Assign every finding an owner and deadline.
OWASP API Security Top 10 explicitly covers broken object and function authorization, unrestricted resource consumption, security misconfiguration, poor API inventory, and unsafe consumption of third-party APIs.
Conclusion
API security is not a final release checkbox. It is a set of testable constraints defining who can access what, perform which action, and consume how much. Moving these rules into automated tests and code review reduces dependence on individual vigilance.
Which of these nine checks is most often postponed in your project?
API часто становится критической частью продукта раньше, чем команда успевает выстроить полноценный процесс безопасности. Сначала появляется мобильное приложение, затем интеграция с партнёром, личный кабинет и публичная документация. В итоге один и тот же backend начинает обслуживать пользователей, администраторов и внешние системы — с разными правами, но не всегда с разными ограничениями.
Ниже — практический pre-release review. Это не замена аудиту или penetration test, а минимальный фильтр, который помогает поймать дорогие ошибки до продакшена.
1. Проверяйте доступ к каждому объекту
Если endpoint принимает user_id, order_id или document_id, сервер не должен верить идентификатору из запроса. Для каждого объекта нужно отдельно проверить: имеет ли текущий пользователь право читать или изменять именно его?
Простой тест: авторизуйтесь как пользователь A, перехватите запрос и подставьте идентификатор объекта пользователя B. Ответ должен быть отказом, а не чужими данными.
2. Разделяйте объектные и функциональные права
Пользователь может иметь доступ к своему заказу, но не к операции refund. Менеджер может видеть клиентов своего отдела, но не экспортировать всю базу. Проверяйте не только «кому принадлежит объект», но и «разрешено ли этой роли выполнять действие».
3. Не считайте наличие токена достаточной защитой
Проверьте срок жизни access-токенов, отзыв сессий, смену пароля, выход со всех устройств и блокировку пользователя. Отключённая учётная запись не должна сохранять действующий доступ до истечения длинного токена.
4. Валидируйте вход и фильтруйте выход
Используйте строгие схемы: типы, длина, допустимые значения, обязательные поля. Не возвращайте объект базы данных целиком «для удобства frontend». Явно формируйте response DTO, чтобы внутренние поля, роли, себестоимость или служебные признаки случайно не попали в ответ.
5. Ограничивайте не только число запросов
Rate limit по IP недостаточен. Нужны лимиты по пользователю, токену, организации и дорогой операции. Отдельно контролируйте размер файла, глубину запроса, число записей в экспорте и стоимость обращения к стороннему сервису.
6. Уберите секреты из кода и логов
API-ключи и пароли должны храниться в предназначенном для этого хранилище и регулярно ротироваться. Логи не должны содержать токены, полные номера документов, банковские данные и тела чувствительных запросов. Маскирование лучше внедрить централизованно, а не надеяться на внимательность каждого разработчика.
7. Ведите актуальный реестр API
Забытая старая версия endpoint остаётся поверхностью атаки. Для каждого API зафиксируйте владельца, окружение, версию, потребителей и дату вывода из эксплуатации. Документация должна отражать реальность, а не состояние проекта полгода назад.
8. Не доверяйте ответам сторонних API
Данные партнёра — тоже внешний ввод. Проверяйте схему, таймауты, размер ответа, редиректы и допустимые адреса. Ошибка или компрометация поставщика не должна автоматически превращаться в вашу уязвимость.
9. Подготовьте наблюдаемость и план реакции
Логируйте отказы авторизации, аномальные объёмы, перебор идентификаторов и резкий рост ошибок. У команды должен быть ответ на четыре вопроса: кто получает алерт, как отозвать доступ, как ограничить endpoint и как определить затронутых пользователей?
Быстрый сценарий проверки за один час
- Выберите пять наиболее чувствительных endpoint.
- Проверьте их под тремя ролями и без авторизации.
- Подмените идентификаторы объектов.
- Отправьте лишние поля, большие значения и повторяющиеся запросы.
- Убедитесь, что секреты не появились в ответах и логах.
- Запишите найденные риски с владельцем и сроком исправления.
OWASP API Security Top 10 отдельно выделяет нарушения объектной и функциональной авторизации, неограниченное потребление ресурсов, неправильную конфигурацию, слабый учёт версий и небезопасное использование сторонних API. Поэтому хороший review проверяет не один «главный endpoint», а весь жизненный цикл доступа и данных.
Итог
Безопасность API — не финальная галочка перед релизом. Это набор проверяемых ограничений: кто, к чему, каким способом и в каком объёме имеет доступ. Чем раньше эти правила становятся частью тестов и code review, тем меньше команда зависит от ручной внимательности.
Какой из девяти пунктов чаще всего откладывается в вашем проекте?
Share
