Разрешения

Что такое разрешения доступа

Разрешение определяет, может ли конкретный пользователь, приложение, сервис или другой субъект выполнить определённое действие над защищаемым объектом.

В простой системе разрешение может выглядеть так:

читать статью

редактировать статью

публиковать статью

удалять пользователя

просматривать заказ

возвращать платёж

Но в реальном приложении одного названия действия часто недостаточно.

Пользователю может быть разрешено редактировать только собственные записи.

Менеджеру только заказы своей организации.

Редактору статьи, но не настройки сайта.

Интеграции только чтение определённого API.

Поэтому современная модель разрешений отвечает сразу на несколько вопросов: кто запрашивает действие, что именно он хочет сделать, над каким объектом и при каких условиях.

OWASP определяет access control или authorization как процесс разрешения или запрета конкретного запроса пользователя, программы или процесса. Среди базовых рекомендаций OWASP выделяет минимальные привилегии, запрет по умолчанию и проверку разрешений для каждого запроса.

Разрешения, права и privileges

В практической разработке слова «разрешение», «право» и permission часто используются как близкие понятия.

Например:

edit_posts

delete_users

view_invoice

refund_payment

описывают конкретные действия, которые субъекту разрешено выполнять.

Термин privilege обычно шире и может обозначать предоставленный субъекту уровень полномочий или совокупность разрешений.

Для архитектуры важнее не терминология, а однозначность модели.

Команда должна понимать, какое конкретно действие защищает каждое разрешение и на какие объекты оно распространяется.

Разрешение с названием manage_everything практически ничего не говорит о фактической границе доступа.

Разрешения orders.read, orders.update и orders.refund значительно точнее описывают возможности системы.

Разрешения и аутентификация

Аутентификация отвечает на вопрос:

Кто выполняет запрос?

Например, система проверила пароль, токен, passkey или другой способ подтверждения личности и установила, что запрос выполняет пользователь с идентификатором 154.

Но успешный вход ещё не означает право выполнять любое действие.

OWASP отдельно подчёркивает различие между authentication и authorization. Аутентифицированный пользователь может не иметь разрешения на конкретный ресурс или операцию.

Например, клиент успешно вошёл в личный кабинет.

Это не означает, что он может открыть административную страницу или изменить заказ другого клиента.

Разрешения и авторизация

Авторизация использует правила доступа, чтобы принять решение о конкретном запросе.

Условно:

Пользователь 154 может редактировать документ 78?

Система проверяет разрешения, роль, владельца объекта, организацию, состояние документа или другие условия.

Результатом становится:

разрешить

или:

запретить

Таким образом, разрешение является частью модели доступа, а авторизация является процессом принятия и применения решения.

На Vagizov.com уже существует отдельная услуга по настройке авторизации, где рассматриваются регистрация, вход, восстановление, роли, личный кабинет, 2FA и SSO. Текущая taxonomy должна оставаться уже по интенту и раскрывать именно разрешения и правила выполнения действий после определения пользователя.

Разрешения и роли

Роль это удобный способ объединить несколько разрешений.

Например, роль Редактор может получить:

articles.read

articles.create

articles.update

articles.publish

При этом ей не обязательно разрешать:

users.delete

plugins.install

settings.update

NIST определяет Role Based Access Control как модель, в которой разрешённые действия над ресурсами связываются с ролями, а не непосредственно с идентичностью каждого пользователя.

Это позволяет управлять доступом группами.

Вместо настройки тридцати разрешений для каждого нового редактора ему назначается соответствующая роль.

Роль не должна заменять проверку разрешения

В коде легко начать проверять:

если пользователь администратор, разрешить

если менеджер, разрешить

если редактор, запретить

При небольшой системе это кажется удобным.

Но по мере развития появляются новые роли, исключения и разные правила для отдельных объектов.

Тогда код заполняется проверками названий ролей.

Более устойчивый подход состоит в проверке требуемого разрешения или политики.

Например:

может ли пользователь вернуть этот платёж

а не:

является ли пользователь менеджером

Роль становится одним из способов получить набор полномочий, а бизнес логика остаётся привязанной к конкретному действию.

Матрица разрешений

До разработки сложной системы доступа полезно составить матрицу.

