Флагманский кейс · AI Product Risk & Safety
Redis P0 до первых пользователей
До первых пользователей аудит безопасности нашёл в Redis критическую утечку токенов уровня P0.
Раскрытие
Это мой собственный продукт. Кейс относится только к инженерной безопасности и ничего не утверждает о клиническом эффекте, сертификации или работе для клиента.
Итог в одном предложении
До первых пользователей аудит безопасности нашёл и устранил P0 в Redis: доступ на чтение мог открыть действующие пользовательские диалоги.
Контекст и ставки
Продукт работал с чувствительными диалогами в терапевтическом формате. Ошибка в серверной части напрямую угрожала конфиденциальности пользователей.
База и ограничения
Row Level Security работал правильно, поэтому беглая проверка не показывала проблему. Уязвимость появилась из-за удобного на вид решения: хранить bearer-токены Supabase рядом с долгоживущим состоянием сессии для повторного подключения.
Точная роль
Как основатель и AI Product Architect я провёл аудит до запуска, воспроизвёл атаку, спроектировал исправление и добавил в CI детерминированную проверку от повторения ошибки.
От сигнала к измеримому изменению
- Сигнал
Во время планового аудита перед запуском содержимое Redis проверили напрямую, не полагаясь только на интеграционные тесты.
- Ограничение
Долгие сессии должны были переживать переподключение, но учётные данные нельзя было делать долгоживущими вместе с ними.
- Решение
Воспроизвести атаку, убрать открытые bearer-токены из Redis, держать авторизацию только в памяти запроса или WebSocket и добавить сканирование Redis в CI.
- Измеримое изменение
P0 удалось воспроизвести и закрыть. Теперь сборка падает, если в Redis снова появляется строка, похожая на токен авторизации.
Before first users, a Redis exposure of plaintext Supabase bearer tokens was reproduced and remediated with a deterministic scan.
Это доказательство безопасности собственного продукта. Оно не подтверждает клиническую эффективность, сертификацию, регуляторное одобрение или результаты клиентского проекта.
- Контекст
- Аудит безопасности NearbyTo.me; под угрозой были чувствительные пользовательские диалоги.
- Период
- Проверка перед запуском; запись в реестре доказательств от 2 сентября 2026 года.
- Точка отсчёта
- Доступ на чтение к Redis мог дать действующие bearer-токены активных чатов.
- Роль
- Как основатель и AI Product Architect я провёл аудит до запуска, воспроизвёл атаку, спроектировал исправление и добавил в CI детерминированную проверку от повторения ошибки.
- Источник
- Проверить запись об источниках
- Происхождение
- Авторский пост, развёрнутая статья о продукте и основной профиль.
- Уверенность
- A: автор лично воспроизвёл уязвимость и описал исправление.
- Раскрытие
- Названный собственный продукт; работа для клиента не подразумевается.
Измеримый или наблюдаемый результат
До первых пользователей мы воспроизвели утечку открытых bearer-токенов Supabase из Redis и закрыли её детерминированной проверкой. CI теперь падает, если такие данные возвращаются в Redis.
Атрибуция и ограничение
Это доказательство безопасности собственного продукта. Оно не подтверждает клиническую эффективность, сертификацию, регуляторное одобрение или результаты клиентского проекта.
Что осталось у команды
Граница сессии стала проще: Redis хранит идентификаторы, временные метки и счётчики, а действующие данные авторизации остаются только в памяти.
Связанная проблема, следующий кейс и CTA
Связанный кейс в том же домене разбирает другую границу решения: антифрод против организованной фабрики аккаунтов.