Чи безпечний Lovable? Що показали 18 554 застосунки Lovable

Ви побудували щось на Lovable, воно працює, і ви вже майже пускаєте туди справжніх людей. Десь того тижня ви набрали «чи безпечний lovable» у пошуку, і повернулася або сторінка про оприлюднення вразливості 2025 року, або постачальник, що продає вам сканування. Жодна з двох не сказала нічого про застосунок, який ви от-от опублікуєте.

Ось у чому помиляється більшість тих відповідей: «чи безпечний Lovable» це три питання, вдягнені в одне речення, і те з них, яке вирішує, чи зможуть незнайомці прочитати дані ваших користувачів, майже ніхто не вимірює.

Ми можемо його виміряти. Між 12 і 14 серпня 2026 року ми прогнали 30 998 живих застосунків через ті самі дев’ять зовнішніх перевірок, які кожен може безкоштовно запустити на нашій головній сторінці, і 18 554 з них були опубліковані на Lovable. Це наша найбільша когорта, три з кожних п’яти застосунків, які ми взагалі сканували. Ось що повернулося для них і де закінчується наш огляд.

Чи безпечний Lovable?

Як платформа, так, і з більшим відривом, ніж ми очікували. Те, що видає сам Lovable, виявилося найчистішим з п’яти виміряних конструкторів. Усе, що вирішувало оцінку, було всередині застосунку, який побудував його власник.

Уявіть крамницю, склад якої через дорогу. Lovable будує крамницю: вітрини, прилавок, вивіску. Склад належить Supabase, і в нього власний замок на власних дверях. Що крамниця видає перехожому, це одне питання. Що склад видає кожному, хто підійде і попросить, це зовсім інше, і жодне прибирання в крамниці цього не змінює.

1. Платформа. Чи публікує Lovable ваш застосунок як належить: дійсний сертифікат, домен, що не спливає, нічого, що витікає зі збірки. Це крамниця.
2. Агент. Чи надійний код, який пише ШІ Lovable. Жодне зовнішнє сканування не бачить проводки, і ця стаття каже про це, замість вгадувати.
3. Застосунок, який ви опублікували. До чого незнайомець дістається з тротуару: ключ у коді, який завантажує браузер, бакет сховища, що перелічує свої файли, таблиця бази, що відповідає кожному, хто спитає.

Наші перевірки читають третє питання і дві частини першого. Щодо платформи: сертифікат був дійсний на всіх 18 486 застосунках, де ми змогли його прочитати, і жоден домен з 18 554 не наближався до закінчення. Щодо агента нам нічого вимірювати. Щодо застосунку ми маємо 18 554 відповіді.

Що ми знайшли в 18 554 застосунках Lovable

Дев’ять перевірок, ззовні, без входу і без доступу до чийогось акаунта. Ми жодного разу не читали рядок: там, де база відповідала, ми питали, скільки рядків вона віддала б, і на цьому спинялися. Жоден застосунок не названо ні тут, ні деінде в тому, що ми публікуємо. Кожна частка нижче рахується від застосунків, на яких перевірка відповіла, бо перевірка, що не змогла завершитися, це невідомо, а не пройдено, і саме це правило рухає знаменники. Метод і дані у звіті.

Оцінки: 15 963 A, 370 B, 1 814 C, 402 D і 5 F. Дев’ять застосунків не мали жодної знахідки.

Саме перший рядок пояснює, чому «99 % застосунків Lovable мають проблему з безпекою» це речення, яке ви десь прочитаєте і маєте проігнорувати. Заголовки безпеки браузера надсилає те, що віддає вашу сторінку, а на вашзастосунок.lovable.app це Lovable, тому кожен застосунок на тому хості отримує ту саму відповідь. Їх варто мати, і не з них робиться D.

Приберіть цей рядок, і 15 453 з 18 554 застосунків не мали більше нічого. Решта 3 092 це решта цієї статті.

Що Lovable робить добре, і це майже весь список

Три з наведених цифр найкращі, які ми записали в будь-якого конструктора, і всі три вирішує платформа, а не ви.

