Ризики кібербезпеки в мобільних застосунках на вайбкодингу: що ламається насправді

Коротко

• Застосунки на вайбкодингу виходять у реліз із передбачуваними дірами в безпеці: ШІ генерує правдоподібний на вигляд код, а не перевірений
• Топ-5 ризиків: зашиті в код секрети, незахищене локальне сховище, відсутній пінінг сертифікатів, слабкі сценарії автентифікації, неперевірені сторонні SDK
• Реальні наслідки: витоки даних, видалення з App Store, штрафи за GDPR, колективні позови
• У кожній кодовій базі на вайбкодингу, яку ми аудитували, було щонайменше три з цих проблем
• Рішення: досвідчений інженер переглядає кожен рядок, що торкається облікових даних, мережі чи даних користувачів, — до запуску, а не після витоку

Текст підготувала команда Applefy. Ми аудитували мобільні кодові бази, зроблені іншими студіями, підрядниками та процесами, де працював лише ШІ. Картина щоразу та сама.

Вайбкодинг дає застосунки, які виглядають завершеними, але такими не є. Інтерфейс працює. Основний сценарій проходить. А під капотом модель безпеки — це те, що ШІ вгадав останнім.

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

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

Чому вайбкодинг провалюється саме на безпеці

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

Три структурні причини:

1. Безпека за замовчуванням невидима. Погана архітектура проявляється низькою продуктивністю. Погана безпека проявляється лише тоді, коли нею хтось скористається. В ШІ немає зворотного зв’язку, який сказав би, що щойно написаний код уразливий.
2. У тренувальних даних є погані приклади. На Stack Overflow повно «робочих» відповідей, які зберігають токени в UserDefaults або обходяться без пінінгу сертифікатів. Модель не знає, які з прикладів хибні.
3. Моделювання загроз вимагає суджень. Зрозуміти, від чого саме захищатися — у вашому конкретному контексті, з вашими конкретними користувачами й даними, — це людська робота. ШІ не ставить тих запитань, які ставить інженер, що думає про безпеку.

Результат: застосунки на вайбкодингу стабільно ламаються в тих самих кількох місцях.

7 найпоширеніших провалів безпеки в мобільних застосунках на вайбкодингу

1. API-ключі та секрети, зашиті в бінарник

Ви випустили серверний ключ Firebase, секрет Stripe або токен стороннього API прямо всередині зібраного застосунку. Будь-хто, у кого є IPA чи APK, дістане його за лічені хвилини.

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

Ціна: будь-хто може звертатися до вашого бекенду так, ніби це ваш застосунок. Вичерпає безкоштовний ліміт, зловживатиме вашими API або видаватиме себе за користувачів. Ротація ключів — болісна процедура. Заміна скомпрометованого ключа після запуску може розтягнутися на тижні.

2. Чутливі дані в UserDefaults замість Keychain

Токени автентифікації, токени оновлення, облікові дані до API — усе це лежить у UserDefaults на iOS або в SharedPreferences на Android. І те, і те — звичайні незашифровані файли, які можна прочитати з резервної копії або з пристрою з jailbreak.

Як це стається: ШІ бере найпростіший патерн «зберегти це на диск», а це UserDefaults. Keychain вимагає більше кроків налаштування. Перемагає коротший шлях.

Ціна: вкрадений пристрій або зламана резервна копія = вкрадений акаунт. У користувачів iOS резервні копії лежать в iCloud. У користувачів Android є бекапи через ADB. Обидва шляхи зливають облікові дані.

3. Немає пінінгу сертифікатів

Ваш застосунок довіряє будь-якому сертифікату, який підсуне мережа. У корпоративній або ворожій мережі з проксі типу man-in-the-middle зловмисник читає кожен виклик API, який робить ваш застосунок. Він бачить токени автентифікації, платіжні дані, персональну інформацію.

Як це стається: коректно реалізований пінінг сертифікатів — це 20–40 рядків коду. ШІ рідко додає його, якщо про це не попросити прямо.

