Различайте вход и разрешение действия
Авторизация пользователя в смысле входа подтверждает его личность, но не делает все данные доступными. Для каждого запроса серверу нужно понять, к какому объекту обращается человек и что он вправе с ним делать.
OWASP относит нарушения доступа к объектам и функциям к важным рискам API. В продукте это проявляется просто: пользователь может открыть чужой заказ по идентификатору или выполнить административное действие через прямой запрос. Скрытие кнопки в интерфейсе не является серверной проверкой.
Опишите права для полей и операций
Не все свойства объекта одинаково доступны. Пользователь может менять контактный комментарий, но не внутренний статус оплаты. Если сервер принимает произвольный набор полей, можно случайно разрешить изменение того, что интерфейс не предлагал.
Определите допустимые входные поля и состав ответа для каждой операции. Проверяйте роль и принадлежность объекта. В ответ не должны попадать лишние внутренние сведения только потому, что они существуют в модели базы данных.
Ограничьте ресурсоёмкие действия
Запрос может запускать дорогой поиск, формировать большой экспорт, отправлять сообщение или вызывать платный внешний сервис. Такие операции требуют лимитов и понятного контроля. Ограничения определяются не только числом HTTP-запросов, но и стоимостью конкретного действия.
Различайте обычную работу, массовую операцию и новый аккаунт без истории. Для длинных задач полезны очередь и ограничение параллельности. Пользователю нужно объяснять ожидание и возможность продолжить, а команде — видеть причины ограничения.
Проверяйте внешние данные и адреса
Интеграция получает сведения из другого сервиса, но это не делает их автоматически корректными. Проверяйте формат, допустимые значения и границы объёма. Не позволяйте внешнему ответу бесконтрольно управлять внутренними действиями.
Если продукт загружает содержимое по пользовательскому URL, отдельно проработайте допустимые назначения и защиту от доступа к внутренним ресурсам. Проверки должны действовать на сервере, включая перенаправления и фактический адрес соединения. Сценарий и его ограничения описываются до запуска.
Сделайте журнал полезным и ограниченным
Журнал помогает установить, какая операция происходила, кем она выполнена и каким результатом завершилась. Для критичных изменений нужна связь с бизнес-объектом и возможность расследовать последовательность действий.
При этом не следует сохранять пароли, токены и полные документы без необходимости. Определите состав записей, срок хранения и круг доступа. Сообщение пользователю должно объяснять продолжение работы, а диагностические подробности доступны только уполномоченной команде.
Включите проверки в приёмку и развитие
Составьте тестовые роли и объекты нескольких владельцев. Проверяйте чтение, изменение, экспорт, файлы и административные маршруты. Добавьте превышение лимита, повтор операции и ошибку внешнего сервиса.
Список вопросов не заменяет специализированную проверку сложной системы, но делает ожидания владельца продукта конкретными. После появления нового API или роли обновляйте набор сценариев. Безопасность должна поддерживать реальные правила работы продукта.
Проверяйте права на объект и действие на сервере.
Что проверить перед следующим шагом
- Проверяйте права на объект и действие на сервере.
- Разделите допустимые поля запроса и ответа.
- Определите лимиты для дорогих операций.
- Проверяйте внешние данные и назначения запросов.
- Не включайте секреты в журналы и открытые ошибки.
- Повторяйте проверки после добавления ролей и API.
Материал PENROUZ · 13 октября 2026. Практические рекомендации изложены для планирования проекта.
Как мы готовим материалы ↗Разработка личного кабинета для клиентов
Проектируем и разрабатываем клиентские кабинеты: заказы, документы, обращения, доступ к услугам и понятные статусы. Соединяем интерфейс с реальными процессами компании.
Посмотреть состав решения ↗