Защитить PHP-проект после вайбкодинга можно, если проверить его входные данные, доступ к базе, авторизацию, зависимости и настройки сервера, а затем повторить проверку после каждого заметного изменения. ИИ ускоряет разработку, но его код всё равно нуждается в ревью и тестах. Ниже — порядок действий для владельца небольшого сайта или внутреннего инструмента: как найти рискованные места, что проверить в первую очередь и когда подключить разработчика по безопасности.
Почему PHP-проект после вайбкодинга нужно проверять отдельно?
ИИ-агент может написать код, запустить тесты, подключить базу и даже развернуть приложение. Но успешный запуск не доказывает, что сайт безопасен: тесты подтверждают ожидаемое поведение, а не обязательно проверяют, что произойдёт при специально подготовленном вводе.
Особенно внимательно проверьте страницы входа, формы обратной связи, поиск, загрузку файлов и административную часть. Там приложение принимает данные от пользователя или выполняет действия с повышенными правами. Например, форма может показывать правильное сообщение при обычном тексте, но неверно обработать кавычки или неожиданный путь к файлу.
Начните с карты проекта: запишите, какие страницы доступны без входа, где пользователь меняет данные и какие действия доступны администратору. Для более полной проверки используйте чек-лист security review вайбкодинг-проекта.
Что проверить в коде PHP в первую очередь?
Сначала ищите места, где приложение получает данные извне и передаёт их дальше: в SQL-запрос, HTML-страницу, команду или файловую операцию. Не доверяйте значению только потому, что его отправила форма вашего сайта. Пользователь может изменить запрос вручную.
- SQL-запросы. Проверьте, что приложение использует подготовленные запросы с параметрами, а не собирает SQL из строки, введённой пользователем. Поиск по проекту по запросам к базе поможет составить перечень мест для ревью.
- Вывод в HTML. Значения, которые ввёл пользователь или вернула база, нужно безопасно экранировать перед показом на странице. Проверьте комментарии, подписи профиля и результаты поиска.
- Загрузка файлов. Ограничьте типы и размер файлов, задавайте имена на стороне сервера и не позволяйте запускать загруженный файл как PHP-скрипт. Проверьте также, куда именно приложение сохраняет файл.
- Авторизация. Убедитесь, что сервер проверяет права при каждом действии. Скрытая кнопка в интерфейсе не защищает страницу, если запрос можно отправить напрямую.
- Ошибки и секреты. Не показывайте посетителям трассировки ошибок и конфигурацию сервера. Пароли и ключи не должны попадать в публичный код, репозиторий или журналы приложения.
Проверяйте не только файлы PHP. Настройки веб-сервера, подключённые библиотеки и конфигурация окружения тоже влияют на защиту проекта.
Как проверять исправления, не полагаясь на ответ ИИ?
Просите агента объяснить, какие файлы он изменил, откуда приходят данные и как приложение проверяет права. Затем просмотрите эти места сами или передайте их разработчику. Просьба «проверь безопасность» слишком общая: задайте конкретную задачу, например проверить SQL-запросы и обработку загрузки файлов.
Для каждой найденной проблемы заведите тест, который воспроизводит её до исправления и проходит после. Проверяйте обычный сценарий и попытку выйти за его границы: например, открыть чужую запись, подставить неожиданный символ или передать файл с неподходящим расширением. Набор тестов пользовательских сценариев можно дополнить по инструкции по добавлению тестов в вайбкодинг-проект.
Если агент умеет запускать команды и работать с инструментами, задайте ему последовательность: сначала анализ, затем изменение, после этого тесты и короткий отчёт по результатам. Такой маршрут работы можно закрепить в скилле. Однако итоговые изменения всё равно стоит просмотреть: автоматический помощник может пропустить проблему или ошибочно объявить проверку успешной.
Какие типичные ошибки мешают защите?
- Считать, что отсутствие ошибок на главной странице означает безопасность всего сайта.
- Проверять код только по текстовому объяснению агента, не запуская тесты и не просматривая изменения.
- Ограничивать доступ только в интерфейсе, не проверяя серверную обработку запросов.
- Исправить одну форму и забыть о похожих местах, где данные проходят тем же путём.
- Внести правку прямо на работающем сайте, не проверив её сначала на копии проекта.
- Отключить сообщения об ошибках для посетителей, но оставить секреты и подробные ошибки в общедоступных журналах.
После проверки сохраните список уязвимых участков и принятых решений. При следующем изменении формы или авторизации этот список подскажет, какие тесты запустить повторно.
Начните с карты страниц и действий, затем проверьте обработку ввода, права доступа и настройки файлов. После исправлений запустите тесты на обычные и некорректные запросы. Если проект принимает платежи, хранит важные данные или уже подвергался атаке, перед публикацией передайте код и конфигурацию на независимое ревью.