Ціна: зловмисники у Wi-Fi кав’ярень, моніторинг корпоративної мережі, шкідливі VPN-провайдери — усі вони бачать ваш трафік у відкритому вигляді. Для фінтех- чи медичного застосунку це вже порушення регуляторних вимог.

4. Зламані сценарії автентифікації, які виглядають правильними

Екран входу працює. Перевірка пароля працює. Сценарій виглядає завершеним. Але логіка оновлення токена насправді не перевіряє новий токен перед тим, як його зберегти. Або вихід із застосунку не завершує сесію на сервері. Або скидання пароля довіряє посиланню з листа без перевірки на сервері.

Як це стається: ШІ пише код автентифікації, наслідуючи патерни. Результат компілюється. Основний сценарій працює. А крайні випадки — прострочені токени, повторно відтворені токени, стани гонки — ніхто не перевіряє.

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

5. Неперевірені сторонні SDK

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

Як це стається: ШІ оптимізує за критерієм «функція запрацювала», а не «чи можна довіряти цьому супровіднику». Деякі популярні бібліотеки вже зламували в атаках на ланцюг постачання. Деякі покинуті. Деякі збирають дані користувачів, про які застосунок ніде не повідомив.

Ціна: порушення законів про приватність (GDPR, CCPA, COPPA). Відхилення або видалення з App Store. Репутаційний удар, коли дослідник безпеки опублікує, що ваш застосунок стукається на сервер у країні, яка не має до вас жодного стосунку.

6. Немає перевірки вхідних даних у WebView і deep links

Застосунки з вбудованими WebView довіряють будь-якому URL, який їм дають завантажити. Застосунки з deep links довіряють будь-яким параметрам, що надходять. І те, і те — класичні вектори XSS та ін’єкцій.

Як це стається: ШІ генерує виклик завантаження у WebView, не думаючи про недовірені вхідні дані. Парсери deep links приймають довільні параметри й передають їх прямо в запити.

Ціна: зловмисник надсилає жертві посилання, яке відкриває застосунок і запускає привілейовану дію. Або виконує JavaScript усередині WebView з доступом до нативних мостів.

7. Немає рядків призначення в Info.plist і декларацій про приватність

Ваш застосунок звертається до камери, геолокації, контактів чи мікрофона, але Info.plist (iOS) або AndroidManifest.xml (Android) не пояснює навіщо. І App Store, і Google Play за це відхиляють застосунки. Гірше: навіть якщо застосунок вийде, він порушує очікування користувачів щодо приватності.

Як це стається: ШІ генерує виклик API, але пропускає налаштування маніфесту. У продакшні застосунок падає під час першого ж звернення до цього API.

Ціна: відхилення в App Store (Guideline 5.1.1). А якщо застосунок усе ж вийшов — ризики за GDPR і CCPA. (Причини відхилень ми зібрали в посібнику з публікації в App Store.)

7 ризиків одним поглядом

Реальні наслідки

Нічого з цього не є теорією.

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

Видалення з App Store. І Apple, і Google видаляють застосунки, які порушують правила розкриття даних про приватність. Запуск мертвий. База користувачів випаровується. Повторна подача з виправленнями забирає тижні.

Штрафи за GDPR і CCPA. Європейські регулятори вже виписували штрафи на десятки мільйонів за недбале поводження з даними користувачів. CCPA у Каліфорнії додає ще один шар. Більшість застосунків на вайбкодингу навіть не здогадуються, що вже порушують правила.

Колективні позови. Американські юрфірми, що представляють позивачів, автоматично сканують застосунки на порушення приватності. Знахідка перетворюється на позов. Умови мирових угод публічні.

Провалені аудити й SOC 2. Якщо ви продаєте B2B, сертифікація з безпеки не обговорюється. Мобільний клієнт на вайбкодингу провалює кожен розділ аудиту SOC 2.

Скільки коштує знайти проблему пізно, а скільки — запобігти їй

Виправити діру в безпеці до запуску — кілька годин інженерного рев’ю.

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