По одной оси располагаются типы пользователей или роли.

По другой объекты и действия.

Например, для заказа можно отдельно определить:

просмотр

создание

редактирование

отмена

возврат платежа

изменение владельца

экспорт персональных данных

Так быстро обнаруживаются слишком широкие роли.

Менеджеру может быть нужен просмотр и изменение статуса заказа, но не возврат любого платежа.

Контент менеджеру может быть нужен доступ к товарам, но не к пользователям и настройкам платежной системы.

На Vagizov.com аналогичный подход используется при проектировании авторизации: до разработки фиксируются роли, объекты и разрешённые действия.

Принцип минимальных привилегий

Один из базовых принципов контроля доступа состоит в том, что субъект получает только те полномочия, которые необходимы для выполнения его задачи.

NIST определяет least privilege как ограничение пользователя или процесса минимальным набором системных ресурсов и разрешений, необходимых для выполнения функции.

Если редактору достаточно публиковать статьи, ему не требуется право устанавливать плагины.

Если интеграции достаточно читать список заказов, ей не требуется их удалять.

Если сотруднику нужен доступ к одной организации, ему не нужно автоматически давать доступ ко всем клиентам системы.

Минимальные разрешения уменьшают последствия как взлома учётной записи, так и обычной человеческой ошибки.

Deny by default

Безопасная модель должна исходить из запрета.

Если система не нашла правила, которое явно разрешает действие, результатом должен быть отказ.

OWASP рекомендует подход deny by default и указывает, что приложение должно явно обосновывать предоставление доступа, а не считать его разрешённым при отсутствии подходящего ограничения.

Это особенно важно после добавления нового функционала.

Представим новый административный endpoint.

При модели allow by default он может случайно оказаться доступным всем аутентифицированным пользователям, пока разработчик не добавит отдельный запрет.

При deny by default новый ресурс остаётся закрытым, пока разрешение не будет предоставлено явно.

Проверка должна выполняться при каждом запросе

Нельзя проверить права только при входе и считать, что дальнейшие действия автоматически допустимы.

Пользователь может открыть другой URL.

Отправить запрос напрямую в API.

Изменить идентификатор объекта.

Повторить старый запрос.

Изменить параметры формы.

Поэтому разрешение проверяется при выполнении каждой защищаемой операции.

OWASP прямо рекомендует валидировать permissions на каждом запросе независимо от того, инициирован он обычной страницей, AJAX, API или другим способом.

Проверка должна происходить на доверенной стороне

JavaScript может скрыть кнопку.

CSS может скрыть пункт меню.

Frontend может не показывать административный экран.

Но пользователь контролирует собственный браузер.

Он может самостоятельно отправить HTTP запрос.

Поэтому frontend ограничение является только UX механизмом.

Решение о доступе должно проверяться на серверной стороне, API gateway или другом доверенном компоненте, который пользователь не может изменить.

OWASP Top 10:2025 прямо приводит контроль доступа только на frontend как пример Broken Access Control.

Скрытая кнопка не является разрешением

Представим страницу заказа.

Обычный клиент не видит кнопку:

Вернуть платёж

Администратор видит.

Если backend endpoint возврата не проверяет permission, обычный пользователь может вызвать его вручную.

Например, через DevTools, curl или собственный скрипт.

Поэтому интерфейс может отражать существующие права, но никогда не должен быть единственным местом их реализации.

На Vagizov.com этот же принцип применяется в услуге настройки авторизации: доступ проверяется на сервере, а не только через скрытие кнопок.

Права на объект

Разрешения часто зависят не только от типа действия, но и от конкретного объекта.

Например, пользователь может иметь право:

orders.read

Но это не означает доступ к любому заказу системы.

Необходимо дополнительно проверить:

этот заказ принадлежит текущему пользователю?

или:

этот заказ относится к организации пользователя?

Так появляется объектная авторизация.

OWASP Top 10:2025 относит возможность просмотра или изменения чужого объекта через подмену его идентификатора к Broken Access Control.

Горизонтальное повышение привилегий

Горизонтальная эскалация происходит, когда пользователь получает доступ к ресурсам другого пользователя того же уровня.

Например:

клиент может посмотреть чужой заказ

