AIで作ったサイトの公開前チェック｜認証・APIキー・フォーム

AIで画面や機能を作れるようになっても、動くことと安全に公開できることの確認は別に必要です。特に会員情報、管理画面、外部サービスのAPI、問い合わせフォームがあるサイトでは、公開前にデータの流れとアクセス権限を整理します。

このガイドは、サイトの所有者や開発担当者が自分の管理する環境を点検するための入口です。項目にチェックが付いても、すべての脆弱性がないことを保証するものではありません。

ログインと、操作できる範囲

ログインできるかに加え、その利用者が何を見たり変更したりしてよいかを確認します。ボタンを隠すだけでは、サーバー側の権限確認にはなりません。

• ログアウトした状態で、管理画面や会員データを取得できないか。
• 一般利用者が管理者向けの操作を実行できないか。
• 自分が用意した別のテストアカウントのデータを表示・変更できないか。
• 退会・権限変更・ログアウト後に、不要なアクセスが残らないか。

確認にはテスト用アカウントとダミーデータを使います。別の利用者や第三者のシステムを無断で試験対象にしないでください。

APIキーと秘密情報

APIキーや管理用トークンは、ブラウザへ配信するJavaScript、公開リポジトリ、エラー画面に含めないよう確認します。サーバー側の環境変数も、必要な処理からだけ使う設計にします。

権限を必要な範囲に絞り、開発用と本番用を分け、変更できる担当者を決めます。漏えいが分かったキーは、画面から消すだけでなく、失効・再発行と利用履歴の確認が必要です。

公開してよいデータだけか

ストレージの画像・PDF、データベース、検索用インデックス、バックアップ、ログを確認します。管理画面から見えないファイルでも、共有URLや公開設定でアクセスできる場合があります。

公開する資料と社内資料を分け、公開設定を誰が変更できるかを決めてください。フォームの入力内容や認証情報が、アクセス解析やエラー通知へ不用意に送られないことも確認します。

フォームは、送信から通知まで試す

お問い合わせフォームは、入力画面の見た目だけで判断しません。実際の利用端末で、未入力・入力誤り・送信中・送信失敗・正常完了を確認します。

• スマートフォンでボタンが押せて、入力に応じた案内が出る。
• 不正な入力をサーバー側でも拒否する。
• 二重送信や連続送信への対策がある。
• 通知先にメールが届き、失敗時に気付ける。
• 完了画面で、受付後の流れが分かる。

迷惑送信対策を入れた場合は、認証が読み込めないときにも、利用者が理由と再試行方法を確認できるかを試します。

公開後の担当を決める

公開時の確認だけでなく、依存ライブラリの更新、アカウント管理、障害通知、バックアップと復旧の担当を決めます。外部サービスを使う場合は、利用上限や費用の通知先も確認します。

OWASP Top 10は、代表的なWebアプリケーションのリスクを整理した資料です。個別サイトの診断結果や、安全性を認定する仕組みではありません。扱う情報や機能に合わせて点検範囲を決めます。

確認結果を、次の対応につなげる

項目	自分の環境での確認方法	問題があった場合の対応
認証・権限	ログアウト状態と権限の異なるテスト利用者で、画面・API双方を確認	サーバー側の権限判定を修正して同じ条件で再試験
秘密情報	配信ファイル、リポジトリ、エラー表示を確認	露出した認証情報の失効・再発行と、利用履歴の確認
公開データ	共有設定とログアウト状態でのファイルアクセスを確認	公開範囲を修正し、必要なファイルだけ再公開
フォーム	スマートフォンで失敗・再試行・成功を試し、通知先と照合	ボタン、検証処理、認証、通知のどこで止まるかを切り分け
運用	障害通知先と復旧手順を担当者が確認	担当者・連絡先・手順を決め、テスト環境で確認

確認できなかった項目は「問題なし」にせず、未確認として残します。対象URL、条件、起きたこと、再現手順を記録すると、修正と再チェックが進めやすくなります。

よしなに診断のプランごとに確認対象が異なります。診断結果の指摘リストと、修正作業・再チェックの契約範囲は依頼前に分けて確認してください。

確認を依頼するときに用意するもの

公開予定URL、主な機能、ログインの有無、扱うデータの種類、利用サービス、公開希望日をまとめます。テスト環境の有無と、どこまで検査してよいかも共有します。問い合わせ本文に秘密鍵や本番パスワードを記載する必要はありません。

YOSHINANIのよしなに診断は、AIで作ったサイトやアプリの公開前点検を行い、重大度を付けた指摘リストをお渡しします。プランごとの対象・納期を確認のうえ、未確認の箇所を相談できます。