Бесплатный тариф конструктора приложений: как проверить условия безопасности перед регистрацией

Кликнул «Start Free», получил workspace на субдомене платформы, накидал форм, подключил таблицу, показал демо заказчику — и через три месяца выяснил, что часть клиентских данных уезжает в браузер шире, чем должна, а доступ к проекту держится на одном пароле редактора. Знакомая история? Должна быть. В no-code это происходит не потому, что люди внезапно разучились думать о безопасности. Просто бесплатный тариф очень ловко маскирует ограничения: снаружи он выглядит как «меньше места и меньше пользователей», а внутри часто оказывается «меньше контроля, меньше журналов, меньше способов закрыть доступ».

Безопасность данных в бесплатных конструкторах приложений начинается не с красивой страницы Security и не с обещаний про «enterprise-grade infrastructure». Она начинается с неприятного вопроса: что именно платформа не даёт вам проверить, настроить и принудительно включить, пока вы не перешли на платный уровень. И вот там, в этой серой зоне между «можно собрать за вечер» и «можно доверить реальные данные», обычно и лежит основная мина.

В 2025 году исследователи из Wiz Research описали критические проблемы в Base44: речь шла об обходе аутентификации и доступе к чужим приложениям через несанкционированное использование учётных записей. Важна здесь не вывеска конкретной платформы, а механика. Даже сервисы, которые говорят с рынком на языке зрелой разработки, остаются платформами со своей закрытой логикой, своими ошибками и своими зонами непрозрачности. Бесплатный тариф добавляет к этому ещё один слой: часть защитных функций может быть недоступна, часть — урезана, часть — спрятана за формулировкой «available on higher plans».

Ловушка бесплатного доступа: почему отсутствие 2FA и SSO делает приложение уязвимым

Начнём с самого скучного и потому самого недооценённого: доступа к рабочему пространству. В классической разработке уже давно считается странным держать продакшн-проект на одном пароле без двухфакторной аутентификации, без централизованного управления пользователями и без понятной процедуры удаления доступа. В no-code это до сих пор выглядит для многих как «ну мы же пока только тестируем».

Проблема в том, что «пока тестируем» очень быстро превращается в «туда уже занесли настоящую базу». Сначала это десять лидов из формы. Потом выгрузка из CRM. Потом таблица с телефонами, статусами оплат и комментариями менеджеров. А доступ к конструктору всё ещё живёт в личном ящике основателя, продуктолога или подрядчика, который собрал первую версию.

Двухфакторная аутентификация для участников workspace на бесплатных или стартовых тарифах у разных платформ устроена по-разному: где-то она доступна сразу, где-то ограничена, где-то вынесена в более дорогие планы или корпоративные настройки. Проверять надо не рекламный лендинг, а конкретное место в документации и настройках аккаунта: можно ли принудительно включить 2FA для всех редакторов проекта, а не просто «порекомендовать» её каждому участнику.

Один пароль — одна точка отказа. Если участник проекта использует тот же email и похожий пароль, что в других сервисах, компрометация стороннего аккаунта становится входом в приложение. И дальше уже неважно, насколько аккуратно вы настроили формы: злоумышленник заходит не через пользовательский интерфейс, а через редактор, где лежат источники данных, интеграции, API-ключи, настройки публикации и права.

SSO — та же история, только для команд. Если платформа не даёт подключить корпоративный IdP через SAML или OpenID Connect на выбранном тарифе, вы не можете нормально управлять жизненным циклом доступа. Сотрудник уволился — его надо удалить вручную. Подрядчик закончил работу — снова вручную. У человека сменился отдел — вручную. В маленькой команде это кажется терпимым до первого забытого аккаунта.

Двухфакторка в конструкторе приложений — не «удобство для зрелых компаний». Это последний простой барьер перед тем, как чужой пароль станет вашим инцидентом.

Есть ещё один тихий слой риска: история изменений. На бесплатных тарифах могут быть ограничены версии, staging/production-разделение, расширенные журналы и откаты. Даже если платформа в целом поддерживает такие механизмы, не факт, что они доступны именно в бесплатном режиме и именно для вашего типа проекта. А без истории изменений расследование превращается в гадание: кто поменял правило доступа, когда исчез фильтр, почему новая форма стала отдавать лишние поля.

