Если персональная ссылка открывает чужой кабинет, доступ нужно немедленно ограничить. Такая ссылка фактически работает как credential, поэтому ошибка может затронуть не одну страницу, а весь набор ранее отправленных писем.
Отключите проблемный тип ссылок, отзовите активные токены и проверьте, связывает ли сервер токен с конкретным пользователем, назначением и сроком действия.
Что сделать в первую очередь
- Зафиксируйте пример без пересылки ссылки посторонним.
- Приостановите генерацию и обработку данного типа токенов.
- Определите период и версии, в которых создавались ошибочные ссылки.
- Отзовите токены и завершите связанные сессии при необходимости.
Почему возникает проблема
Утечка возникает, когда ссылка содержит предсказуемый ID или backend доверяет параметру пользователя отдельно от токена.
- В URL передаётся последовательный user_id.
- Один токен переиспользуется для нескольких получателей.
- Кэш страницы не учитывает авторизацию.
- После проверки токена backend загружает кабинет по другому параметру URL.
- Ссылка не имеет срока действия и цели.
Пошаговая диагностика
- Проверьте формат и энтропию токена.
- Проследите запрос от токена до выбранного user_id.
- Проверьте Cache-Control и CDN для персональных страниц.
- Сравните две ссылки разных тестовых пользователей.
- Проверьте повторное открытие после использования и истечения срока.
Как исправить
Токен должен быть случайным, ограниченным по назначению и однозначно определять владельца на сервере.
- Генерируйте криптографически случайный одноразовый токен.
- Храните только хеш токена и его owner_id.
- Не принимайте user_id из URL после успешной проверки.
- Добавьте expires_at, purpose и used_at.
- Запретите публичное кэширование ответа и очищайте параметры из аналитики.
Как проверить результат
- Ссылка одного пользователя никогда не открывает данные другого.
- Изменение параметров URL не меняет владельца.
- Отозванный и просроченный токены не работают.
- Персональная страница не возвращается из общего CDN-кэша.
Как не допустить повторения
- Добавьте негативные тесты IDOR.
- Не записывайте токены целиком в логи.
- Проводите ревизию всех magic link и reset link.
- Ограничьте доступный объём данных после входа по ссылке.
Чего не стоит делать
- Не маскируйте последовательный ID простым Base64.
- Не оставляйте старые ссылки активными после исправления.
- Не пересылайте реальные проблемные URL через незащищённые каналы.
Что подготовить для диагностики
- Тип ссылки и время генерации.
- Обезличенный маршрут обработки.
- Схема таблицы токенов.
- Настройки CDN и кэширования.
Частые вопросы
Достаточно ли длинного UUID?
Случайность важна, но нужны также срок, назначение, отзыв и серверная привязка к владельцу.
Нужно ли сообщать пользователям?
Это зависит от состава раскрытых данных и масштаба инцидента; решение принимают после технической и организационной оценки.
Когда стоит обратиться за помощью
Если ссылки уже рассылались, потребуется отозвать их, проверить журналы доступа и закрыть все варианты обхода владельца.
Итог
Персональная ссылка должна давать строго ограниченный и проверяемый доступ. Я могу провести аудит обработчика, заменить схему токенов и помочь безопасно отозвать старые ссылки.