Новый endpoint не добавили в правила авторизации. Как должен повести себя безопасный механизм доступа?
Безопасный механизм должен отказать в доступе по умолчанию: отсутствие правила для endpoint трактуется как запрет, а не как разрешение. Это называется принципом fail-closed и запрещающими настройками по умолчанию.
Тестировщик должен подтвердить, что новый endpoint недоступен без явно заданного разрешения. Публичный доступ также должен оформляться отдельным явным правилом, а не возникать из-за отсутствия записи в политике.
Принцип запрета по умолчанию появился как ответ на риск неполных или ошибочных правил безопасности. В больших системах политики доступа постоянно меняются, а новые маршруты и операции могут добавляться быстрее, чем для них обновляют конфигурацию авторизации.
Если система разрешает доступ при отсутствии подходящего правила, любая ошибка настройки превращается в потенциальную уязвимость. Подход fail-closed ограничивает последствия такой ошибки: неизвестная операция блокируется до тех пор, пока для неё явно не определят допустимый доступ.
Предположим, разработчик добавил endpoint для просмотра внутренних отчётов, но не зарегистрировал его в политике ролей. При модели «разрешить, если запрета нет» обычный аутентифицированный пользователь может получить доступ к данным, которые ему не предназначены.
Риск возникает не только для новых маршрутов. Он также появляется при ошибке сопоставления пути, неизвестной роли, сбое загрузки политики или непредусмотренном значении разрешения. Последствиями могут стать раскрытие данных, выполнение административных операций или обход разделения обязанностей.
Безопасный алгоритм сначала должен определить субъект запроса, требуемое действие и защищаемый ресурс, а затем найти для них подходящее явное разрешение. Если разрешение не найдено, политика недоступна, правило неоднозначно или роль неизвестна, результатом должен быть отказ.
Отказ должен происходить на серверной стороне, до выполнения защищаемой операции. Скрытие кнопки в интерфейсе не является защитой: клиент можно изменить, а endpoint вызвать напрямую. Код ответа может зависеть от принятой модели ошибок, но он не должен выдавать защищённый результат; обычно применяются отказ в доступе или отсутствие ресурса, если это нужно для сокрытия самого факта существования объекта.
При тестировании полезно проверять не только штатный endpoint, но и варианты, которые часто ломают сопоставление правил: близкие пути, разные HTTP-методы, завершающий разделитель, альтернативное представление регистра, неизвестная роль и недоступная политика. Важно убедиться, что отсутствие правила не превращается в разрешение из-за значения по умолчанию.
У такого подхода есть компромисс: ошибка конфигурации может временно сделать функцию недоступной. Это безопаснее, чем автоматически открыть её, но требует мониторинга отказов, проверок политик в процессе сборки и явного описания публичных операций.
Команда добавила операцию экспорта отчётов. Вариант с глобальным разрешением доступа был прост в реализации, но создавал риск раскрытия данных при появлении нового маршрута. Вариант с запретом по умолчанию требовал добавить отдельное правило и тесты для каждой допустимой роли, зато ошибка регистрации приводила к отказу, а не к утечке.
Выбрали второй вариант: endpoint стал недоступен до явного назначения разрешения, после чего проверили доступ разрешённой роли и отказ для остальных. В результате забытая запись в политике обнаружилась на этапе интеграционного тестирования, до выпуска функции пользователям.
Нет. Решение об авторизации должно приниматься до побочного эффекта: изменения данных, запуска задачи или отправки чувствительного ответа. Если система сначала выполняет операцию, а затем проверяет разрешение, это не защищённый отказ, даже если клиент получил ошибку.
Да. Публичность должна быть явно заявлена в политике, иначе невозможно отличить преднамеренно открытый маршрут от забытого или неправильно сопоставленного. Явное правило также упрощает аудит и позволяет тестами обнаружить случайное изменение статуса endpoint.
Он должен отказать в доступе к защищаемым операциям, то есть сохранить режим fail-closed. Продолжение работы с пустой политикой, кэшем неизвестного состояния или разрешением по умолчанию может открыть доступ именно во время сбоя, когда контроль особенно важен.