Разбор · Опубликовали 08.10.2026
Аутентификация узнаёт пользователя, авторизация даёт права: агенты проверяют оба решения
Работающий вход ещё не защищает чужие заявки. В заказе нужны правила доступа и проверки отказов.
Разбор собственной машины агентов vibecoding.ru · текст подготовлен с ИИ · факты проверены по первоисточникам 8 октября 2026
Аутентификация проверяет, под какой учётной записью вошёл пользователь. Авторизация решает, что ему разрешено. Успешный вход не даёт права читать чужие данные.
Клиент видит свои заявки, менеджер меняет статус, руководитель назначает исполнителя. Агентам поручают вход и проверку каждого действия.
Не хотите разбираться сами? Внедряем ИИ в ваш бизнес: задачи без лимита, одна цена в месяц, отмена в любой момент.
1. Вход подтверждает учётную запись, права разрешают конкретное действие.
В интерфейсах «авторизация» часто означает вход. В заказе разделите подтверждение учётной записи и право на действие с определённой записью.
Логин называет учётную запись. Пароль, код или ссылка подтверждают вход в неё. Это не обязательно установление паспортной личности человека.
Клиент вошёл правильно. Но может ли он скачать этот счёт? Если счёт другой компании, сервер должен отказать. Это проверка прав.
В задании «сделать вход» права потеряны. Запишите отдельно способы входа и разрешённые действия: иначе приёмка закончится на открывшейся странице.
Назвать учётную запись, подтвердить её и разрешить действие нужно отдельно.
Различие аутентификации и авторизации: OWASP Authentication и Authorization Cheat Sheets; Kaspersky. Проверено 8 октября 2026. Примеры с заявками и счетами условные.
2. Защищённая страница не гарантирует защищённые данные.
Этот разрыв мы встречали в собственной машине разработки сайта. Инженер ведёт машину агентов: записывает правила, принимает изменения и разбирает ошибки.
Наш курс по агентной разработке предлагает вход по почте, со ссылкой в письме. По журналу машины, сервер проверяет право на содержимое урока отдельно от входа.
Это свои находки, не клиентский кейс. В разборе ответственности за ошибки они уже описаны; здесь проверим право на данные.
Ревью находило доступ там, где проверка выглядела законченной.
07.07
Независимое ревью обнаружило прямое чтение данных админки в обход пароля на её странице. Записали задачу перенести защиту к запросам данных. Вывод для приёмки: проверять серверный отказ, а не только вход на экран.
09.09
Ревью цепочки оплаты курса нашло риск: подпись сообщения подтверждала источник, но не покупку нужного товара. Добавили проверку товара. Правило: подтверждённое сообщение ещё не основание выдать конкретный доступ.
Разборы собственной машины vibecoding.ru от 7 июля и 9 сентября 2026; повторно сверены 8 октября. Июльская запись фиксировала находку и задачу на исправление, не завершённый аудит. Сентябрьская описывала внесённую проверку товара.
3. Роль клиента не разрешает читать заявки всех клиентов.
Роль «клиент» не отвечает, чья перед ним заявка. Проверке нужны владелец записи и компания: одинаковая роль бывает у конкурентов.
Менеджер видит свои заявки или весь отдел? Границу определяет заказчик. Инженер превращает её в правило; агент не должен решать это сам.
Матрица связывает пользователя, запись и действие. Укажите разрешение или отказ. Без заданного разрешения доступ к защищённым данным закрыт.
Кнопку можно скрыть, а запрос отправить напрямую. Случайный номер заявки не заменяет проверку прав: известная чужая ссылка должна давать отказ.
В матрице нужны и разрешения, и границы этих разрешений.
Условная матрица для согласования с заказчиком, не внедрённая клиентская система. Принципы: OWASP Authorization и IDOR Prevention Cheat Sheets, проверены 8 октября 2026. Для вашего процесса границы могут отличаться.
4. Агенты реализуют согласованные права, инженер проверяет ограничения.
Агенту можно поручить сценарии входа, серверные проверки и тесты. Но фраза «сделай безопасно» не заменяет постановку задач агенту с ожидаемым результатом.
Задайте успех и отказ: клиент добавляет файл к своей заявке; запрос к чужой ничего не меняет. Оба исхода входят в определение «готово».
Сервер проверяет права до выдачи данных и изменения записи. Заявка, файл и выгрузка могут идти разными путями: один защищённый экран их не закрывает.
В правилах для агентов закрепите тестовые записи и работу в ветке. Разрешение написать код не означает разрешение менять боевые роли.
На каждом шаге агент показывает результат, который можно проверить.
Предлагаемый порядок работы. Проверка разрешений при каждом запросе: OWASP Authorization Cheat Sheet; проверки разных ролей: OWASP WSTG 4.2, WSTG-ATHZ-02. Проверено 8 октября 2026. Это план приёмки, не отчёт о выполненном заказе.
5. Приёмка должна доказать отказ на чужую заявку и снятую роль.
Правильный вход на демонстрации не выявит лишних прав клиента. Попросите второй прогон: пользователь пытается сделать запрещённое.
Создайте тестовые записи клиентов разных компаний и сотрудников разных ролей. Инженер проверяет действия в интерфейсе и запросами к серверу.
Надписи «нет доступа» мало: проверьте, что чужие данные не выданы и база не изменилась. Скрыть выполненное действие поздно.
Снимите роль в уже открытой сессии. Если права сохраняются до нового входа, согласуйте этот срок заранее. После увольнения это станет проблемой.
У каждой проверки есть разрешённый исход и отказ без побочного действия.
Сценарии приёмки по OWASP WSTG 4.2, WSTG-ATHZ-02, IDOR Prevention и Session Management Cheat Sheets. Проверено 8 октября 2026. Таблица задаёт ожидаемые результаты; эти тесты не выполнялись для клиентского проекта.
6. Заказ доступа начинается с матрицы и заканчивается повторяемой проверкой.
Примите матрицу, вход, серверные ограничения и повторяемые проверки. Если сдали только форму входа, изоляцию клиентов по ней не доказать.
Инженер принимает и разрешённые, и запрещённые сценарии. Зафиксируйте, кто отвечает за выпуск и исправление: ответственность не переходит к модели.
Клиентского кейса по этой теме у нас нет. Здесь опыт машины vibecoding.ru и руководства OWASP. Скорость написания кода не доказывает защищённость.
Что и как мы проверяли
| Факт | Что известно | Проверено |
|---|---|---|
| Вход и права | Открыты руководства OWASP по аутентификации, авторизации, доступу к записям и сессиям. Отдельно изучен WSTG 4.2. Сценарии в таблицах составлены для статьи, не взяты из клиентского проекта. | 2026-10-08 |
| Наш вход | Публичная страница входа в курс описывает письмо со ссылкой. Журнал собственной машины описывает отдельную проверку доступа к уроку. Письмо не отправляли; чужие учётные записи не проверяли. | 2026-10-08 |
| Наши ошибки | Разборы 7 июля и 9 сентября 2026 сверены с журналами. Не объявляем июльскую запись датой закрытия всех проблем и не выдаём /open за отчёт аудита. | 2026-10-08 |
| Цена проекта | Живой /services: «Один проект», 250 000 ₽ в месяц, один продукт и один поток работы. Отдельной цены реализации входа на странице нет. | 2026-10-08 |
| Граница опыта | Опыт относится к vibecoding.ru и учебным материалам. Клиентского кейса по аутентификации и авторизации нет. Эта статья не является проверкой безопасности читательской системы. | 2026-10-08 |
В курсе разбираем правила, задачи и проверки. Урок «Дверь в Telegram» включает права доступа. Это учебный материал, не аудит вашей системы.
Разработка по подписке стоит 250 000 ₽ в месяц в тарифе «Один проект», на 8 октября 2026. Это цена проекта и потока работы, не смета любой системы входа.
Агенты дописывают согласованные сценарии входа и серверные ограничения. Инженер проверяет разрешённые и запрещённые действия. Объём согласуют заранее.
Соберите роли и действия, которые нельзя разрешить по ошибке. Чтобы обсудить следующий шаг, откройте страницу для руководителя с этой матрицей.
7. Частые вопросы
Общий адрес почты отдела подходит для доступа сотрудников?+
Общий ящик не различает сотрудников. Для действий, где нужно знать исполнителя, задайте персональные учётные записи. Если общий доступ необходим, отдельно согласуйте его права и способ фиксировать ответственного.
Нужны ли права, если все сотрудники входят через корпоративный аккаунт?+
Да. Общий вход может подтвердить сотрудника, но приложению всё равно нужно определить, какие записи и действия ему разрешены. Подтверждение корпоративной учётной записи само по себе не делает сотрудника администратором приложения.
Поможет ли двухфакторный вход от чтения чужих заявок?+
Он добавляет проверку при входе. Если сервер выдаёт любому вошедшему клиенту любую заявку, дополнительный фактор это правило не исправит. Нужно отдельно ограничить доступ к записям.
Можно ли разрешить поддержке работать от имени клиента?+
Это отдельное разрешение, которое не следует автоматически из роли сотрудника. Задайте цель, допустимые действия и срок. В журнале должно быть понятно, кто из поддержки действовал и с чьими данными. Такой сценарий требует собственной приёмки.
Агент может сам проверить написанные им ограничения?+
Ему можно поручить первый прогон тестов. Приёмку проводит инженер по согласованной матрице, включая прямые запросы и запрещённые действия. Тесты, которые повторяют ошибочные предположения автора, могут быть зелёными при лишних правах.
Источники
- OWASP: Authentication Cheat Sheet — Проверка учётной записи; первоисточник, проверен 08.10.2026
- OWASP: Authorization Cheat Sheet — Правила доступа, отказ по умолчанию, серверная проверка; проверен 08.10.2026
- OWASP: IDOR Prevention Cheat Sheet — Проверка доступа к конкретным записям; проверен 08.10.2026
- OWASP WSTG 4.2: Testing for Bypassing Authorization Schema — WSTG-ATHZ-02: разные пользователи и роли, гость, выход; проверен 08.10.2026
- OWASP: Session Management Cheat Sheet — Изменение прав, срок сессии и выход; проверен 08.10.2026
- Kaspersky: аутентификация и авторизация — Объяснение различия терминов; проверено 08.10.2026
- vibecoding.ru: ответственность за ошибки ИИ — Опубликованный контекст собственного ревью; проверено 08.10.2026
- vibecoding.ru: публичный вход в курс — Описание входа по почте; страница открыта 08.10.2026, вход не выполняли
- vibecoding.ru: машина разработки — Публичное устройство машины, не отчёт аудита; проверено 08.10.2026
- vibecoding.ru: разработка по подписке — «Один проект», 250 000 ₽ в месяц; проверено 08.10.2026
- vibecoding.ru: программа курса — Учебный контекст правил, задач и проверок; проверено 08.10.2026
Запомнить
1. Разделите в заказе подтверждение учётной записи и разрешение действия. Работающий вход не даёт права на чужие данные.
2. Утвердите матрицу: кто, с какой записью, что может сделать. Роль клиента не отменяет границу между компаниями.
3. Попросите серверные проверки и прогон отказов: чужая заявка, файл, выгрузка, изменение роли, завершённая сессия.
4. Поручите агентам реализацию и тесты. Принимайте работу с инженером по разрешённым и запрещённым действиям; новые ошибки добавляйте в повторяемую проверку.