Здесь не нужно впадать в паранойю. Нужно просто считать отсутствие этих функций не «особенностью тарифа», а частью модели угроз. Если приложение касается реальных людей и реальных данных, доступ к редактору становится не менее важным, чем доступ конечных пользователей.

Риск субдоменов: как работа на платформенных доменах повышает вероятность фишинга

Бесплатные тарифы часто оставляют приложение на домене платформы: что-то вроде project.platform.app или myapp.builder.io. Для демо это удобно. Для продукта, который собирает данные пользователей, — уже не так невинно.

Субдомен конструктора не принадлежит вам в нормальном смысле этого слова. Вы не управляете корневым доменом, не контролируете его репутацию, не можете настроить часть DNS-политик так, как сделали бы на собственном домене. Пользователь видит в адресной строке не ваш бренд, а бренд платформы с добавкой имени проекта. Если он вообще смотрит в адресную строку — что уже отдельный оптимистичный сценарий.

Главный риск здесь — фишинг и подмена доверия. Чем больше приложений живёт на одном платформенном домене, тем проще злоумышленнику построить правдоподобную имитацию: похожее имя проекта, похожий интерфейс, похожая форма входа. Собственный домен не делает вас бессмертным, но даёт нормальные инструменты защиты: контроль DNS, настройку почтовой аутентификации, управление сертификатами и более понятную коммуникацию с пользователем. У платформенного субдомена эта связь размыта.

Есть и технические нюансы. У современных платформ cookie обычно настроены с учётом изоляции приложений, флагов Secure, HttpOnly и SameSite. Но проверять это надо руками, а не верить формулировке «secure by default». Особенно если приложение работает в связке с внешними таблицами, встроенными виджетами, плагинами и авторизацией через сторонние сервисы. Чем больше компонентов, тем больше мест, где граница между вашим приложением и чужим кодом становится тоньше.

Не надо автоматически записывать любой платформенный субдомен в катастрофу. Для прототипа, закрытой демонстрации или учебного проекта это нормальный компромисс. Но если вы просите пользователя вводить персональные данные, загружать документы, оставлять финансовую информацию или проходить регистрацию — домен перестаёт быть косметикой. Он становится частью доверительной модели.

Практическая проверка здесь простая:

• можно ли подключить собственный домен на вашем тарифе;
• можно ли настроить корректные редиректы и запретить использование старого платформенного адреса как основного;
• как выглядит страница входа и не путает ли она пользователя брендами;
• какие cookie выставляет приложение и какие у них флаги;
• есть ли у платформы понятная политика по злоупотреблениям на соседних субдоменах.

В бесплатном режиме часть этих ответов часто оказывается неудобной. И лучше узнать это до того, как адрес приложения попал в письма, презентации и пользовательские закладки.

Ошибка фильтрации на стороне клиента: почему данные видны в коде страницы

Вот классика no-code, которая не устаревает. Приложение берёт из источника данных больше записей, чем нужно конкретному пользователю, а потом фильтрует отображение уже в браузере. На экране человек видит только «свои» строки. В сетевых ответах, JavaScript-объектах или состоянии страницы может лежать больше.

Для новичка это выглядит логично: в визуальном редакторе есть фильтр «показывать записи текущего пользователя», значит, доступ закрыт. Но фильтр интерфейса и правило доступа — не одно и то же. Первое отвечает за то, что нарисовано на экране. Второе — за то, какие данные вообще покинули сервер или внешний источник.

Если чужие записи уже приехали в браузер, они не защищены. Они просто не показаны штатным компонентом. Любой пользователь с минимальным любопытством открывает DevTools, смотрит Network, XHR/Fetch, Local Storage, состояние приложения — и видит, насколько честно платформа отрезает лишнее. Это не «хакерство в капюшоне». Это базовая диагностика фронтенда.

