Принимаем сайт у разработчика: 7 вопросов по безопасности

Вы заказали сайт у фрилансера или AI-разработчика, получили готовый проект и готовы оплатить работу. Но прежде чем переводить деньги и открывать доступ пользователям, стоит убедиться, что сайт не содержит критических уязвимостей. В этой статье мы разберем, как проверить работу разработчика сайта на безопасность, какие вопросы задать исполнителю и на что обратить внимание при приемке.

1. Где хранятся доступы и как они защищены?

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

2. Есть ли резервное копирование и как его восстановить?

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

3. Какие данные собирают формы на сайте?

Формы обратной связи, подписки, заказы — через них передаются персональные данные пользователей. Убедитесь, что данные шифруются при передаче (SSL-сертификат), хранятся в безопасности и не отправляются на сторонние серверы без вашего ведома. Спросите, куда именно уходят письма с формы, и проверьте, не дублируются ли они в открытом виде в логах.

4. Как настроены права доступа в админке?

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

5. Ведется ли логирование действий?

Логи — это записи о том, кто и когда заходил в админку, какие действия выполнял. Наличие логов помогает быстро найти причину проблемы, если сайт начал вести себя странно. Спросите, включено ли логирование, как долго хранятся записи и можно ли их просматривать. Если разработчик не знает, что такое логи, — это тревожный сигнал.

6. Какие уязвимости были найдены и устранены?

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

7. Что произойдет, если я захочу передать сайт другому специалисту?

Рано или поздно вам может понадобиться сменить разработчика. Убедитесь, что у вас есть полные доступы к хостингу, домену, исходному коду, базе данных и всем сервисам (почта, CDN, аналитика). Попросите разработчика предоставить инструкцию по передаче. Если он отказывается или говорит, что «это сложно», — это повод не платить полную сумму до решения вопроса.

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

5 ошибок vibe coding проектов, которые зря игнорируют

Когда сайт собирается за вечер с помощью нейросети, легко пропустить детали, которые стоят дорого. Речь не о дизайне или скорости — а о вещах, которые могут привести к утечке данных или взлому. Мы собрали самые частые ошибки vibe coding проектов, которые встречаются даже в работающих прототипах.

Доступы и секреты в коде

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

Что делать: выносите секреты в переменные окружения или используйте сервисы вроде Vault. Даже для MVP это должно быть правилом.

Формы без валидации и защиты

Формы обратной связи, подписки, заявки — классическая точка входа для атак. В vibe coding проектах часто забывают про серверную валидацию: AI генерирует красивую HTML-форму, но не проверяет данные на бэкенде. Это открывает путь для XSS, SQL-инъекций и спама.

Достаточно добавить базовую проверку типов полей, длину и экранирование спецсимволов. Не надейтесь только на клиентский JavaScript — он отключается за секунду.

Открытые API и отсутствие авторизации

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

Даже для внутренних API используйте простые ключи доступа или JWT. Не оставляйте эндпоинты «для теста» без защиты.

База данных с правами «на всех»

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

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

Логика доступа: кто что может делать

Даже если авторизация есть, часто путают роли. Например, обычный пользователь может случайно получить доступ к админ-панели через прямой URL. Или модератор — удалять чужие записи. В vibe coding проектах ролевая модель часто не продумана до конца.

Пропишите для каждого действия минимальный уровень доступа и проверяйте его на сервере. Не полагайтесь только на то, что кнопка скрыта в интерфейсе.

Как проверить свой проект за час

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

SafeVibe предлагает аудит по этому чек-листу типовых рисков vibe coding-проектов — чтобы вы могли запускаться с уверенностью, а не с надеждой.

Не сливайте ключи: как давать AI доступ к коду без риска

AI-ассистенты вроде ChatGPT и Claude прочно вошли в рабочий процесс разработчиков и владельцев цифровых проектов. Но вместе с удобством приходит и риск: случайно скопированный в промпт токен или строка подключения к базе данных могут оказаться в открытом доступе. В этой статье мы разберём, как безопасно давать ai доступ к коду, не подставляя свой проект и клиентов.

Почему AI-сервисы не заменяют политику безопасности