Різниця між «знайти пізно» і «запобігти» тут ближча до 100x, ніж до 10x, які ми наводимо для загальної якості коду. Помилка в безпеці — найдорожча з тих, які виявляють запізно.

Який вигляд має справжній аудит безпеки

В Applefy кожен проєкт на iOS та Android, який ми випускаємо, проходить через таке:

1. Аудит секретів. Жодних ключів у бінарнику. Усі секрети підставляються під час збірки або підтягуються зі сховища на сервері.
2. Рев’ю сховища. Будь-які збережені облікові чи персональні дані проходять через Keychain (iOS) або EncryptedSharedPreferences (Android). UserDefaults і SharedPreferences — лише для нечутливих даних.
3. Мережева безпека. Пінінг сертифікатів налаштовано. ATS увімкнено на iOS. Конфігурацію мережевої безпеки на Android закрито.
4. Рев’ю сценаріїв автентифікації. Життєвий цикл токена, логіка оновлення, завершення сесії при виході, скидання пароля — усе це переглядає досвідчений інженер за чеклістом OWASP Mobile.
5. Аудит залежностей. Кожен сторонній SDK перевіряємо за репутацією супровідника, датою останнього оновлення, заявленими дозволами та поведінкою під час роботи.
6. Маніфест і мітки приватності. Кожне звернення до API має рядок із поясненням призначення. Мітки App Privacy Labels точно відображають, які дані збираються. (Див. наш посібник із безпеки iOS-застосунків.)
7. Тест на проникнення перед запуском. Зовнішній тестувальник працює з продакшн-збіркою. Знайдене виправляємо до подачі в App Store.

Ось і вся різниця. Роботи не меншає. Хтось має її зробити.

Часті запитання

Чи можна замість переписування просто зробити аудит безпеки застосунку на вайбкодингу?

Іноді так. Усе залежить від того, що знайдете. Поверхневі проблеми (немає рядків призначення, слабке сховище) можна залатати. Архітектурні (немає підтримки пінінгу сертифікатів, зламана модель автентифікації) часто вимагають переписати більші частини коду.

Скільки коштує аудит безпеки мобільного застосунку?

Типовий діапазон для невеликого чи середнього мобільного застосунку — 8K–20K € за ґрунтовний аудит. Більше, якщо в роботу входить і усунення знайденого. Усе одно дешевше за витік.

Який мінімальний рівень безпеки потрібен мобільному застосунку стартапу?

Keychain або EncryptedSharedPreferences для чутливих даних. Пінінг сертифікатів. Жодних секретів у бінарнику. Сценарій автентифікації, переглянутий досвідченим інженером. Точні мітки приватності. Далі — моделюйте загрози, виходячи з того, з якими даними працюєте.

Чи актуальний OWASP Mobile Top 10 як орієнтир у 2026 році?

Так — це стандартний галузевий чекліст. Беріть його за базу. І доповнюйте рекомендаціями під платформу: документацією Apple з безпеки iOS та порадами Google щодо безпеки Android.

Чи допомагає ШІ в тестуванні безпеки?

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

А серверна безпека — хіба не там більший ризик?

Важливе і те, і те. Мобільний клієнт часто простіша мішень, бо бінарник сам приїжджає на пристрій зловмисника. Але так, серверна безпека не менш критична. Більшість тих самих принципів (жодних зашитих секретів, аудит залежностей, перевірка вхідних даних) працює й там.

Чи можна отримати сертифікацію з безпеки мобільного застосунку?

Найчастіше клієнти просять SOC 2 Type II. ISO 27001 — ширший. Для платежів обов’язковий PCI DSS. Жодного з них не отримати на кодовій базі з вайбкодингу без суттєвого переписування.

Як Applefy уникає цих проблем?

Критичний для безпеки код пишуть руками досвідчені інженери. На згенерований ШІ код — лінтер-хуки й обов’язкове рев’ю. Тест на проникнення перед кожним запуском. (Див., як ми використовуємо Claude Code.) Проблема не в інструменті, а в нагляді.