На бесплатных тарифах риск усиливается не магически, а организационно. Пользователь конструктора чаще выбирает самый быстрый путь: подключить таблицу, вывести список, поставить фильтр в компоненте. Серверные правила, политики доступа, отдельные API-слои, проекции полей, middleware — всё это либо отсутствует, либо требует другого уровня тарифа, либо просто не попадает в поле зрения человека, который собирает MVP к пятнице.

OWASP в материалах по no-code/low-code и citizen development отдельно выделяет утечки чувствительных данных и слепое доверие к платформенной логике. Это не академическая страшилка. Визуальные конструкторы действительно поощряют мышление «если компонент не показывает, значит, доступа нет». Для безопасности это плохая привычка.

Проверка занимает меньше времени, чем настройка красивой страницы входа. Создайте двух тестовых пользователей. Дайте каждому по набору записей. Зайдите под первым, откройте DevTools, обновите страницу и посмотрите, что реально пришло в браузер. Потом повторите под вторым. Если в ответах есть данные не того пользователя — приложение нельзя считать готовым к реальной эксплуатации, даже если интерфейс выглядит безупречно.

И отдельно смотрите поля. Утечка не всегда выглядит как «пользователь А видит карточку пользователя Б». Иногда на экран выводится имя и статус, а в JSON рядом приезжают телефон, email, сумма заказа, внутренний тег, комментарий менеджера и ссылка на документ. Интерфейс молчит, сеть говорит.

Архитектурные ограничения: лимиты баз данных и отсутствие контроля доступа

Бесплатный тариф — это не просто «меньше строк» или «меньше операций». Это другой контур ответственности. Платформа оставляет вам ровно столько управления, сколько считает достаточным для знакомства с продуктом. Для демонстрации этого может хватить. Для обработки реальных данных — далеко не всегда.

Лимиты сами по себе не являются уязвимостью. Ограничение на количество записей, операций, пользователей, запросов или workflow-единиц — нормальная часть тарифной модели. Проблема начинается, когда из-за лимитов разработчик начинает обходить архитектуру: складывает разные типы данных в одну таблицу, объединяет роли, убирает проверки «временно», кэширует лишнее на клиенте, делает одну универсальную страницу для всех пользователей и надеется, что визуальный фильтр всё разрулит.

Платформа при достижении лимита обычно ведёт себя согласно своим правилам: блокирует часть функций, просит обновить тариф, ограничивает публикацию, замедляет операции или перестаёт принимать новые данные — конкретика зависит от сервиса и плана. Не надо приписывать ей хаос без доказательств. Но надо понимать другое: когда проект упирается в потолок, команда принимает быстрые решения. А быстрые решения в no-code почти всегда касаются доступа и данных.

Самые неприятные ограничения обычно лежат не в объёме, а в контроле:

1. Гранулярные роли и права. В простом приложении есть «админ» и «пользователь». В живом бизнес-процессе нужны менеджер, руководитель, оператор, внешний партнёр, бухгалтер, клиент, временный подрядчик. Если тариф или платформа не дают выразить эти роли нормально, права начинают имитировать фильтрами и условной видимостью элементов.

2. Правила доступа на уровне данных. Хорошая защита отвечает на вопрос не «какую кнопку видит пользователь», а «какие строки и поля сервер вообще имеет право ему вернуть». В no-code это зависит от конкретной платформы, источника данных и способа подключения. Таблица, внешняя база, API, встроенная база конструктора — у каждого варианта свои границы.

3. Аудит действий. Кто экспортировал данные? Кто поменял роль? Кто удалил запись? Кто подключил новый плагин? Если на выбранном тарифе нет журналов или они слишком короткие и поверхностные, расследовать инцидент будет почти невозможно. Вы узнаете, что «что-то случилось», но не восстановите цепочку.

4. Серверная валидация. Клиентская форма может запретить неправильный ввод, но злоумышленник не обязан пользоваться вашей формой. Он может повторить запрос, изменить параметры, отправить неожиданные значения. Если платформа не позволяет настроить проверку на серверной стороне или в правилах источника данных, целостность держится на честности клиента.

5. Изоляция сред. Без разделения dev/staging/production легко протестировать новую логику на реальных данных. В no-code это особенно соблазнительно: открыл редактор, поправил условие, нажал publish. Через минуту пользователи уже живут с этой правкой.

