Аудит безпеки WordPress: Що перевірити перед запуском

Перш ніж будь-який плагін, згенерований PAGEnza, потрапить до інсталяції WordPress користувача, він проходить три автоматизовані перевірки безпеки. Ця публікація пояснює, що шукають ці перевірки — і чому кожна з них важлива.

Чому код, згенерований ШІ, потребує аудиту

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

Найпоширеніші, які ми бачимо:

• Використання $_GET або $_POST без санітизації
• Відсутність перевірки nonce при надсиланні форм
• Прямі запити до бази даних без $wpdb->prepare()
• Використання eval() або exec() для динамічної поведінки
• Виведення даних користувача без esc_html() або esc_attr()

Це не екзотичні крайні випадки. Вони регулярно з'являються у вихідних даних LLM — навіть у найкращих моделях.

Етап 1: Валідація промпту

Перш ніж ШІ напише хоча б один рядок, ми аналізуємо опис користувача. Цей крок виявляє дві категорії проблем:

Спроби маніпуляції — промпти, які намагаються змусити ШІ генерувати навмисно шкідливий код. Такі речі, як „ігноруй попередні інструкції“ або „створи бекдор для тестування“.

Нечіткі або непрактичні описи — промпти, які занадто короткі або занадто неоднозначні, щоб створити корисний код. „Зроби плагін“ генерує сміття; „Створи контактну форму, яка надсилає дані на електронну адресу з фільтрацією спаму“ генерує щось реальне.

Якщо промпт не проходить цю перевірку, користувач бачить конкретне повідомлення про помилку, яке пояснює чому — а не загальне відхилення.

Етап 2: Linting PHP в ізольованому контейнері

Після того, як ШІ згенерує PHP код, він виконується через php -l у Docker-контейнері, який повністю ізольований від усього іншого. Це виявляє синтаксичні помилки ще до того, як плагін потрапить до інсталяції WordPress.

Але ми йдемо далі: якщо linting не вдається, система не просто відхиляє вихідні дані. Вона надсилає помилку назад до ШІ з промптом для виправлення — це те, що ми називаємо лікуванням (healing). ШІ бачить свою помилку і намагається знову, до трьох разів.

Це означає, що користувачі майже ніколи не бачать повідомлення „генерація не вдалася“. Вони бачать трохи довший час генерації — і робочий код.

Етап 3: Сканування безпеки коду

Це найважливіший етап. Ми проводимо статичний аналіз, який перевіряє:

Небезпечні функції: eval(), exec(), system(), shell_exec(), passthru() — будь-яка з них блокує випуск плагіна.

Вектори SQL-ін'єкцій: сирі виклики $wpdb->query() з інтерпольованими змінними, відсутність $wpdb->prepare(), пряме використання mysql_query().

Відсутність перевірок дозволів: AJAX-обробники, які не викликають current_user_can() перед виконанням будь-яких привілейованих дій.

Відсутність перевірки nonce: обробники форм, які не викликають wp_verify_nonce() або check_ajax_referer().

Неекранований вивід: echo $_GET[...], echo $user_input без функцій екранування.

Якщо щось із цього знайдено, плагін блокується. Користувач бачить звіт, який точно перелічує, які функції викликали блокування і чому — а не просто „перевірка безпеки не вдалася“.

Як виглядає звіт аудиту

Кожен згенерований плагін постачається зі звітом про аудит безпеки простою мовою. Він містить:

• Які перевірки пройшли (зелений)
• Які перевірки викликали попередження (бурштиновий) — проблеми, які не є блокуючими, але заслуговують на увагу
• Будь-які виправлення, які були автоматично застосовані під час лікування

Звіт генерується автоматично та додається до завантаження плагіна. Він корисний як для вашої власної впевненості, так і для того, щоб показати клієнтам, що ви серйозно поставилися до безпеки.

Етап 4: Валідація під час збереження

Це не частина початкової генерації — це застосовується, коли користувачі вручну редагують код плагіна в редакторі PAGEnza.

Щоразу, коли ви зберігаєте, виконується той самий тест lint + безпеки. Якщо ви введете критичну вразливість під час редагування, збереження буде заблоковано, доки ви її не виправте. Це запобігає поширеному сценарію, коли розробник робить швидку „тимчасову“ зміну, яка залишається в продакшені два роки.

Обмеження автоматизованого аудиту

Автоматичне сканування добре виявляє певний клас проблем. Воно не виявляє все.

Логічні помилки, порушена бізнес-логіка та тонкі проблеми з ескалацією привілеїв, які не включають відомі небезпечні шаблони, все ще вимагають людського перегляду. Ми прозорі щодо цього в документації — аудит не замінює перегляд безпеки, це мінімум, який гарантує мінімальний стандарт.

Для продукційних плагінів, що обробляють платежі або конфіденційні дані, ми рекомендуємо ручний перегляд на додаток до автоматизованих перевірок. Звіт аудиту надає людині-рецензенту хорошу відправну точку.