Скрытая уязвимость в Libarea — как подмена ID раскрывает закрытые данные

🔍 В чём суть проблемы?
Всё начинается с простой вещи: на сайте есть объекты — статьи, посты, вопросы — и у каждого из них есть свой data-id. В нормальной ситуации, если объект скрыт от пользователя (например, пост удалён или доступен только автору), то при попытке доступа к нему пользователь должен получить отказ — 403 или 404.

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

Пользователь открывает DevTools.

Находит кнопку действия (например, «Поставить лайк» или «Добавить в закладки»).

Подменяет data-id на другой.

Сервер выполняет действие — даже если у пользователя нет прав.

🧪 Примеры, с которыми можно столкнуться
Подмена data-id и лайк скрытой статьи → запись в базу, как будто пользователь взаимодействовал с ней.

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

Открытие или изменение несуществующего или приватного объекта — без авторизации или прав доступа.

Если вы позволяете взаимодействовать с объектами по data-id без проверки прав на сервере, вы открываете прямой путь к утечке данных и обходу ограничений. Отображение заголовков закрытых статей во вкладке «Закладки» — уже сигнал, что доступ контролируется только на клиенте, а не там, где это действительно важно.

🔒 Совет: всегда проверяйте авторизацию и права доступа к объектам на серверной стороне. Никогда не полагайтесь на интерфейс или скрытые элементы в DOM — это не защита.