Source maps. 225 з 18 553 застосунків Lovable публікують оригінальні файли за застосунком разом із коментарями. Це приблизно 1 з 80. На Base44 та сама перевірка спрацьовує на 59 % застосунків, на Replit на 6 %. Продакшн-збірка Lovable типово робить правильну річ, тож це здебільшого не ваша проблема.

Cross-origin заголовки. Нуль застосунків з 18 518 сказали будь-якому сайту світу, що той може звертатися до їхнього API, і нуль дозволили це з куками входу відвідувача. Це та знахідка, яка найлегше дає іншому сайту діяти як ваш користувач, і на Lovable вона не з’явилася жодного разу.

Загублені приватні файли. Нуль застосунків з 18 442 віддавали .env чи .git/config за звичайним URL. У застосунку Lovable немає власного сервера, щоб його неправильно налаштувати, тож і забутого файла позаду немає.

Нічого з цього не втішний приз. Це та частина роботи, про яку вам не довелося думати і про яку в більшості інших конструкторів хтось думає.

Єдина цифра, що має значення: 2 017 з 3 553

Серед застосунків Lovable, чию базу Supabase ми справді змогли запитати, 57 % віддали рядки запиту, що не ніс жодного входу.

Знаменники варто пройти, бо саме цю цифру всі цитують і майже ніхто не окреслює. З 18 554 застосунків Lovable 6 532 називали проєкт Supabase у коді, який віддають. З них 3 553 відповіли достатньо добре, щоб ми могли судити, а решта 2 979 ні, тож вони невідомі, а не чисті. З тих 3 553 2 017 повернули рядки незнайомцю.

У 373 з тих застосунків таблиця, що відповіла, мала назву з людей: users, profiles, orders, messages. Це 373 застосунки, а не 373 таблиці. В інших 1 644 це було щось, чого ми не могли назвати ззовні: можливо, каталог товарів, який завжди мав бути публічним, можливо, будь-що інше.

Якщо міряти проти всіх просканованих застосунків Lovable, а не проти підмножини, про яку ми могли судити, 2 017 з 18 554 це приблизно 11 зі 100. Запам’ятайте цю цифру на два розділи.

Чому це лягає на базу даних, а не на Lovable

Через рішення в дизайні, яке правильне, свідоме і майже ніколи не пояснене людині, якої воно стосується.

У застосунку Lovable немає власного сервера. Сторінка в браузері відвідувача говорить із Supabase напряму, і саме тому все це можна побудувати за один вечір і саме тому так мало цих застосунків мають відкритий маршрут API: немає вашого API, щоб лишити його відкритим. Щоб це працювало, адреса вашої бази і ключ до неї мають бути надруковані всередині застосунку, де кожен їх прочитає. Цей ключ називається публікованим, і те, що він публічний, правильно. Він і має там бути.

А отже єдине, що стоїть між незнайомцем і вашою таблицею users, це налаштування Supabase на кожну таблицю, що зветься Row Level Security. Якщо воно ввімкнене і політику написано, публічний ключ читає лише ті рядки, які політика дозволяє. Якщо вимкнене, публічний ключ читає таблицю.

Тепер частина, яка вирішує більшість проєктів на Lovable. Supabase вмикає Row Level Security типово для таблиць, які ви створюєте кліками в Table Editor. Таблиці, створені виконанням SQL, його не отримують, а виконання SQL це спосіб, яким конструктор створює таблиці для вас. Тож звичайна форма проєкту на Lovable така: кілька таблиць, зроблених руками, які захищені, поруч із тими, що були згенеровані і можуть бути незахищені. Обидві виглядають однаково. Жодна не поскаржиться. Застосунок працює бездоганно в обох випадках, і в цьому вся проблема: нічого з того, що ви бачите спереду, не каже вам, який саме вид у вас.

Довша версія цього, разом із SQL, тут, а покрокова інструкція простою мовою для цієї платформи це чи безпечний ваш застосунок Lovable.

Політика, яка прибирає помилку і лишає таблицю відкритою

Увімкнути Row Level Security це крок один із двох, і саме на кроці два ШІ-помічник дуже охоче робить неправильну річ.