Ни один нейросетевой сервис не гарантирует полную конфиденциальность переданных данных. Даже если вы используете платную версию, провайдер может анализировать промпты для обучения модели. Поэтому первое правило: не передавать api ключи в chatgpt и другие AI-инструменты в открытом виде. Вместо этого создайте отдельный файл с переменными окружения (.env) и никогда не включайте его в запрос.

Секреты в коде: главные источники утечек

Чаще всего разработчики случайно передают в AI:

  • API-ключи и токены доступа к внешним сервисам;
  • пароли и строки подключения к базам данных;
  • приватные ключи шифрования;
  • персональные данные клиентов (имена, email, адреса);
  • коммерческую логику и алгоритмы, которые составляют конкурентное преимущество.

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

Как защитить .env и переменные окружения

Самый простой способ — использовать файл .env и не добавлять его в репозиторий. Проверьте, что он есть в .gitignore и токены в репозитории не появляются даже в старых коммитах. Если вы работаете с AI-ассистентом, скопируйте только публичную часть кода, а все чувствительные данные замените плейсхолдерами типа YOUR_API_KEY_HERE.

Практический чек-лист перед отправкой кода в AI

  1. Проверьте, нет ли в коде строк вида api_key = "sk-..." или password = "...".
  2. Убедитесь, что в запрос не попали файлы конфигурации продакшена.
  3. Если нужно показать пример данных — используйте синтетические тестовые данные, а не реальные записи из БД.
  4. Для работы с секретами используйте менеджеры паролей или сервисы вроде Vault — никогда не храните ключи в самом коде.
  5. После завершения сессии с AI очистите историю чата, если сервис сохраняет промпты.

Когда AI-разработка становится рискованной

Многие малые бизнесы и авторы каналов начинают с малого: просят AI написать скрипт для парсинга или интеграции. Но на этом этапе легко забыть про защиту env файла и случайно передать токен доступа к CRM или платёжному шлюзу. Последствия могут быть серьёзными: от утечки клиентской базы до финансовых потерь.

Если вы не уверены, что ваш процесс безопасен, стоит проконсультироваться со специалистами. Команда SafeVibe помогает настроить безопасный процесс AI-разработки и работу с секретами, чтобы вы могли пользоваться преимуществами нейросетей без страха за данные.

Итог

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

5 скрытых угроз работающего сайта

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

1. Инъекции и недоверенные данные

Даже если форма отправляет письмо, это не значит, что она защищена от SQL-инъекций или XSS. Злоумышленник может ввести в поле имя специальный код — и база данных окажется под угрозой. Ошибки безопасности в коде часто связаны с тем, что разработчик не фильтрует пользовательский ввод. Проверьте: все ли поля экранируют спецсимволы? Используются ли параметризованные запросы?

Как проверить?

  • Введите в поле имени: <script>alert('test')</script> — если появится всплывающее окно, сайт уязвим к XSS.
  • Попробуйте ввести ' OR 1=1 -- в поле логина — если авторизация пройдёт, есть SQL-инъекция.

2. Небезопасная логика авторизации

Админка открывается? Отлично. Но может ли её открыть любой пользователь, если угадает URL? Или если подменить параметр ?user_id=1? Скрытые уязвимости сайта часто прячутся в логике доступа. Например, после входа в личный кабинет пользователь может изменить чужой профиль, просто подставив другой ID в адресной строке.

Что делать?

  • Проверьте, что каждый запрос к API проверяет права текущего пользователя.
  • Убедитесь, что админ-панель недоступна по прямой ссылке без сессии.

3. Утечка данных через ошибки

Когда сайт падает, он может показывать стек вызовов, пути к файлам, версии библиотек. Это — золотая жила для атакующего. Безопасность веб приложения включает настройку обработки ошибок: в production все сообщения должны быть обезличены, а детали — записываться в лог.

Простой тест

Попробуйте ввести несуществующий URL или отправить некорректные данные в форму. Если увидите техническую информацию — срочно отключайте отладку.

4. Слабые настройки сервера и API

Сайт может работать, но его серверная часть — быть открытой для атак. Например, разрешён CORS с любого источника, не настроены заголовки безопасности, открыты ненужные порты. Проверка backend безопасности должна включать аудит HTTP-заголовков (Content-Security-Policy, X-Frame-Options, HSTS) и конфигурации веб-сервера.