сотрудник одной компании видит документы другой

пользователь меняет чужой профиль

Если URL выглядит так:

/account/orders/185

нельзя считать заказ доступным только потому, что пользователь авторизован.

Backend должен проверить отношение между текущим субъектом и заказом 185.

OWASP отдельно выделяет доступ к ресурсам другого пользователя как распространённую проблему авторизации.

Вертикальное повышение привилегий

Вертикальная эскалация означает получение полномочий более высокого уровня.

Например:

пользователь получает функции администратора

редактор устанавливает плагины

менеджер назначает себе дополнительные роли

обычный API token получает административный endpoint

Причиной может быть отсутствующая серверная проверка, неправильное наследование, изменение пользовательских параметров или ошибка политики.

OWASP Top 10:2025 также относит privilege escalation к типичным последствиям Broken Access Control.

Разрешения уровня поля

Иногда доступ нужно контролировать не только к объекту, но и к отдельным его свойствам.

Например, менеджеру разрешено редактировать клиента:

имя

телефон

комментарий

Но нельзя менять:

роль

баланс

внутренний риск скоринг

владельца организации

Если API принимает весь объект без фильтрации разрешённых свойств, пользователь может попытаться отправить дополнительное поле вручную.

Поэтому permission model может включать field level access.

Особенно это важно для API, где клиент легко изменяет JSON запроса независимо от интерфейса.

Разрешения уровня функции

Система должна отдельно определять доступ к операциям.

Например:

просмотреть заказ

изменить адрес

отменить заказ

подтвердить возврат

экспортировать данные

Это разные возможности.

Право редактирования объекта не обязательно должно автоматически разрешать наиболее чувствительные действия.

Для критичных функций лучше использовать более точные разрешения.

Так становится возможен принцип минимальных привилегий без создания огромного количества ролей.

RBAC

Role Based Access Control хорошо подходит системам, где полномочия естественно связаны с рабочими функциями.

Например:

Клиент

Редактор

Менеджер

Бухгалтер

Администратор

Каждая роль получает набор разрешений.

NIST описывает RBAC как управление доступом через роли и связанные с ними разрешения.

Модель проста для объяснения и администрирования.

Но она начинает усложняться, когда решение зависит не только от профессии пользователя, но и от владельца объекта, организации, региона, времени или других условий.

Проблема role explosion

Представим B2B систему.

Сначала существуют:

manager

editor

Потом появляется необходимость различать:

менеджера своей организации

менеджера филиала

старшего менеджера

менеджера только для чтения

менеджера с возвратами

менеджера без экспорта

Если каждую комбинацию условий превращать в новую роль, количество ролей быстро растёт.

OWASP отмечает такую проблему RBAC и рекомендует для сложных прикладных моделей рассматривать более детальные подходы, включая ABAC и Relationship Based Access Control.

ABAC

Attribute Based Access Control принимает решение по атрибутам.

NIST определяет ABAC как модель, где доступ к операции определяется на основе атрибутов субъекта, объекта, запрашиваемого действия, условий среды и соответствующих политик.

Например:

пользователь работает в организации 52

документ принадлежит организации 52

пользователь имеет атрибут department=finance

документ имеет тип invoice

операция выполняется из разрешённой среды

Тогда политика может разрешить действие без создания отдельной роли под каждую комбинацию.

Атрибуты субъекта

К субъекту могут относиться:

организация

отдел

должность

уровень допуска

регион

тип аккаунта

статус

тариф

пройденное обучение

подтверждённая 2FA

Система использует только те атрибуты, которые реально нужны политике.

Чем больше условий участвует в решении, тем важнее контролировать источник и актуальность этих данных.

NIST отдельно подчёркивает необходимость надёжно устанавливать, хранить, обновлять и отзывать атрибуты, используемые системой контроля доступа.

Атрибуты объекта

Сам объект также может влиять на разрешение.

Например:

документ принадлежит организации

запись имеет владельца

файл содержит определённый уровень чувствительности

заказ находится в определённом статусе

проект относится к конкретной команде

Пользователь может иметь право редактировать черновик, но не подписанный документ.

Менеджер может просматривать заказы своей организации, но не остальных клиентов.