З увімкненим налаштуванням і без написаної політики ваш власний застосунок перестає працювати. Ви отримуєте помилку, вставляєте її в чат, і повертається щось, від чого помилка зникає. Дуже часто це політика, що дозволяє всім, написана як using (true). Це чинна політика. Вона задовольняє вимогу, що політика існує. Вона дозволяє кожен рядок кожному запиту.

Панель тепер повідомляє таблицю як захищену, помилка зникла, ваш застосунок працює, а таблиця читається рівно так само, як і раніше. Про це в нас ціла стаття, бо це найпереконливіший збій у всьому стеку: RLS увімкнено, а ваша таблиця досі публічна.

Якщо ви колись вставляли помилку Row Level Security у вікно чату і приймали перше виправлення, з яким збірка пройшла, прочитайте ту політику сьогодні.

CVE-2025-48757 і чому це вже не ваше питання

Вона справжня, вона була серйозна, і з боку Lovable закрита вже понад рік. Вона також не те, що вам слід перевіряти.

У травні 2025 року дослідник безпеки Метт Палмер опублікував CVE-2025-48757 про застосунки Lovable, у чиїх таблицях Supabase Row Level Security була відсутня або написана надто дозвільно. Він просканував 1 645 застосунків Lovable і знайшов 170 з відкритими базами. Відповіддю Lovable стала перевірка безпеки, що виконується перед публікацією і попереджає про незахищені таблиці.

Ось чесне прочитання, і саме тому CVE це хибна рамка. Те оприлюднення знайшло приблизно 10 відкритих застосунків на кожні 100. За шістнадцять місяців, на когорті вдесятеро з лишком більшій, ми знайшли приблизно 11 на 100. Знаменники не однакові, і жодна з двох вибірок не є цілим інтернетом, тож беріть їх як той самий порядок величини, а не як точне порівняння. Напрям достатньо ясний: частка не впала.

Це не виправлення, що провалилося. Це ознака того, що воно ніколи по-справжньому не було вразливістю продукту. Це налаштування на ваших власних таблицях, у вашому власному проєкті Supabase, яке ніхто інший не ввімкне за вас. Патч туди не дістає, і саме тому дістає перевірка, яку запускаєте ви самі.

З чого насправді складалися 822 ключі

Майже всі були в порядку, і сканер, який сказав би вам інакше, навчав би вас себе ігнорувати.

822 з 18 554 застосунків Lovable мали щось схоже на ключ у коді, який завантажує відвідувач. Прочитане як перелік форм, це 4 % застосунків, що «зливають секрети». Прочитане як те, що кожен ключ насправді вміє, воно виглядає так:

727 ключів Google це причина, чому ми класифікуємо, а не просто збігаємо форми. Ключ Google Maps у браузері там, де й має бути, а виправлення це обмежити його вашим власним доменом, а не панікувати.

Значення мають чотири нижні рядки, і вони рідкісні: 30 застосунків з 18 554. Це також ті знахідки, що самі по собі коштують грошей, і зазвичай вони виринають як рахунок, що приходить раніше, ніж хтось помітив. Дві деталі для протоколу. Усі три ключі service_role з усього сканування на 30 998 застосунків були в застосунках Lovable, і так само два з трьох живих секретів Stripe. Ключ service_role у браузері робить кожну політику Row Level Security у вашому проєкті неістотною одним рядком, і тому це єдина знахідка, яку ми оцінюємо як критичну з першого погляду, і та, яку варто ротувати того самого дня.

Відрізнити два види займає приблизно хвилину, і ми написали інструкцію.

768 бакетів сховища, які ніхто не хотів відкривати

Бакет Supabase, позначений публічним, віддає не лише ті файли, на які посилається ваш застосунок. Він також перелічує кожен файл усередині кожному, хто спитає.

768 з 16 565 застосунків Lovable, які ми могли перевірити, мали щонайменше один бакет, що перелічував свій вміст. Причина та сама, що й у читаних таблиць: зробити бакет публічним це спосіб, яким ви змушуєте зображення з’явитися, воно працює одразу, і потім ніщо не каже вам, що перелік ішов у комплекті. Завантажені рахунки, фото документів і аватари користувачів опиняються в одному місці. Що публічний бакет насправді відкриває пояснює виправлення, а це підписані URL, а не приватний бакет, з якого ви потім не зможете читати.

