bubble app security для Bubble.io: чеклист privacy rules і API до Live
Перед першими користувачами і оплатами я проходжу privacy rules, ролі, URL, Workflow/Data API та API Connector — підказки в інтерфейсі не дорівнюють захисту даних.
Чому це не «як користуватися додатком»
У пошуку how to use bubble app змішується з питаннями про захист. Я solo bubble io developer — для мене різниця проста: прихована кнопка або окрема admin-сторінка не є авторизацією. Доступ до даних задають privacy rules на сервері, налаштування API і те, які поля взагалі потрапляють у браузер. Про це окремо: Bubble MVP за 14 днів:.
Bubble працює за моделлю спільної відповідальності: платформа (Bubble/AWS) тримає інфраструктуру; я — правила доступу, ключі, workflow-и та інтеграції. Поруч із цим: FLUX 3 Image і Vercel.
1. Privacy Rules: мінімум до Deploy
- Нові типи даних. З 2021 року новий data type за замовчуванням public, якщо не увімкнути «private» при створенні (тоді з’являється placeholder rule лише для creator). Я не покладаюся на «потім допишу rules».
- Патерн правил. Окремі grant-правила для ролей/умов + Everyone else з deny на view/search/modify там, де потрібно. Приклад з docs: поле Admin на User + additive rules.
- Поля, не лише UI. Якщо rule дозволяє view field, клієнт може отримати ці дані (DevTools, мережа) навіть коли елемент прихований. Principle: least privilege по полях.
- Search privacy mode (Settings → General): Strict рекомендований для чутливих застосунків; Automatic може дозволити inference через searches на сторінках. Перехід на Strict інколи ламає пошуки, доки не дозволите constrainable fields — я закладаю час на виправлення.
- User type. Я перевіряю правила на вбудованому User так само ретельно, як на власних типах.
Інструмент: Privacy rules checker у Security Dashboard — потрібні sample records у типах, які тестую. Про це окремо: AI кодинг для Bubble: ai.
2. Ролі без «секретів у option sets»
Типовий патерн для SaaS: роль на User (наприклад, option set User Role) + умови в privacy rules (related company, creator тощо).
- Option sets відправляються на клієнт; privacy rules на них не діють. Я ніколи не зберігаю там API keys, internal tokens, «секретні» URL.
- Redirect з Page loaded для «не-admin» — зручно для UX, але не замінює rules на data types.
3. URL parameters і тимчасові дані
- URL і custom states не зашифровані; користувач може змінити query вручну.
- Передача unique id thing у URL — нормальна практика, якщо privacy rules блокують чужий read/update.
- Я не кладу в URL/secrets/custom states: паролі, токени, PII, які не повинні світитися.
4. Workflows vs auto-binding
- Privacy rules не блокують запис через workflows так, як auto-binding. Для edit/delete через workflow я ставлю Only when умови (власник, роль, tenant).
- Allow auto-binding — окремо на поле; без явного дозволу auto-binding не «випадково» відкриє mass assignment.
| Аспект | Workflows | Auto-binding |
|---|---|---|
| Privacy rules і запис | Не блокують запис так, як auto-binding | Блокування запису через privacy rules — інакше, ніж у workflows |
| Edit/delete | Only when умови (власник, роль, tenant) | — |
| Дозвол на полі | — | Allow auto-binding — окремо на поле |
| Mass assignment | — | Без явного дозволу не «випадково» відкриє mass assignment |
5. Data API і Workflow API
Data API (за замовчуванням вимкнений):
- Admin bearer token = повний доступ до БД, privacy rules ігноруються. Я зберігаю його як root password; окремі dev/live keys; мінімальна кількість.
- Виклики від імені залогіненого user — rules застосовуються.
- Я вмикаю лише типи/операції, які реально потрібні зовнішньому клієнту.
Workflow API:
- Endpoint без authentication викликає будь-хто з URL — ризик abuse/workload, не лише «виток даних».
- Ignore privacy rules when running the workflow — server-side admin-level доступ. Небезпечно разом із слабкою auth або широким search усередині workflow.
- Auth + умови в workflow + коректні rules на user-facing шляхах — три шари, а не один checkbox.
Деталі: Data API security, Workflow API security.
6. API Connector і секрети
- За замовчуванням виклики йдуть через сервер — private auth/parameters не потрапляють у клієnt.
- Я обережний з Use as: Data + слабка auth (None, OAuth2 User-Agent Flow), якщо чутливі параметри в query/body.
- Ключі — у private header/parameter; не в option sets, не в тексті workflow на сторінці, не в URL.
- Dev/live ключі розділяю; права й rate limits — на стороні провайдера API.
7. Security Dashboard (scan.bubble.io)
Автоматичний аудит доповнює ручну перевірку, але не замінює її (heuristics):
- privacy rules / publicly accessible fields;
- search privacy mode;
- exposed credentials (secrets scanner);
- небезпечні API Connector configs;
- unauthenticated API workflows;
- слабка password policy.
Після виправлень я роблю повторний прогін перед Live.
8. Тести в dev app (авторська матриця, не офіційний Bubble checklist)
Я створюю 2–3 тестових користувачів (різні ролі/tenant). Для кожного критичного data type:
- Logged out — прямий URL з id чужого запису; search/repeating group на index; Data API (якщо увімкнений) без token / з user token.
- Wrong role — той самий id swap у URL; спроба workflow через API з чужим session.
- Logged in, correct role — переконуюся, що потрібні операції все ще працюють після посилення rules.
- DevTools — чи немає зайвих полів у відповідях для «звичайного» user.
| Сценарій | Перевірки |
|---|---|
| Logged out | Прямий URL з id чужого запису; search/repeating group на index; Data API (якщо увімкнений) без token / з user token |
| Wrong role | Той самий id swap у URL; спроба workflow через API з чужим session |
| Logged in, correct role | Переконатися, що потрібні операції все ще працюють після посилення rules |
| DevTools | Чи немає зайвих полів у відповідях для «звичайного» user |
9. Плагіни
Офіційні docs не гарантують residency даних плагінів. З community-практики: автор плагіну не отримує доступ до вашої БД, доки ви самі не відправите дані зовнішнім call через plugin element. Я перевіряю, що йде на third-party server; використовую designated secret fields, не public plugin properties (Dashboard це підсвічує).
10. OWASP LCNC як зовнішня рамка
OWASP Citizen Development / LCNC Top 10 — не покрокова інструкція Bubble, але зручно для self-audit: authorization misuse, data leakage, secret handling, misconfiguration, untrusted components. Я зіставляю з пунктами вище.
Перед Live: короткий порядок
- Privacy rules + Search mode на всіх типах з PII/оплатами.
- Ролі в rules, не лише в UI.
- URL/custom states без секретів.
- Workflow conditions + auto-binding review.
- Data/Workflow API: вимкнути зайве, auth на endpoint, без зловживання ignore privacy rules.
- API Connector routing і ключі.
- Security Dashboard + ручні сценарії в dev.
- Огляд плагінів.
bubble.io login і сесії користувача — частина моделі, але не замінюють rules на ваших типах даних. Статус платформи (bubble.io status) стежу окремо; він не закриває misconfiguration у моєму bubble.io app.
Джерела: Security | Bubble Docs, Protecting data with privacy rules, Security dashboard.