Такие правила сложно выразить одной глобальной ролью.

Условия среды

ABAC позволяет учитывать контекст запроса.

Например:

время

тип устройства

сеть

состояние дополнительной проверки

географический контекст

Но использовать динамические условия нужно осторожно.

Политика должна оставаться понятной и тестируемой.

Если доступ зависит от десятка скрытых факторов, сотрудникам и разработчикам становится сложно объяснить, почему конкретный запрос был разрешён или запрещён.

ReBAC

Relationship Based Access Control строит разрешение вокруг отношений между субъектом и объектом.

Например:

пользователь является владельцем документа

пользователь состоит в команде проекта

пользователь является участником организации

пользователь добавлен в список редакторов файла

OWASP приводит ReBAC как отдельную модель для детальных объектных разрешений и отмечает, что она особенно полезна там, где право определяется отношениями между пользователями и ресурсами.

Такой подход естественен для совместных документов, команд, социальных функций и B2B приложений.

ACL

Access Control List хранит правила рядом с объектом или ресурсом.

Условно:

документ 15

пользователь 3 может читать

пользователь 7 может редактировать

группа 5 может читать

Такой подход удобен там, где конкретный объект имеет собственный список участников.

Но большие ACL сложнее администрировать массово.

На практике модели могут сочетаться.

Например, базовые разрешения предоставляются через RBAC, а доступ к отдельному проекту дополнительно определяется отношением пользователя к нему.

Как выбрать модель

Не нужно выбирать RBAC, ABAC или ReBAC только по популярности.

Сначала описываются реальные требования.

Если права полностью зависят от рабочих ролей, RBAC может быть достаточно.

Если решение зависит от свойств пользователя, объекта и среды, ABAC становится естественнее.

Если основным условием является отношение к конкретному ресурсу, полезна relationship based модель.

OWASP рекомендует определять требования авторизации раньше выбора конкретного фреймворка или библиотеки, а не подстраивать бизнес правила под возможности готового компонента.

Разрешения в WordPress

WordPress разделяет роли и capabilities.

Официальная документация WordPress прямо определяет роль как набор задач, которые пользователь может выполнять, а конкретные разрешённые действия представлены capabilities.

Например:

edit_posts

publish_posts

upload_files

moderate_comments

manage_options

Пользователь получает capabilities через назначенную роль.

При необходимости разработчик может создавать собственные роли и capabilities.

Почему в WordPress лучше проверять capability

Плагину обычно не требуется спрашивать:

пользователь Administrator?

Лучше проверить способность выполнить нужное действие.

Например, если функция предназначена для пользователя с правом управления определёнными настройками, проверяется соответствующая capability.

Так кастомная роль сможет получить нужную возможность без необходимости становиться полным администратором.

Это соответствует общему принципу минимальных привилегий.

WordPress также предупреждает, что некоторые capabilities дают более широкий доступ, чем может казаться по конкретному интерфейсу. Поэтому при создании собственных ролей нужно учитывать фактические возможности каждого разрешения.

REST API WordPress тоже требует проверки прав

Открытие endpoint в WordPress REST API не должно автоматически означать доступ к операции.

Разные маршруты могут требовать собственные capability checks.

Официальная документация WordPress приводит примеры, где REST API проверяет edit_theme_options, edit_posts, edit_pages и другие capabilities в зависимости от запрашиваемого ресурса.

Поэтому скрыть административный интерфейс недостаточно.

Прямой REST запрос должен проверяться теми же правилами доступа.

Разрешения API token

Внешней интеграции также не обязательно предоставлять все права пользователя.

Токен может иметь ограниченный scope.

Например:

только чтение заказов

создание заявки

просмотр каталога

обновление остатков

без управления пользователями

Так компрометация одного ключа не предоставляет атакующему максимальные полномочия всей системы.

При проектировании API полезно рассматривать разрешения клиента отдельно от разрешений человека, от имени которого он может действовать.

Service accounts

Сервисы и фоновые процессы тоже являются субъектами доступа.

Например:

система резервного копирования

CRM интеграция

очередь обработки

бот

CI процесс

импортёр товаров

Им часто по привычке выдают административный ключ, потому что так быстрее запустить интеграцию.

