Сканування безпеки Lovable: чого воно не доведе

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

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

Чи перевіряє Lovable мій застосунок на проблеми з безпекою?

Так, і їх два. Обидва безкоштовні.

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

Усе, що нижче, прочитано у власній документації Lovable про безпеку24 вересня 2026 року. Ця функція змінювалася за рік не раз, тож дивіться на дату будь-якої статті, яка її описує, включно з цією.

Що перевіряє сканування безпеки Lovable

Три ділянки, як фіксований набір перевірок, за секунди, під час кожної публікації.

Документація Lovable називає їх оглядом бази даних, аудитом залежностей і перевіркою сервера MCP. Огляд бази даних це те, що важить для цієї статті, і його опис варто прочитати повільно: він охоплює таблиці без контролю доступу до окремого запису, тобто без Row Level Security, а також правила доступу, які пропускають усіх, і вимкнений захист від викрадених паролів. Аудит залежностей шукає відомі вразливості у ваших пакетах npm. Перевірка MCP шукає сервер MCP, який ваш застосунок віддає назовні без автентифікації.

Знахідки повертаються згрупованими за ділянками і позначеними як Critical, Warning або Info. Сканування спрацьовує автоматично з діалогу публікації, і ви також можете запустити його з розділу Security у проєкті.

Деякі тексти називають це Basic scan. Кнопка в розділі Security сьогодні каже Run quick scan, тож якщо стаття і ваш екран не сходяться в назві, актуальний ваш екран.

Що додає Deep scan

Він читає весь код вашого застосунку і не запускається сам.

Deep scan містить усе з Quick scan, а потім дивиться на вашу власну логіку, ваші дозволи й ваші дані. Lovable перелічує сім ділянок: контроль доступу й авторизація, неавтентифіковані та придатні до зловживання точки входу, небезпечне введення та ін’єкції, витік секретів і облікових даних, платежі й рахунки, автентифікація та безпека акаунтів, а також відкриті персональні й чутливі дані. Він теж безкоштовний.

Речення з документації, за яким справді треба діяти, таке: Deep scan не запускається автоматично, поки ви працюєте. Він запускається тоді, коли ви його запускаєте. У проєкті, де його ніколи не запускали, код ніколи не читали, хоч би скільки разів проєкт публікували, і діалог публікації вам про це не скаже. Робочі простори Enterprise можуть планувати Deep scan для вибраних проєктів у Workspace Security center, і це єдина конфігурація, де воно стається без того, щоб хтось згадав.

Lovable також може спробувати виправити знайдене, поки ви будуєте або через Try to fix all у розділі Security. Прочитайте, що змінило виправлення, перш ніж його прийняти. Полагодження, від якого зникає помилка row level security, це дуже часто політика, яка пропускає всіх, і така політика задовольняє перевірку й лишає таблицю відкритою.

Претензія 2025 року і що змінилося

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

У травні 2025 року Метт Палмер оприлюднив CVE-2025-48757 про застосунки Lovable, у яких таблиці Supabase не мали row level security або мали його написаним надто широко. Відповіддю Lovable стала перевірка перед публікацією. Власний текст Палмера описав її межу в одній дужці:

Функція Publish у Lovable допомагає переконатися, що політики RLS увімкнені на всіх таблицях, і повідомляє, коли це не так (але не обов’язково показує, чи вони достатні).

На цю прогалину чинна документація дає відповідь: вона прямо називає правила доступу, які пропускають усіх, серед того, що позначає огляд бази даних. Ніщо в цій статті не перевіряє це твердження. Якщо хочете перевірити, створіть одноразову таблицю з політикою, яка пропускає всіх, і подивіться, чи сканування її назве. Довга версія CVE є в чи безпечний Lovable.

Чого не доведе сканування зсередини

Чи віддає ваш живий застосунок рядки тому, хто не увійшов у акаунт.

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

• Політика пропускає всіх. Записана як using (true), вона є чинною політикою, вона задовольняє вимогу, щоб політика існувала, і повертає кожен рядок кожному, хто звернувся.
• Політика покриває читання і більше нічого. Select перевіряється, insert, update і delete ніхто не писав, тож будь-хто може писати в таблицю, яку ніхто не може прочитати повністю.
• Умова збігається з більшою кількістю людей, ніж мала. Вона мала назвати одного клієнта, а називає кожного відвідувача з відкритою сесією, або кожного відвідувача.

Тепер частина, яка вирішує, як читати зелений результат. Ззовні ці три випадки й таблиця взагалі без захисту дають однакову відповідь, і це рядки. Ваші користувачі їх не розрізняють. Усі інші, хто відкриє ваш застосунок, теж ні.

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

Одне чесне застереження до цього числа. Ми стояли на тротуарі, і ми не маємо жодного погляду всередину цих проєктів. Ми можемо повідомити, що відповіли 2 017 опублікованих застосунків. Ми не можемо повідомити, скільки з них запускали сканування і що воно їм сказало.

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

Чого не побачить сканування ззовні

Натиснути ручку не скаже вам нічого про кімнату, яка не має дверей на вулицю, а таких чотири.

Ваше дерево залежностей npm не лежить на сторінці, яку завантажує браузер. Ваш серверний код, включно з edge functions і тим, чи перевіряє маршрут, хто звертається, працює там, куди ми ніколи не дістаємося. Таблиця, яку ваш фронтенд ніколи не називає, для нас невидима, бо ми знаходимо назви таблиць у коді, який віддає ваш застосунок, плюс короткий перелік поширених назв: таблицю, якої в браузері немає ніде і яку ніхто не вгадав би, ми просто не питаємо. А сервер MCP не є тим, що знаходить запит сторінки.

Два сканування Lovable разом читають усі чотири. Наше пише «Не вдалося перевірити», коли воно не змогло відповісти на питання, замість галочки.

Рядок про те, що ваш опублікований застосунок віддає незнайомцю, і є причиною запускати обидва, і саме навколо нього побудоване наше сканування. Загальна версія того, де закінчується погляд ззовні, є в що пропускає сканування за URL.

Обидва, і в такому порядку

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

1. Дайте Quick scan відпрацювати під час публікації, а тоді прочитайте його. Це кілька секунд, і воно однаково відбувається. Проклацати діалог це найпоширеніший шлях, яким знахідка Critical потрапляє в продакшн.
2. Запустіть Deep scan перед тим, як щось справжнє піде в люди, і ще раз після того, як додасте вхід, платежі чи будь-яку таблицю з людьми. Сам він не запуститься.
3. Опублікуйте.
4. Проскануйте опубліковану адресу ззовні. Наше читає ваш живий застосунок так, як його читає відвідувач, триває близько 20 секунд, не потребує акаунта і називає перевірки, які не змогло завершити: просканувати застосунок.

У цій послідовності є проміжок, і саме з ним варто рахуватися. Quick scan працює, коли ви публікуєте. Більшість того, що відкриває таблицю, взагалі не проходить через публікацію: ви змінюєте налаштування в панелі Supabase, ви опівночі приймаєте політику, яку асистент написав у вікні чату, ви створюєте таблицю зранку, а екран, що її читає, виходить у четвер. Ніщо з цього не є публікацією, тож ніщо з цього не запускає сканування, а Deep scan і так ніколи не запустився б сам.

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

Як читати зелений результат

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

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

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

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

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

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