Бесплатный тариф конструктора — это не «тот же продукт, только маленький». С точки зрения безопасности это часто другой набор рычагов, и некоторых рычагов у вас просто нет.

Отдельная тема — внешние источники вроде таблиц и подключённых баз. Многие no-code-приложения начинают жизнь с Google Sheets, Airtable или похожих сервисов, потому что это быстро и понятно. Но таблица как источник данных требует отдельной модели доступа: кто имеет доступ к самой таблице, как устроены API-ключи, можно ли ограничить поля, есть ли представления, как ротируются токены, что происходит при увольнении человека, который всё это подключал.

Если конструктор позволяет подключить внешний источник только в упрощённом режиме, без нормальной проекции данных и серверных правил, вы снова оказываетесь в ловушке клиентской фильтрации. Если позволяет глубже — отлично, но это надо проверять на вашем тарифе, а не в абстрактном описании продукта.

Методология OWASP для no-code: как избежать «слепого доверия» к платформе

OWASP Citizen Development Top 10 полезен не тем, что даёт очередную табличку угроз. Полезен он другим: заставляет перестать смотреть на no-code как на игрушечную разработку. Если приложение принимает решения, хранит данные и раздаёт доступы, у него есть полноценная поверхность атаки. Просто часть этой поверхности скрыта под визуальным редактором.

Account Impersonation — несанкционированное использование чужой учётной записи. Для no-code это особенно опасно, потому что аккаунт редактора часто имеет слишком много власти. Через него можно поменять источник данных, открыть страницу, подключить плагин, вытащить экспорт, опубликовать новую версию. Если нет 2FA, SSO, журналов и политики удаления доступа, всё держится на дисциплине людей. А дисциплина — плохой механизм безопасности, когда её нельзя проверить.

Sensitive Data Leakage — утечка чувствительных данных. Сюда попадает не только очевидная история «все записи приехали в браузер». Лишние поля в API-ответах, открытые вложения, предсказуемые ссылки, токены в local storage, публичные таблицы, неправильно настроенные интеграции — всё это один и тот же класс ошибки: данные доступны шире, чем предполагал автор приложения.

Blind Trust — слепое доверие к платформе и её экосистеме. «Платформа большая, значит, всё безопасно» — плохой аргумент. Большие платформы тоже ошибаются. Плагины тоже пишут люди. Шаблоны тоже могут быть собраны с удобством выше безопасности. Разница только в том, что в классической разработке вы можете открыть код зависимости, прогнать анализ, ограничить права, построить sandbox. В no-code вы часто видите только красивую карточку плагина и кнопку Install.

Business Logic Bypass — обход бизнес-логики. Визуальный сценарий может быть правильным для честного пользователя: нажал кнопку, прошёл шаги, получил результат. А атакующий меняет параметры запроса, пропускает шаг, подставляет чужой идентификатор, вызывает действие напрямую. Если правила проверяются только интерфейсом, бизнес-логика обходится не «взломом», а внимательностью.

Insecure Third-Party Integration — слабая интеграция со сторонними сервисами. No-code любит соединять всё со всем: формы, CRM, рассылки, платежи, таблицы, аналитика, чаты. Каждая интеграция добавляет секреты, вебхуки, токены, права и новые места хранения данных. На бесплатном тарифе вы можете не получить нормальных инструментов для ограничения прав или аудита этих связей.

Финансовые и крупные цифровые сервисы давно живут в логике, где защита данных — это не один переключатель, а набор процессов, ролей и технических барьеров. Даже такие традиционные институты, как цифровые финансовые сервисы ВТБ, вынуждены строить безопасность как постоянную практику, а не как раздел на лендинге. No-code-проект, который собирает реальные данные, не становится исключением только потому, что его собрали без кода.

Что проверить перед регистрацией на бесплатном тарифе

Я не люблю универсальные чек-листы, потому что ими часто заменяют мышление. Но перед регистрацией на бесплатном тарифе есть набор вопросов, которые лучше задать до того, как вы втянули в платформу команду и данные. Не в духе «поставить галочки», а руками: открыть документацию, создать тестовый проект, посмотреть сетевые ответы, проверить настройки.