Это нарушает принцип минимальных привилегий.

Сервис должен получать только необходимые действия и данные.

Если процесс только выгружает заказы, ему не нужно право удалять пользователей или менять настройки сайта.

Multi tenant системы

Особое внимание разрешениям требуется в системах с несколькими организациями.

Пользователь может иметь одинаковую роль manager, но только внутри своей компании.

Поэтому правило:

role == manager

недостаточно.

Нужно дополнительно проверить tenant или organization объекта.

Например:

пользователь принадлежит организации 15

заказ принадлежит организации 15

пользователю разрешено действие orders.read

Только совокупность условий даёт доступ.

Именно отсутствие объектной проверки часто приводит к горизонтальной эскалации.

Владелец объекта

Одна из самых распространённых политик выглядит так:

пользователь может изменять собственный объект.

Но слово «собственный» должно определяться сервером.

Нельзя доверять полю:

{
  "owner_id": 15
}

только потому, что его отправил frontend.

Backend должен получить текущего пользователя из доверенного контекста и самостоятельно проверить отношение к объекту.

Иначе атакующий изменит owner_id или идентификатор ресурса.

Разрешения должны учитывать состояние объекта

Иногда право зависит от жизненного цикла объекта.

Например:

черновик можно редактировать

опубликованный договор нельзя менять

отменённый заказ нельзя повторно отменить

платёж можно вернуть только после успешной оплаты

Здесь разрешение состоит из двух частей:

пользователь имеет соответствующее полномочие

текущее состояние объекта допускает операцию

Так бизнес правила становятся частью модели контроля доступа.

Административные разрешения

Особенно внимательно нужно выдавать возможности, которые позволяют менять саму модель доступа.

Например:

создание пользователей

назначение ролей

изменение permissions

выдача API ключей

управление SSO

изменение политик

Если пользователь может назначить себе более высокую роль, остальные ограничения теряют смысл.

Поэтому административные полномочия полезно дробить.

Человек, который создаёт аккаунты сотрудников, не обязательно должен уметь назначать максимальные системные права.

Разрешения по умолчанию

Новый пользователь, роль, API клиент или интеграция не должны автоматически получать широкий набор полномочий.

Безопаснее начинать с минимального уровня и добавлять необходимое.

OWASP рекомендует deny by default именно потому, что при появлении нового ресурса или функции отсутствие явно заданного правила не должно превращаться в разрешение.

Это также упрощает аудит.

Можно объяснить, зачем конкретный permission был предоставлен.

Наследование разрешений

Иерархические роли могут уменьшать дублирование.

Например, старший редактор получает возможности обычного редактора плюс публикацию.

Но наследование нужно проектировать осторожно.

Если роль верхнего уровня автоматически наследует слишком широкий набор permissions, одна ошибка затрагивает множество пользователей.

Особенно сложно становится при множественном наследовании и исключениях.

Чем сложнее иерархия, тем важнее иметь машинно проверяемую матрицу доступа.

Запреты и разрешения

Система должна заранее определить, как разрешаются конфликты.

Например:

роль пользователя разрешает действие

политика объекта запрещает

другая группа снова разрешает

Какой результат должен победить?

Если это не определено архитектурой, разные части приложения могут принимать разные решения.

Во многих безопасных моделях явный запрет имеет приоритет или применяется общий принцип deny by default.

Но конкретную семантику нужно закрепить в одном месте и тестировать.

Временные разрешения

Некоторые полномочия нужны только на ограниченный период.

Например, подрядчику предоставляется административный доступ для диагностики.

После завершения работы такой доступ должен быть отозван.

Вместо постоянной роли можно использовать временное назначение с датой истечения или отдельный ограниченный аккаунт.

Это уменьшает накопление «вечных» доступов, о существовании которых через год никто не помнит.

Жизненный цикл доступа

Разрешения нужно контролировать не только при создании аккаунта.

Сотрудник может перейти в другой отдел.

Проект закончиться.

Подрядчик завершить работу.

Организация изменить тариф.

Пользователь быть заблокирован.

Интеграция перестать использоваться.

Поэтому модель должна поддерживать изменение и отзыв полномочий.

Без процесса ревизии со временем практически любая система накапливает лишние права.

