Более 16 000 баз данных Supabase раскрывают PII, пароли и токены аутентификации

Платформа Supabase, позиционирующая себя как открытая альтернатива Firebase, широко используется для быстрого развёртывания бэкенда, аутентификации и хранения данных. Однако, как показало новое исследование, тысячи приложений на её основе остаются с неправильно настроенными правами доступа, что приводит к публичному раскрытию чувствительной информации.

Подробности

Исследователи выявили более 16 000 баз данных Supabase, которые оказались неправильно сконфигурированы и доступны извне. В таких базах данных содержались читаемые таблицы с персональными данными (PII), паролями и токенами аутентификации. Проблема связана с некорректной настройкой политик доступа — в частности, с отсутствием или ошибками в механизме Row Level Security (RLS), который предназначен для разграничения прав на уровне строк. При должной настройке RLS Supabase ограничивает доступ к данным в зависимости от роли пользователя. Если же политики не заданы или заданы неверно, база данных может отвечать на запросы без аутентификации, отдавая любые данные. Именно такие случаи и стали предметом исследования: обнаруженные экземпляры позволяли читать таблицы с чувствительной информацией без каких-либо ограничений. Масштаб в 16 000+ баз данных указывает на системную проблему: многие разработчики либо не знают о необходимости настройки RLS, либо оставляют её «на потом», либо применяют шаблоны, в которых защита отключена по умолчанию. Поскольку Supabase часто используется для MVP, прототипов и небольших проектов, такие конфигурации нередко попадают в продакшен и остаются без внимания. Точный список затронутых организаций не раскрывается, однако сам факт наличия открытых таблиц с паролями и токенами аутентификации означает, что злоумышленники могли получить доступ к учётным данным и сессиям пользователей. Это создаёт риск дальнейших атак: от захвата аккаунтов до lateral movement внутри инфраструктуры.

Что делать

В первую очередь необходимо проверить все проекты на Supabase и убедиться, что для каждой таблицы включён и корректно настроен Row Level Security. Политики должны явно разрешать только необходимые операции для аутентифицированных пользователей и запрещать всё остальное по умолчанию. Далее следует провести аудит публичных ключей (anon key) и убедиться, что они не используются там, где требуется привилегированный доступ. Публичный ключ по своей природе предназначен для клиентской стороны, но его безопасность целиком зависит от правильно настроенных RLS-политик. Также рекомендуется: — проверить логи доступа к базам данных на предмет подозрительных запросов; — сменить пароли и отозвать токены аутентификации, если есть подозрение на утечку; — ограничить сетевой доступ к базам данных там, где это возможно; — внедрить регулярные проверки конфигураций в CI/CD; — использовать мониторинг и алерты на попытки несанкционированного чтения данных. Разработчикам, использующим Supabase в продакшене, стоит рассматривать проверку RLS как обязательный шаг перед каждым релизом. Автоматизация таких проверок снижает риск человеческой ошибки и помогает избежать подобных инцидентов в будущем. Итог: массовая утечка данных из-за неправильной настройки Supabase — это напоминание о том, что безопасность бэкенда начинается с корректной конфигурации прав доступа. Игнорирование RLS превращает удобную платформу в открытый источник утечек.

Источник: BleepingComputer