WordPressセキュリティ監査：公開前のチェックリスト

PAGEnzaによって生成されたプラグインがユーザーのWordPressインストールに到達する前に、3つの自動セキュリティチェックを通過します。この記事では、これらのチェックが何を検索し、なぜそれぞれが重要なのかを説明します。

AI生成コードが監査を必要とする理由

大規模言語モデルは、WordPressプラグインの作成に驚くほど長けています。フック名を知っており、WPのコーディング標準を理解し、読みやすいPHPを生成します。しかし、予測可能な間違いも犯します。そして、それらの間違いはセキュリティ上の脆弱性となります。

私たちがよく目にするもの:

• サニタイズなしでの$_GETまたは$_POSTの使用
• フォーム送信時のnonce検証の欠落
• $wpdb->prepare()なしでの直接データベースクエリ
• 動的な動作のためのeval()またはexec()の使用
• esc_html()またはesc_attr()なしでのユーザーデータの出力

これらはエキゾチックなエッジケースではありません。それらはLLMの出力に定期的に現れます — 最高モデルからでもです。

ステージ1：プロンプト検証

AIが一行書く前に、ユーザーの説明を分析します。このステップは2つのカテゴリの問題を捉えます：

操作の試み — AIに意図的に悪意のあるコードを生成させようとするプロンプト。「以前の指示を無視する」や「テスト用にバックドアを作成する」など。

曖昧または実行不可能な説明 — 有用なコードを生成するには短すぎるか、曖昧すぎるプロンプト。「プラグインを作成する」はゴミを生成します。「スパムフィルタリング付きのメールアドレスに送信する連絡フォームを作成する」は実際のものを生成します。

プロンプトがこのチェックに失敗した場合、ユーザーは一般的な拒否ではなく、その理由を説明する具体的なエラーメッセージを見ます。

ステージ2：隔離されたコンテナでのPHP linting

AIがPHPコードを生成すると、それは完全に隔離されたDockerコンテナ内でphp -lを通じて実行されます。これにより、プラグインがWordPressインストールに到達する前に構文エラーがキャッチされます。

しかし、私たちはさらに進みます：lintingが失敗した場合、システムは単に出力を拒否するだけではありません。エラーを修正プロンプトと共にAIに送り返します — これを**ヒーリング（healing）**と呼びます。AIは自身の誤りを見て、最大3回まで再試行します。

これは、ユーザーが「生成失敗」メッセージをほとんど見ないことを意味します。彼らは少し長い生成時間 — そして動作するコードを見ます。

ステージ3：コードセキュリティスキャン

これが最も重要なステージです。静的解析を実行し、以下をチェックします：

危険な関数: eval(), exec(), system(), shell_exec(), passthru() — これらはいずれもプラグインのリリースをブロックします。

SQLインジェクションベクトル: インタープリタ変数を使用した生の$wpdb->query()呼び出し、$wpdb->prepare()の欠落、mysql_query()の直接使用。

権限チェックの欠落: 特権的なアクションを実行する前にcurrent_user_can()を呼び出さないAJAXハンドラ。

Nonce検証の欠落: wp_verify_nonce()またはcheck_ajax_referer()を呼び出さないフォームプロセッサ。

エスケープされていない出力: echo $_GET[...], エスケープ関数なしのecho $user_input。

これらが見つかった場合、プラグインはブロックされます。ユーザーは、どの関数がブロックを引き起こしたか、そしてなぜかを正確にリストするレポートを見ます — 単なる「セキュリティチェック失敗」ではありません。

監査レポートの外観

生成された各プラグインには、平易な言葉でのセキュリティ監査レポートが付属しています。それはリストします：

• 合格したチェック（緑）
• 警告を引き起こしたチェック（アンバー）— ブロックではないが注意が必要な問題
• ヒーリング中に自動的に適用された修正

レポートは自動的に生成され、プラグインのダウンロードに添付されます。これは、あなたの自信のためにも、顧客にあなたがセキュリティを真剣に受け止めたことを示すためにも役立ちます。

ステージ4：保存時の検証

これは初期生成の一部ではありません — ユーザーがPAGEnzaエディタでプラグインコードを手動で編集する場合に適用されます。

保存するたびに、同じlint +セキュリティスキャンが再度実行されます。編集中に重大な脆弱性を導入した場合、それを修正するまで保存はブロックされます。これにより、開発者が迅速な「一時的な」変更を行い、それが2年間本番環境に残るという一般的なシナリオが回避されます。

自動監査の限界

自動スキャンは、特定のクラスの問題をうまく捉えます。すべてを捉えるわけではありません。

論理エラー、壊れたビジネスロジック、および既知の危険なパターンを含まない微妙な権限昇格の問題は、依然として人間のレビューが必要です。私たちはドキュメントでこれについて透明性を持っています — 監査はセキュリティレビューの代わりではなく、最低基準を保証するものです。

支払いまたは機密データを処理する本番プラグインの場合、自動チェックに加えて手動レビューを推奨します。監査レポートは、人間のレビュー担当者に良い出発点を提供します。