13.06.2025 13:48
qbitcats 5 862 Источник

Платформа Lovable, позиционируемая как low‑code решение для создания веб-приложений и сайтов, где основное взаимодействие с системой происходит через чат с искусственным интеллектом, столкнулась с критической уязвимостью, связанной с RLS-политиками. Она позволила получать и изменять данные без аутентификации — сотни проектов оказались под угрозой.

Хронология обнаружения

20 марта 2025 года исследователь безопасности Мэтт Палмер обнаружил критическую брешь на сайте Linkable, созданном на Lovable. С помощью простых запросов он получил полный доступ к таблице users через публичный REST API Supabase.

Официальный идентификатор уязвимости CVE-2025-48757 был опубликован 29 мая 2025 года с критическим рейтингом CVSS 3.1 — 9.3 балла.

Суть уязвимости

Lovable по умолчанию включала Row-Level Security (RLS) политики в базе данных Postgres, однако на практике политики часто выглядели так:

USING (true)

Эта запись не ограничивает доступ к данным никак, открывая их для всех пользователей, включая неавторизованных. В результате:

  • Любой мог читать данные из открытых таблиц с помощью запроса типа ?select=*.

  • Злоумышленник мог изменять данные, например, переводя платежи в статус «paid» с помощью простого POST-запроса с использованием стандартного ключа анонимного доступа (anon-key).

Масштабы проблемы

Палмер просканировал 1645 проектов на платформе Lovable, обнаружив:

  • 303 уязвимых REST-эндпоинта.

  • 170 сайтов (около 10% от общего числа) предоставляли доступ к конфиденциальным данным.

Доступ открывался к личной информации пользователей, платежным данным, API-ключам и другим критически важным сведениям.

Реакция Lovable

После публикации информации о проблеме Lovable выпустила версию 2.0 платформы 24 апреля 2025 года, включив инструмент Security Scan, который должен проверять безопасность проектов перед публикацией.

Однако этот сканер лишь подтверждал факт включения RLS-политики, но не проверял её содержимое и корректность. Политика вида USING (true) считалась «защищённой», хотя фактически оставалась небезопасной.

Сообщество и официальный ответ

Разработчик Danial Asaria публично высказался в Twitter, подчеркнув, что пользователи платформы «не осознавали необходимости ручной настройки RLS» и назвал эту проблему архитектурной ошибкой самой платформы.

Сам Мэтт Палмер подтвердил серьёзность проблемы и подчеркнул ответственность самой платформы Lovable за её возникновение и распространение.

Почему это важно

Эта ситуация демонстрирует уязвимость подхода low-code платформ, которые ориентированы на простоту и скорость разработки, зачастую жертвуя встроенными механизмами безопасности. Отсутствие строгих проверок и перекладывание ответственности на разработчиков проектов без достаточного опыта создаёт риски масштабных утечек данных.

Рекомендации для защиты данных

Если вы используете платформу Lovable, немедленно примите меры:

  1. Проверьте RLS-политики во всех таблицах базы данных Supabase.

  2. Обязательно используйте строгие условия в RLS, например:

USING (auth.uid() = user_id)

  1. Не смешивайте чувствительные и публичные данные в одной таблице.

  2. Не доверяйте только Security Scan от Lovable, проверяйте политику вручную.

Итоги и выводы

Случай с CVE-2025-48757 — важный сигнал всей индустрии low-code решений. Без встроенной, автоматической безопасности такие платформы создают риски для конфиденциальности и целостности пользовательских данных.

Разработчикам платформ и проектам на их основе важно понять, что ответственность за безопасность не должна полностью ложиться на плечи конечных пользователей без чётких инструкций и эффективных инструментов контроля.

Защита данных должна стать частью базовых настроек всех платформ, а не дополнительной опцией.

Источники:

Комментарии (5)


  1. php7
    13.06.2025 14:02
    #28433686

    Эта запись не ограничивает доступ к данным никак, открывая их для всех пользователей, включая неавторизованных.

    Я хз, что такое USING (true)

    Но мне кажется, что это не задача БД проверять права доступа к данным.

    Или типа там запрос вида

    UPDATE
    payments P
    SET
    P.status = 'Paid'
    WHERE
    P.id = %id с запроса%

    ?


    1. pintor
      13.06.2025 14:02
      #28433866

      Я хз, что такое USING (true)

      Это механизм, чтобы на уровне таблицы настроить политику доступа к строкам, что-бы `where p.id == %id` не писать, и потом не проверять по всему проекту кто забыл это where добавить.

      Можно записать `USING (id = current_user_id)` и этот current_use_id вы устанавливаете для сессии работы с БД (как вариант). И далее вам не нужны никакие where, строки будут автоматически отфильтрованы.

      Нужно это или нет, это вы уж сами решайте. Это просто фича Postgres.

      Postgres RLS


      1. AlexSpaizNet
        13.06.2025 14:02
        #28436138

        Я так понимаю это не подходит к бэкенду который мультитенант и где тупо открыто 10 коннекшенов например в пуле с креденшиалс никак не связанных с юзером который дергает напирмер апишку? Сессия к базе открыта же и просто шарится между всеми через пул, и юзер который это делает не имеет юзера в базе, так что current user не имеет связи с ним.

        Или я ошибаюсь?


        1. pintor
          13.06.2025 14:02
          #28436580

          В моем проекте как раз для мультитенант и используется. Про сессию это я просто для примера написал.

          Как там сесии создаются и шарятся или нет - это на ваши заботы (ну или фреймворка которым вы пользуетесь). У меня в проете делается не особо оптимально, для каждого запроса в БД устанавливается значение параметра и в конце запроса сбрасывается.

          А в целом, RLS - устанавливается для таблицы, потом если у вас переменная которую вы проверяете не установлена, запрос просто упадет.

          И вы можете в любом месте SQL запроса установить переменную, а потом сбросить.

          Например:

          set current_user 1;
select * from users;
reset current_user; -- не помню reset или unset


  1. Wesha
    13.06.2025 14:02
    #28433948

    Они просто в промпте «Напиши мне код для <......>» забыли дописать «...и чтобы без дырок в безопасности!»