Удаление пользователя и отзыв доступа

Удаление аккаунта не всегда достаточно.

Могут существовать:

активные сессии

API tokens

refresh tokens

ключи интеграций

делегированный доступ

приглашения

временные ссылки

При отзыве прав нужно понимать, какие связанные credentials продолжают работать.

Иначе пользователь визуально удалён из панели, но старый token продолжает давать доступ к API.

Проверка прямого URL

Каждый закрытый экран нужно тестировать не только через меню.

Необходимо открыть его адрес напрямую пользователем без нужных permissions.

Например:

/admin/settings
/account/other-user
/export/customers

Если URL закрыт только потому, что ссылка не отображается, это Broken Access Control.

OWASP Top 10:2025 прямо приводит force browsing к защищённым страницам как типичный сценарий обхода контроля доступа.

Проверка изменения идентификатора

Для object level authorization полезен простой тест.

Пользователь открывает собственный объект:

/orders/184

Затем идентификатор меняется:

/orders/185

Если 185 принадлежит другому человеку, система должна отказать в доступе независимо от того, существует ли такой объект.

Такие проверки особенно важны для заказов, заявок, документов, файлов, профилей и API ресурсов.

Права на статические файлы

Авторизация требуется не только динамическим страницам.

Закрытый PDF может быть защищён интерфейсом, но при этом находиться по публично доступному URL.

То же касается:

резервных копий

экспортов

приватных изображений

договоров

отчётов

файлов пользователей

OWASP рекомендует включать статические ресурсы в общую модель access control и не предполагать, что отсутствие ссылки делает файл закрытым.

Права файловой системы

Разрешения приложения и permissions файловой системы относятся к разным уровням, но используют похожий принцип.

Web серверу не требуется запись во все каталоги.

PHP процессу не обязательно иметь доступ к файлам других сайтов.

Пользователь сервера не должен получать root полномочия только ради выполнения одной операции.

Таким образом, принцип минимальных привилегий применяется и к ОС.

В родительском разделе «Права доступа» Vagizov.com уже опубликован отдельный материал об изоляции WordPress сайтов на сервере. Он рассматривает разделение PHP FPM и ограничение межсайтового доступа. Поэтому текущая taxonomy «Разрешения» должна сосредоточиться прежде всего на логических permissions приложения, не дублируя тему серверной изоляции.

Broken Access Control

Ошибки разрешений относятся к наиболее существенным рискам веб приложений.

В актуальном OWASP Top 10:2025 категория Broken Access Control занимает позицию A01. Она включает обход проверок доступа, просмотр или изменение чужих объектов, доступ к API без необходимых ограничений, privilege escalation и другие нарушения модели разрешений.

Это объясняет, почему permissions нельзя рассматривать как второстепенную настройку административной панели.

Ошибка доступа может позволить читать, изменять или удалять данные другого пользователя даже при полностью корректной аутентификации.

Логирование отказов доступа

Не каждый 403 является атакой.

Пользователь может открыть старую ссылку.

Права могли быть изменены.

Интерфейс мог содержать ошибку.

Но систематические неуспешные попытки доступа полезно журналировать.

OWASP рекомендует логировать события и отказы контроля доступа и при необходимости создавать уведомления для повторяющихся подозрительных сценариев.

При этом журнал не должен содержать секреты, пароли и другие данные, не необходимые для диагностики.

Кто изменил разрешения

Для административных систем полезен отдельный audit trail.

Например:

кто назначил роль

кому

какие права изменились

когда

какое значение было раньше

Это особенно важно, если полномочия влияют на финансовые операции, персональные данные или административный доступ.

Без истории сложно отличить ошибку конфигурации от намеренного повышения привилегий.

Тестирование матрицы доступа

Модель разрешений должна проверяться автоматически.

Например:

гость не видит закрытый документ

клиент видит собственный заказ

клиент не видит чужой заказ

редактор может изменить статью

редактор не может назначить администратора

менеджер своей организации видит её клиентов

менеджер другой организации не видит их

OWASP рекомендует создавать unit и integration тесты для правил авторизации и использовать их как часть контроля регрессий.

Тестировать нужно отрицательные сценарии

Разработчики часто проверяют только:

администратор может открыть страницу