П’ятихвилинна перевірка вашого застосунку Lovable

Кожен пункт це сторінка, яку ви відкриваєте. Скористайтеся приватним вікном, щоб ваш власний вхід не відповідав замість незнайомця.

1. Supabase → Authentication → Policies. Пройдіть список. Будь-яка таблиця, де Row Level Security вимкнено, читається кожним, хто має адресу вашого проєкту, а вона надрукована у вашому застосунку.
2. Прочитайте політики таблиць, де його ввімкнено. Якщо одна з них дозволяє всім, таблиця відкрита, а панель усе одно зве її захищеною.
3. Supabase → Storage. Будь-який бакет, позначений публічним, перелічує свої файли кожному. Подивіться, що в ньому, перш ніж вирішити, що це нормально.
4. Supabase → Settings → API. Переконайтеся, що ключ, який віддає ваш застосунок, це публікований. Якщо секретний ключ колись вставляли в проєкт, ротуйте його там, перш ніж видаляти з коду, бо старе значення працює, доки ви цього не зробите.
5. Або доручіть це скануванню. Воно виконує ці чотири ззовні і ще п’ять, займає приблизно 20 секунд, не потребує акаунта і показує вам оцінку та те, що її спричинило: просканувати застосунок.

Якщо ви радше пройдете всю поверхню як список, 10-хвилинний чекліст безпеки охоплює те, що варто підтвердити на будь-якому щойно запущеному застосунку, а чи може будь-хто прочитати вашу базу Supabase це тест, який варто зробити, якщо ви зробите лише одну річ.

Ваш застосунок змінюється з кожною публікацією

Сканування, яке ви запустили минулого місяця, описує застосунок минулого місяця, а на Lovable цей місяць коротший за більшість.

Публікація це один клік, тож зміна виходить у світ тієї миті, коли ви її приймаєте. Між вами й інтернетом немає кроку розгортання, який спіймав би таблицю, додану сьогодні вранці з вимкненим Row Level Security, або ключ, вставлений у чат опівночі, щоб пройти збірку, яка падала. Кожна з 2 017 відкритих баз, які ми знайшли, належала комусь, чий застосунок працював бездоганно.

Reeve Monitor це версія цієї статті, яка запускається сама. Він повторює всі дев’ять перевірок щогодини на трьох застосунках, дивиться кожні 60 секунд, чи застосунок відповідає, повідомляє, коли результат змінюється, замість чекати, поки ви подивитеся, і надсилає місячний звіт. Він коштує $12 на місяць за прайсом, із сімома безкоштовними днями до першого списання; сторінка цін іноді нижча за цифру тут і ніколи не вища.

Якщо ваш застосунок Lovable використовує Supabase, а 6 532 з 18 554 просканованих використовують, друга половина проблеми це копія. Відкрита таблиця це те, що незнайомець може прочитати. Агент із доступом до бази або міграція, що пішла не в той бік, це те, що може її стерти, а власна щоденна резервна копія Supabase на безкоштовному тарифі не з тих, які ви відновите самі. Reeve Care щоночі знімає зашифровану копію вашої бази Supabase, тримає її там, куди ваш проєкт не дістає, перевіряє, що кожна копія справді відновлюється, і дає вам відновлення в один клік, коли воно потрібне. Усе, що робить Monitor, уже входить. Care коштує $49 на місяць за прайсом за один застосунок, із тими самими сімома безкоштовними днями.

Як виглядає цей другий збій, розказане тим, з ким це сталося, є в дні, коли ШІ-агент стер продакшн-базу. Жодна з дев’яти перевірок цієї статті там не допомогла б. Копія допомогла б.

Що зробити цього тижня

Lovable зробив свою половину добре. Ті 2 017 це половина, яка ваша, і вона налаштування, а не переписування. Якщо вам натомість потрібне порівняння між конструкторами, який конструктор застосунків на ШІ найбезпечніший має таблицю для всіх п’яти.