5. Ошибки в логике бизнес-процессов

Иногда код технически корректен, но логика опасна. Например, при оформлении заказа можно изменить цену товара через POST-запрос, или скидка применяется несколько раз. Небезопасная логика сайта — это когда функция работает, но с нарушением намерений владельца. Проверьте: может ли пользователь получить товар без оплаты? Может ли создать бесконечное количество купонов?

Что в итоге?

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

Сайт через нейросеть: 7 шагов перед запуском

Вы потратили вечер, накидали промптов — и нейросеть выдала готовый лендинг, интернет-магазин или сервис. Красиво, быстро, дёшево. Но прежде чем нажимать «Опубликовать», стоит остановиться. Безопасность сайта сделанного через ai — это не паранойя, а минимальная ответственность перед пользователями, клиентами и законом. AI пишет код быстро, но он не проверяет, нет ли в нём дыр, уязвимых форм или открытых доступов к базе. Давайте разберёмся, что нужно проверить обязательно.

Почему AI-код нельзя запускать без проверки

Нейросеть не понимает контекст. Она генерирует то, что похоже на правильный код, но не гарантирует его безопасность. Типичные проблемы: незакрытые SQL-инъекции, открытые API-ключи прямо в коде, отсутствие валидации форм, слабая защита от XSS-атак. Всё это реальные уязвимости, которые могут стоить денег и репутации.

Шаг 1: Проверка кода на уязвимости

Откройте код, который сгенерировала нейросеть. Ищите жёстко прописанные пароли, токены, ключи API. Если видите const apiKey = 'sk-...'; — это красный флаг. Такие данные должны быть в переменных окружения, а не в теле скрипта. Также проверьте, как обрабатываются данные из форм: если они напрямую подставляются в SQL-запрос, сайт уязвим для инъекций.

Что делать

  • Используйте инструменты вроде OWASP ZAP или хотя бы ручной просмотр кода.
  • Проверьте, закрыты ли все внешние запросы (CORS, CSP).
  • Убедитесь, что нет открытых эндпоинтов без авторизации.

Шаг 2: Безопасность форм и пользовательских данных

Формы обратной связи, подписки, регистрации — через них часто утекают данные. AI может не добавить защиту от CSRF, не проверять длину поля, не экранировать ввод. Это прямой путь к компрометации базы. Проверьте, что все поля валидируются на сервере, а не только на клиенте.

Шаг 3: Настройка HTTPS и сертификатов

Если сайт принимает данные от пользователей, HTTPS обязателен. Без него все данные передаются открытым текстом. Нейросеть может не настроить автоматический редирект с HTTP на HTTPS. Проверьте это вручную или через сервис SSL Labs.

Шаг 4: Управление доступом и сессиями

Если на сайте есть личный кабинет или админка, убедитесь, что сессии и токены генерируются случайным образом, а не жёстко прописаны. AI часто ставит простые cookie или не устанавливает флаги HttpOnly и Secure. Это может позволить злоумышленнику украсть сессию через XSS.

Шаг 5: Проверка сторонних библиотек

Нейросеть может подключить библиотеки с известными уязвимостями. Проверьте все зависимости через npm audit, pip audit или аналоги. Устаревшая версия jQuery или React — это риск, который легко исправить.

Шаг 6: Тестирование на реальных сценариях

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

Шаг 7: Аудит перед публикацией

Перед тем как показывать сайт клиенту или запускать рекламу, сделайте хотя бы поверхностный аудит. Можно воспользоваться автоматическими сканерами или обратиться к специалистам. SafeVibe предлагает внешний аудит AI- и vibe-coded проектов: мы проверим код, доступы, формы и юридические риски, чтобы вы могли запускаться спокойно.

Что вы получите в итоге

  • Понимание, какие уязвимости есть в вашем AI-сайте.
  • Конкретные рекомендации по исправлению.
  • Спокойствие: вы знаете, что сайт не сольёт данные и не упадёт от первой атаки.

AI — отличный помощник для быстрого прототипирования, но безопасность сайта сделанного через ai остаётся вашей ответственностью. Не доверяйте коду слепо, проверяйте его, и ваш проект будет не только красивым, но и надёжным.