Но безопасность определяется и обратным условием:

обычный пользователь не может открыть страницу

Для каждой чувствительной операции нужен хотя бы один отрицательный сценарий.

Лучше проверять несколько типов нарушения:

неавторизованный пользователь

авторизованный пользователь без permission

пользователь с нужной ролью, но чужим объектом

заблокированный пользователь

истёкший доступ

прямой API запрос

Разрешения после добавления новой функции

Новый endpoint или административная страница должны сразу получать правило доступа.

Не следует сначала выпускать функциональность, а потом вспоминать о permissions.

При deny by default новая операция останется закрытой до явного разрешения.

Так модель безопаснее развивается по мере роста приложения.

Разрешения после обновлений

Обновление CMS, плагина или собственного приложения может добавлять новые capabilities и маршруты.

Поэтому после существенных изменений полезно повторно проверять критичные роли.

Например, новая возможность WordPress или плагина может зависеть от capability, которая раньше имела более узкий эффект.

Официальная документация WordPress отдельно предупреждает, что некоторые capabilities предоставляют доступ сразу к нескольким административным функциям.

Слишком широкая роль администратора

Администратор часто используется как универсальное решение:

не работает, дадим admin

Так проблема исчезает, но принцип минимальных привилегий нарушается.

Для временной диагностики такой подход ещё можно контролировать.

Для постоянной работы сотрудника лучше определить необходимые возможности и создать подходящую модель доступа.

Особенно опасно использовать один общий административный аккаунт несколькими людьми.

В такой ситуации невозможно нормально установить, кто выполнил конкретное действие.

Разрешения для редакторов сайта

Редактору контента обычно нужны возможности:

создавать материалы

редактировать разрешённые материалы

загружать медиа

публиковать при необходимости

Но ему редко требуется:

устанавливать плагины

изменять PHP файлы

создавать администраторов

менять системную конфигурацию

управлять API ключами

WordPress изначально использует разделение ролей и capabilities именно для такого ограничения пользовательских обязанностей.

Разрешения интернет магазина

В ecommerce модель быстро становится сложнее.

Например, сотрудник поддержки может видеть заказ и изменить адрес доставки.

Бухгалтеру нужен доступ к оплате и возвратам.

Контент менеджеру к товарам.

Складскому сотруднику к остаткам.

Администратору к настройкам системы.

Объединить всё это в одну роль manager удобно только на первом этапе.

По мере роста проекта лучше разложить полномочия по фактическим бизнес операциям.

Разрешения B2B кабинета

В B2B системе часто недостаточно обычной пары ролей.

Могут существовать:

организация

владелец организации

сотрудник

подразделение

проект

договор

статус согласования

Например, бухгалтер организации может видеть счета всех сотрудников компании, но не менять настройки участников.

Руководитель может приглашать сотрудников, но не видеть технические системные настройки.

Такая система естественно сочетает роли, объектные отношения и атрибуты.

Разрешения и интерфейс

Frontend должен отражать фактические permissions.

Если пользователю запрещено удалять документ, не нужно показывать активную кнопку удаления и только после клика сообщать об отказе.

Но интерфейс является вторичным слоем.

Сначала backend принимает решение.

После этого frontend использует доступные права, чтобы показать подходящий набор действий.

Так UX и безопасность работают согласованно.

Permission cache

В высоконагруженных приложениях разрешения иногда кешируются.

Это ускоряет проверки, но создаёт новую задачу.

Что происходит после отзыва роли?

Если кеш живёт ещё час, пользователь может сохранять старые полномочия.

Поэтому при проектировании нужно определить стратегию инвалидирования permission cache.

Особенно это важно для критичных административных и финансовых прав.

Разрешения в JWT

Иногда роли или scopes помещаются непосредственно в JWT.

Это уменьшает необходимость обращаться к базе при каждом запросе.

Но появляется ограничение.

Если право пользователя отозвано, уже выданный token может продолжать содержать старое разрешение до истечения срока.

Поэтому модель должна учитывать срок жизни токена и механизм досрочного отзыва там, где он требуется.

Не следует считать содержимое JWT автоматически актуальным бесконечно.

Проверка permission должна быть централизована

Если каждый controller реализует собственную логику:

if role...
if owner...
if department...

разные части приложения быстро начинают вести себя по разному.

OWASP рекомендует использовать единый, повторно применяемый механизм access control и выполнять enforcement рядом с защищаемым ресурсом.

Централизация также упрощает тестирование.

Меняется одна политика, а не десятки почти одинаковых условий.

Но политика должна знать бизнес контекст

Полностью универсальный security middleware не всегда способен принять правильное решение.

Например, правило:

manager может update order

может быть недостаточным.

Дополнительно нужно проверить:

организацию

статус заказа

владельца

тип операции

лимит суммы

Поэтому хорошо спроектированный контроль доступа разделяет общую инфраструктуру и бизнес политику.

Механизм проверки централизован.

Конкретные правила отражают реальную предметную область.

Что не является контролем доступа

Не защищают ресурс сами по себе:

скрытая ссылка

неочевидный URL

UUID

disabled кнопка

CSS класс

JavaScript условие

отсутствие пункта меню

секретное название страницы

Если пользователь может сформировать запрос напрямую, сервер должен самостоятельно проверить разрешение.

Сложный идентификатор способен уменьшить вероятность случайного угадывания, но не заменяет авторизацию.

OWASP отдельно рекомендует не полагаться на непредсказуемость идентификаторов вместо проверки прав.

Ошибка: проверять доступ только к странице

Представим административную страницу, которая закрыта корректно.

Но внутри неё JavaScript вызывает:

/api/users/delete

Если API endpoint не выполняет собственную проверку, защита страницы бесполезна.

Каждый защищённый backend маршрут должен применять модель разрешений независимо от того, какой интерфейс обычно его вызывает.

OWASP Top 10:2025 отдельно упоминает API с отсутствующим access control для изменяющих операций как пример Broken Access Control.

Ошибка: доверять роли из запроса

Frontend не должен сообщать серверу:

{
  "role": "administrator"
}

и ожидать, что сервер использует это значение для принятия решения.

Роль текущего пользователя должна определяться из доверенного серверного контекста.

То же относится к organization ID, ownership и другим данным, влияющим на доступ.

Пользователь контролирует собственный запрос и может изменить любое передаваемое клиентом поле.

Ошибка: создавать одно разрешение «manage»

Разрешение:

orders.manage

быстро становится слишком широким.

Оно может одновременно означать:

просмотр

редактирование

удаление

возврат оплаты

экспорт

смену владельца

Если разные сотрудники должны выполнять разные действия, permission уже невозможно безопасно назначить.

Лучше разделять чувствительные операции настолько, насколько этого требует реальная бизнес модель.

Ошибка: слишком детальная модель

Обратная крайность тоже создаёт проблему.

Если для одного экрана существует сотня разрешений, которые практически всегда назначаются вместе, система становится сложной для управления и тестирования.

Гранулярность должна соответствовать бизнес различиям.

Отдельное permission имеет смысл тогда, когда существует реальный сценарий предоставить одно действие без другого.

Ошибка: забытые разрешения

Старые роли и API ключи часто переживают функциональность, ради которой создавались.

Например, бывший подрядчик сохраняет административный аккаунт.

Интеграция больше не используется, но её token активен.

Старая роль имеет capability, которую новый код интерпретирует шире.

Поэтому permission audit должен включать не только текущую матрицу, но и неиспользуемые субъекты доступа.

Периодическая ревизия прав

Для критичных систем полезно регулярно отвечать на несколько вопросов.

Кто сейчас имеет административные права.

Какие пользователи могут управлять другими аккаунтами.

Какие интеграции имеют write доступ.

Есть ли временные права, которые уже должны были закончиться.

Какие роли больше никому не назначены.

Какие capabilities не используются приложением.

Ревизия особенно важна после кадровых изменений и крупных релизов.

Что должно быть задокументировано

Для поддерживаемой системы недостаточно держать permissions только в исходном коде.

Полезно иметь понятное описание:

какие субъекты существуют

какие ресурсы защищаются

какие действия возможны

какие роли используются

какие разрешения входят в роли

какие объектные правила действуют

какие исключения существуют

кто может менять саму модель

Так новый разработчик или администратор сможет проверить изменение до production.