1. Раздел Security и Compliance. Есть ли у платформы внятное описание безопасности: шифрование в транзите и в покое, регионы хранения, резервные копии, политика инцидентов, сертификации, обработка персональных данных. Важно не наличие красивых слов, а конкретика: что относится ко всей платформе, а что доступно только на отдельных планах.

2. 2FA для участников workspace. Можно ли включить двухфакторную аутентификацию для всех редакторов проекта. Не «каждый может сам», а именно принудительно. Если нельзя — зафиксируйте это как риск, особенно если в проекте будут подрядчики и временные участники.

3. SSO и управление пользователями. Поддерживается ли централизованный вход через корпоративный провайдер. На каком тарифе. Можно ли быстро отключить пользователя, посмотреть активные сессии, ограничить роли.

4. Права на уровне данных. Создайте двух тестовых пользователей и две группы записей. Настройте фильтры так, как планируете в реальном приложении. Затем проверьте Network: не приезжают ли чужие строки и лишние поля.

5. Секреты и токены. Посмотрите Local Storage, Session Storage, cookie и сетевые запросы. Никакие ключи, дающие прямой доступ к базе или внешнему API, не должны лежать в браузере как сувенир.

6. Доменная модель. Можно ли подключить собственный домен, настроить редиректы, убрать платформенный адрес из пользовательского сценария. Если нельзя — решите, допустимо ли это для ваших данных и аудитории.

7. Журналы и откаты. Есть ли история действий, публикаций, изменений прав, подключений интеграций. Можно ли понять, кто что сделал. Можно ли откатить ошибочную публикацию.

8. Плагины и шаблоны. Если приложение зависит от плагинов, выясните, какие права они получают и кто их поддерживает. Бесплатный плагин без прозрачной модели прав — не подарок, а неизвестная зависимость в контуре данных.

9. Экспорт и удаление данных. Как вы заберёте данные при миграции. Как удалите проект. Как удалите данные конкретного пользователя. Есть ли задержки, резервные копии, отдельные условия для вложений.

10. Поведение при росте. Какие лимиты есть на записи, пользователей, операции, storage, публикации, интеграции. Что происходит при достижении лимита: блокировка, просьба обновить тариф, ограничение функций. Это не столько вопрос производительности, сколько вопрос будущей миграции и архитектурных компромиссов.

Последний пункт особенно важен. Бесплатный тариф редко ломает проект в первый день. Он делает другое: приучает строить архитектуру вокруг ограничений. Через месяц эти ограничения становятся частью бизнес-процесса. Через полгода миграция уже болезненна, потому что данные расползлись по таблицам, роли нарезаны условностями, а пользователи привыкли к платформенному домену.

Позиция практика

Бесплатные тарифы no-code платформ — нормальный инструмент для обучения, прототипов и внутренних демонстраций. Было бы странно отрицать их пользу: они позволяют быстро проверить идею, собрать форму, показать сценарий, не заводя инфраструктуру и команду разработки. Проблема начинается там, где бесплатный тариф незаметно превращается в продакшн.

Скрытые условия бесплатных конструкторов приложений редко выглядят как прямой запрет «вам нельзя безопасно работать». Они звучат мягче: расширенные роли доступны выше, собственный домен позже, SSO в корпоративном плане, аудит в продвинутой версии, больше контроля после апгрейда. По отдельности это терпимо. Вместе это и есть профиль риска.

Если вы собираете прототип без реальных персональных данных — бесплатный тариф может быть разумным. Если подключаете клиентов, сотрудников, платежные статусы, документы, медицинские, финансовые или любые чувствительные сведения — сначала проверяйте безопасность конструктора приложений, а потом нажимайте Start Free. Не наоборот.

Экономия на тарифе сама по себе не грех. Грех — считать её архитектурным решением. В безопасности no-code нет магии: данные либо отрезаются на правильной стороне, доступ либо управляется централизованно, действия либо логируются, секреты либо спрятаны от клиента. Если бесплатный план не даёт этих вещей, он не становится плохим продуктом. Он просто не подходит для ваших данных.