"Vibe Coded" Додатки: Витік Даних через Швидкість та ШІ

Зниження Бар'єру для Розробки та Зростання Ризиків

Бар'єр для випуску програмного забезпечення ніколи не був таким низьким. Завдяки інструментам штучного інтелекту, ідея може бути перетворена на робочий прототип за один день та розгорнута до вечора. Хоча результати можуть бути вражаючими, Адам Конвей, провідний технічний редактор XDA, зазначає, що він постійно натрапляє на так звані «vibe coded» додатки, які витікають дані користувачів. Ці проблеми виникають знову і знову, і вони стосуються базових аспектів безпеки, які мали б бути вирішені ще на етапі розробки.

Ця тенденція не є новою і існувала задовго до появи великих мовних моделей (LLM), коли розробники залишали відкритими S3-бакети або надмірно довіряли фронтенду. Однак, що змінилося, так це обсяг таких помилок. Швидкість розробки скоротилася з тижнів до годин, але масштаби помилок також зросли.

Поширені Випадки Витоків Даних

Автор наводить кілька прикладів витоків даних, з якими він стикався:

Ігровий сайт: Нещодавно Конвей виявив ігровий сайт для популярного змагального шутера, який за допомогою однієї кінцевої точки повертав усю базу даних користувачів, включаючи імена, вподобання, електронні адреси та ігровий ранг. Інша кінцева точка повертала приватні розмови між двома іншими користувачами. Сайт завантажував дані всіх зареєстрованих користувачів, а фільтрація відбувалася на стороні клієнта, що означало, що дані вже були на машині користувача.
Контент-платформа: На іншій платформі, створеній за допомогою ШІ, автор виявив, що JSON-об'єкт, який надсилався сервером, містив не лише опубліковані дописи, а й чернетки, заплановані та тестові статті з повним текстом. Фронтенд приховував їх, але дані були доступні через вкладку «Мережа» в консолі розробника.

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

Гучні Випадки Витоків

Проблема витоків даних проявляється і в більш масштабних проєктах:

Платформа для анонімних доносів: Один сайт, який обіцяв анонімність користувачам, що надсилали інформацію про інших, виявив електронні адреси та номери телефонів самих донощиків через власний інтерфейс. Сайт було закрито, але дані вже були скомпрометовані.
Додаток спільноти з ідентифікацією: Інший додаток, що вимагав завантаження селфі та посвідчення особи при реєстрації, зберігав ці файли у хмарному сховищі, налаштованому на анонімне читання. Це призвело до витоку понад 70 тисяч зображень, включаючи 13 тисяч водійських посвідчень та паспортів, а також понад мільйон приватних повідомлень.
Huntarr – інструмент автоматизації: У випадку з Huntarr, самостійно розміщеним інструментом автоматизації, публічний аудит безпеки виявив 21 вразливість, включаючи неаутентифіковану кінцеву точку, що повертала паролі та API-ключі у відкритому тексті. Замість виправлення, розробник видалив проєкт та заблокував користувачів, які піднімали ці питання.

Корінь Проблеми: Неправильне Розуміння Авторизації

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

ШІ-інструменти особливо схильні до створення таких помилок. Якщо попросити помічника створити сторінку, яка показує профіль користувача з його повідомленнями, він охоче налаштує запит, який отримує повідомлення, і відобразить їх на сторінці, не замислюючись про те, кому дозволено їх бачити. Модель оптимізує те, що ви просили – сторінку, яка «працює». «Працює» і «безпечно» – це різні поняття.

Багато популярних ШІ-конструкторів додатків генерують фронтенд, який безпосередньо взаємодіє з хостинговими бекенд-сервісами, такими як Firebase або Supabase, використовуючи API-ключ, вбудований у клієнт. Проблема полягає в тому, що правила безпеки (наприклад, правила безпеки у Firebase або row-level security у Supabase) часто залишаються незміненими або неправильно налаштованими.

Масштаб Проблеми та Економічні Стимули

Дослідження, проведене Меттом Палмером та Коді Лоу, показало масштаб проблеми. Вони виявили, що генератор профілів LinkedIn, створений за допомогою Lovable (одного з відомих ШІ-конструкторів додатків), витікав усю базу даних користувачів. Після цього вони протестували 1645 додатків, представлених на маркетплейсі Lovable, і виявили, що 170 з них (приблизно кожен десятий) витікали дані користувачів через ту саму вразливість. Ця вразливість отримала ідентифікатор CVE-2025-48757, а її корінь полягав у тому, що додатки Lovable підключалися до Supabase без налаштованих політик безпеки на рівні рядків.

Економіка «vibe coding» винагороджує швидкість понад усе. Можна швидко створити невеликий SaaS-інструмент, поставити його за логін-стіну та почати стягувати плату. Якщо найгірше, що станеться, це те, що кілька ранніх користувачів помітять щось дивне і підуть, то «vibe coded» додаток може досягти прибутковості ще до того, як пройде справжній аудит безпеки.

Що це означає для розробників

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

Ключові факти

Бар'єр для випуску програмного забезпечення значно знизився завдяки ШІ, що дозволяє створювати прототипи та розгортати їх за лічені години.
Автор постійно виявляє «vibe coded» додатки, які витікають дані користувачів через небезпечне зберігання даних та неправильну авторизацію.
Приклади витоків включають повні бази даних користувачів, приватні розмови, чернетки статей, електронні адреси, номери телефонів, а також фотографії посвідчень особи та приватні повідомлення.
Корінь проблеми полягає в тому, що розробники (або ШІ-моделі) розглядають фронтенд як авторитет для авторизації, тоді як бекенд повертає всі дані.
ШІ-інструменти оптимізують додатки для функціональності («працює»), а не для безпеки («безпечно»), часто залишаючи правила безпеки (наприклад, row-level security у Supabase) неконфігурованими.