Ключевой кейс · Безопасность ИИ-продуктов
Redis P0 до первых пользователей
Аудит перед запуском обнаружил в Redis уязвимость уровня P0: хранилище могло раскрыть токены доступа к диалогам.
Что можно раскрыть
Это мой собственный продукт. Кейс относится только к инженерной безопасности и ничего не утверждает о клиническом эффекте, сертификации или работе для клиента.
Коротко о результате
Ещё до первых пользователей аудит помог найти и устранить P0 в Redis: доступ на чтение к хранилищу мог дать доступ к активным диалогам.
Что происходило и что было на кону
Продукт работал с чувствительными диалогами в терапевтическом формате. Ошибка в серверной части напрямую угрожала конфиденциальности пользователей.
Исходные условия и ограничения
Защита строк в базе, Row Level Security, работала правильно, и при беглой проверке проблема оставалась незаметной. Уязвимость появилась из-за удобного на вид решения: bearer-токены Supabase хранились рядом с состоянием долгой сессии, чтобы облегчить повторное подключение.
Моя роль
Как основатель и архитектор ИИ-продукта я провёл аудит до запуска и воспроизвёл атаку. Затем подготовил исправление и добавил в CI детерминированную проверку, чтобы ошибка не вернулась.
От проблемы к результату
- Ситуация
Во время планового аудита перед запуском содержимое Redis проверили напрямую, не полагаясь только на интеграционные тесты.
- Ограничение
Нужно было сохранить долгие сессии при переподключении, не оставляя токены доступа в постоянном хранилище.
- Решение
Воспроизвести атаку и убрать bearer-токены из Redis. Хранить их только в памяти запроса или WebSocket, а содержимое Redis проверять в CI.
- Что изменилось
P0 удалось воспроизвести и закрыть. Теперь сборка падает, если в Redis снова появляется строка, похожая на токен авторизации.
До первых пользователей воспроизвели и устранили уязвимость с раскрытием bearer-токенов Supabase, хранившихся в Redis в открытом виде. Добавили детерминированное сканирование.
Этот результат относится к безопасности собственного продукта. Он не подтверждает клиническую эффективность, сертификацию, регуляторное одобрение или результаты клиентского проекта.
- Контекст
- Аудит безопасности NearbyTo.me; под угрозой были чувствительные пользовательские диалоги.
- Период
- Проверка перед запуском; запись в реестре источников от 2 сентября 2026 года.
- Исходная ситуация и показатели
- Доступ на чтение к Redis мог дать действующие bearer-токены активных чатов.
- Роль
- Как основатель и архитектор ИИ-продукта я провёл аудит до запуска и воспроизвёл атаку. Затем подготовил исправление и добавил в CI детерминированную проверку, чтобы ошибка не вернулась.
- Источник
- Источники и подтверждения
- Откуда данные
- Авторский пост, развёрнутая статья о продукте и основной профиль.
- Надёжность данных
- A: автор лично воспроизвёл уязвимость и описал исправление.
- Ограничения публикации
- Название собственного продукта раскрыто; это не клиентский проект.
Что изменилось
До первых пользователей мы воспроизвели уязвимость: Redis раскрывал bearer-токены Supabase, хранившиеся в открытом виде. Токены убрали, а детерминированная проверка в CI теперь останавливает сборку, если такие данные возвращаются в Redis.
Что подтверждает этот результат
Этот результат относится к безопасности собственного продукта. Он не подтверждает клиническую эффективность, сертификацию, регуляторное одобрение или результаты клиентского проекта.
Что осталось у команды
Теперь проще понять, где находятся данные сессии: Redis хранит идентификаторы, временные метки и счётчики. Действующие токены авторизации остаются только в памяти.
Связанная проблема и следующий кейс
В связанном кейсе разбирается другая задача безопасности: как антифрод перешёл к анализу организованной фабрики аккаунтов.