Reeve Чи безпечний ваш застосунок на Lovable?
Чи безпечно будувати на Lovable? Зазвичай так. Вирішує це одне налаштування бази даних, зроблене того дня, коли створювалися ваші таблиці.
Логотипи належать їхнім власникам і показані, щоб позначити сумісність.
Коротко
- Застосунок на Lovable з боку коду зазвичай безпечний. Чи безпечні ваші дані, вирішує одне налаштування Supabase, окреме для кожної таблиці.
- Знайти API-ключ у застосунку зазвичай нормально. Публічному ключу там і місце; sb_secret_… чи service_role там не місце.
- Supabase вмикає Row Level Security для таблиць, створених у Table Editor, але не для створених через SQL, а саме через SQL їх робить білдер.
Lovable доводить вас від ідеї до робочого застосунку швидше за будь-що інше, а та частина, яку він бере на себе, і є саме тією, якої ви ніколи не бачите: база даних, таблиці, правила про те, кому їх дозволено читати. Коли вам кажуть, що ваш застосунок на Lovable «зливає дані», відповідь зазвичай саме там, і туди ви не зазирнете з редактора.
Ось що гайд за гайдом подає неправильно: ризик майже ніколи не в коді, який Lovable написав за вас. Це одне налаштування бази даних, визначене тієї миті, коли таблиця була створена, і більшість текстів або пропускають його, або описують навпаки.
Що Lovable насправді будує і яка половина є публічною
Дві половини, і лише одна з них приватна.
Уявіть крамницю. Lovable будує вам вітрину (сторінки, кнопки, форми), і ця вітрина повністю вручається кожному відвідувачу. Прочитати її може будь-хто. Це не вада: браузер не покаже сторінку, якої йому не дали. За вітриною стоїть склад, ваша база даних у Supabase, і це окрема будівля з власним замком.
Помилка, яка людям дорого коштує, полягає в думці, що вітрина керує складом. Не керує. Прибрати кнопку із застосунку означає зняти вивіску, а не замкнути двері. До вашої бази даних можна дістатися напряму, через інтернет, будь-кому, хто знає її адресу, і ця адреса надрукована на вітрині, бо саме так із нею говорить ваш власний застосунок.
Чи є проблемою ключ у коді вашого застосунку на Lovable?
Зазвичай ні. Усе залежить від того, який це ключ, а є два різновиди, які майже не відрізняються на вигляд.
Публічний ключ каже, до якого проєкту належить запит, і більше нічого.
Supabase називає його sb_publishable_… у нових проєктах і anon у старіших, і
він створений для того, щоб лежати у вашому застосунку, де його може прочитати
будь-хто. Секретний ключ робить протилежне: sb_secret_… або service_role у
старіших проєктах. Він ігнорує кожне встановлене вами правило й може читати та
змінювати кожен рядок у кожній таблиці.
Обидва лежать поруч у панелі Supabase, мають однакову довжину й поводяться однаково, доки ви будуєте. Щоб скопіювати не той, вистачить одного невдалого кліка, після якого нічого не ламається, і саме тому це й лишається непоміченим. Якщо хочете докладну версію того, як їх розрізнити, ми її написали.
Що вирішує, чи можуть сторонні читати ваші дані
Row Level Security є перемикачем для кожної таблиці в Supabase, який рядок за рядком вирішує, кому що дозволено бачити. Коли він вимкнений, ваш публічний ключ читає всю таблицю. Коли ввімкнений і політику написано, читає лише ті рядки, які ця політика дозволяє.
Тепер частина, яка важлива саме для застосунку на Lovable. Supabase вмикає Row Level Security за замовчуванням для таблиць, створених у Table Editor панелі, тому, де клацають. Таблиці, створені виконанням SQL, отримують її вимкненою, і вмикати доводиться свідомо.
Виконання SQL і є тим, як білдер створює таблиці за вас.
Тож звичний проєкт на Lovable виглядає як кілька таблиць, які ви додали клацанням і які захищені, поруч із таблицями, згенерованими за вас, які, можливо, ні. У редакторі вони виглядають однаково. Жодна не поскаржиться. І ввімкнути налаштування ще не фініш, бо таблиця з увімкненою Row Level Security і політикою, яка дозволяє всім, відкрита у спосіб, що читається як закритий.
Як часто це трапляється, можна виміряти. З 3 553 застосунків Lovable, чий Supabase нам відповів, 2 017 віддали рядки запиту без жодного входу, а в 373 з них відкрита таблиця мала назву з людей. Повні цифри є в що показали 18 554 застосунки Lovable.
Як перевірити власний застосунок на Lovable приблизно за десять хвилин
Відкрийте Supabase, потім Authentication → Policies. Перегляньте список таблиць. Усе, що позначено як «Row Level Security вимкнено», може прочитати будь-хто, у кого є адреса вашого проєкту, а вона публічна.
Перевірте ключ, який відвантажує ваш застосунок. У Supabase відкрийте Settings → API. Якщо ваш застосунок використовує публічний ключ, усе правильно й робити нічого не треба. Якщо ж у проєкт на Lovable колись вставляли секретний ключ, спершу замініть його там: видалення з коду двері не зачиняє, бо старе значення досі є в кешованих копіях вашого сайту.
Подивіться на свої сховища файлів. Усе позначене як публічне може переглянути й завантажити будь-хто, незалежно від того, чи посилається на це ваш застосунок.
А потім подивіться ззовні. Перевірки вище кажуть, що налаштовано; вони не кажуть, до чого справді дістається сторонній. Саме цю прогалину закриває наше безкоштовне сканування: воно читає ваш живий сайт так само, як це зробив би будь-який відвідувач, і дає оцінку приблизно за 20 секунд, без акаунта: сканувати застосунок.
Що робити
- Вітрина публічна за задумом. Усе, що Lovable віддає браузеру, може прочитати будь-хто, і жодне приховування цього не змінює.
- Публічний ключ у застосунку доречний. Секретний ключ (
sb_secret_…абоservice_role) варто замінити сьогодні. - Таблиці, зроблені в Table Editor Supabase, мають Row Level Security увімкненою за замовчуванням. Створені через SQL її не мають, а саме так їх робить білдер.
- Увімкнути Row Level Security – це крок перший. Політика, яка дозволяє всім, лишає таблицю відкритою, поки панель повідомляє, що вона захищена.
- Прибрати екран чи кнопку із застосунку на Lovable нічого не змінює в тому, що відповість ваша база даних.
Найшвидше корисне, що можна зробити сьогодні: відкрити в Supabase Authentication → Policies і прочитати список. Якщо для якоїсь таблиці написано, що Row Level Security вимкнено, почніть із неї, а якщо вам зручніше пройти всю поверхню списком, 10-хвилинний чекліст безпеки охоплює решту.
Що насправді може піти не так із застосунком на Lovable
Жоден із цих пунктів не означає, що ви зробили щось не так. Це звичайні побічні ефекти швидкої розробки. Ось те, що варто перевірити:
Секретний ключ, що потрапив у браузер
«Секретний ключ» є головним паролем до сервісу, яким ви користуєтесь: вашої бази даних, поштового інструмента, AI-API. Він має жити на сервері. Іноді такий ключ прослизає в код, що виконується у браузері відвідувача, де його може прочитати будь-хто й скористатися ним, щоб дістатися ваших даних або накрутити рахунки від вашого імені. Нюанс: деякі ключі й мають бути публічними (Lovable та Supabase називають їх «publishable» або «anon»), і це нормально. Reeve розрізняє їх, тож безпечний ключ ніколи не спричинить хибної тривоги.
Відкрита база даних (RLS у Supabase вимкнено)
Застосунки на Lovable зазвичай зберігають дані в Supabase. У Supabase є запобіжник під назвою Row Level Security (RLS, захист на рівні рядків), який вирішує, кому дозволено читати чи змінювати кожен рядок. Якщо він вимкнений, ваші таблиці можуть бути доступні для читання, або й редагування, будь-кому, хто знайде адресу. Це різниця між «мої дані належать мені» і «мій список клієнтів публічний», і це найпоширеніша проблема vibe-coded застосунків.
Відкритий файл .env або конфігурації
Файл .env є місцем, де проєкт зберігає паролі та ключі. Час від часу він помилково публікується разом із застосунком. Якщо до нього можна дістатися, це пряма стежка до всього найчутливішого. Reeve перевіряє, чи не доступний ваш файл потихеньку.
Публічне сховище файлів
Якщо ваш застосунок дозволяє завантажувати файли (фото, PDF), вони живуть у «бакетах» сховища. Публічний бакет означає, що будь-хто може переглядати чи завантажувати те, що всередині, тож файл, призначений для однієї людини, може стати видимим усім. Reeve перевіряє, чи можна переглянути список ваших бакетів; він ніколи не завантажує чужих файлів.
Увімкнені Source maps
«Карта коду» (source map) є закулісним файлом, що розкриває оригінальний код вашого застосунку. Зручно під час розробки, але якщо вона потрапляє в продакшн, то дає стороннім читабельну копію того, як влаштований ваш застосунок, а це полегшує пошук усіх дверей вище. Само по собі не критично, але варто прибрати.
Відсутні заголовки безпеки та відкриті ендпоінти
Невеликі налаштування, що підказують браузерам, як захищати ваших відвідувачів, а також те, чи відповідають точки доступу до даних будь-кому чи будь-якому сайту. Окремо це дрібниці; разом вони розширюють щілину. Reeve позначає ті, яких бракує.
Що таке Reeve і чим він не є
Reeve є безкоштовною перевіркою ззовні в режимі читання, наче інспектор, який обходить будинок по периметру й перевіряє двері. Це швидко, і це ловить поширені помилки з великими наслідками. Це не повний аудит безпеки, і чиста оцінка не є гарантією: вона означає, що очевидні двері зачинені.
Lovable є потужним інструментом, і його команда додає дедалі більше запобіжників; у Supabase теж є вбудований радник, що позначає проблеми з RLS у панелі керування. І те, і те справді корисне. Що додає Reeve: ви живете в Lovable, а не в консолі Supabase, і ті інструменти говорять мовою розробників. Reeve дивиться на весь ваш застосунок ззовні, так, як подивився б сторонній, і розповідає знайдене словами, за якими можна діяти. А якщо ви взагалі не хочете про це думати, ми можемо стежити за ним замість вас.
Хочете, щоб цим займалися, а не лише перевірили?
Reeve Care продовжує стежити за вашим застосунком, робить резервні копії даних і допомагає полагодити, коли щось ламається, щоб ви могли будувати далі, а не хвилюватися.
Дізнатися про Reeve CareПоширені запитання
Чи безпечний мій застосунок на Lovable за замовчуванням?
Lovable дає надійну відправну точку й постійно покращує свої налаштування за замовчуванням, але «безпечний за замовчуванням» усе одно залежить від того, як налаштований ваш застосунок, надто ж від правил вашої бази даних у Supabase. Дізнатися можна, лише перевіривши, що насправді відкрито; саме це безкоштовне сканування Reeve робить приблизно за 20 секунд.
Чи може застосунок на Lovable злити мої API-ключі?
Таке трапляється, зазвичай коли ключ, якому місце на сервері, опиняється у фронтенд-коді. Але не кожен ключ є проблемою: деякі й створені публічними. Reeve читає завантажений код вашого застосунку, знаходить будь-які ключі й підказує, які з них безпечні, а які треба перенести.
Що таке Supabase RLS і чому це важливо для мого застосунку на Lovable?
RLS (Row Level Security, захист на рівні рядків) є правилом Supabase про те, хто може бачити чи змінювати кожен рядок ваших даних. Якщо його вимкнено, ваші таблиці можуть бути відкриті будь-кому. Оскільки більшість застосунків на Lovable використовують Supabase, це найважливіше, що варто налаштувати правильно, і Reeve перевіряє це, жодного разу не читаючи ваших справжніх даних.
Чи зламає сканування мій застосунок на Lovable і чи змінить дані?
Ні. Reeve дивиться лише на те, що вже публічне ззовні. Він ніколи не входить в акаунти, нічого не змінює й не завантажує ваших файлів. Режим читання, наче перевірка, чи замкнені двері, не заходячи всередину.
Lovable зробив базу даних за мене. Це означає, що вона налаштована безпечно?
Не автоматично, і причина цілком конкретна. Supabase вмикає Row Level Security за замовчуванням для таблиць, які ви створюєте клацанням у Table Editor. Таблиці, створені виконанням SQL, її не отримують, а саме через SQL білдер створює таблиці за вас. Тож таблиці, зроблені вами вручну, зазвичай захищені, а зроблені Lovable, можливо, ні.
У яких моїх таблиць увімкнено Row Level Security?
Відкрийте свій проєкт у Supabase, перейдіть до Authentication, потім до Policies. Там перелічено кожну таблицю вашої схеми public і показано, чи ввімкнено RLS. Усе, що позначено як вимкнене, може прочитати будь-хто, у кого є адреса вашого проєкту й ваш публічний ключ, і обидві ці речі лежать усередині вашого застосунку.
Я знайшов ключ у своєму застосунку на Lovable. Як зрозуміти, чи це важливо?
Подивіться, який це ключ. Публічний ключ (у нових проєктах Supabase він зветься sb_publishable_, у старіших anon) має бути у браузері, і це не витік. Секретний ключ, sb_secret_ або старіший service_role, ігнорує кожне ваше правило й ніколи не повинен потрапляти у браузер. Якщо знайшли саме його, замініть його в панелі Supabase перш за все інше.