AIで作ったWebアプリのセキュリティチェック｜公開前に確認する8項目

1〜3：認証・権限・APIキー

1. ログインしていない人にデータを返さないか

保護する画面だけでなく、データの取得・更新APIやダウンロード処理にも認証が必要です。ログアウト後や利用停止後にアクセスできないかも、テスト用アカウントで確認します。

2. 別の利用者や組織の情報を取得できないか

ログイン済みの人にも、扱えるデータの範囲があります。担当者・管理者・社外利用者などの役割と、個々のデータへのアクセス権限を確かめます。ボタンを非表示にするだけでは、サーバー側の権限確認にはなりません。

3. APIキーを公開コードに残していないか

APIキーやDBの認証情報が、ブラウザーへ配信するコード、Git履歴、ログ、共有ファイルに残っていないか確認します。公開された可能性がある秘密情報は、文字を消すだけで終えず、失効・再発行と影響確認が必要です。

4〜6：データベース・入力値・通信

4. データベースの公開範囲と接続権限

DBを誰が、どこから利用できるかを確認します。アプリに必要な操作と管理用の操作は分け、検証時の広い権限が残っていないかを見ます。添付ファイルの保存先も、同じように公開範囲を確認します。

5. 入力をサーバー側で検証しているか

文字数、形式、ファイルの種類・サイズなどを、サーバー側でも検証します。DB操作には適切なパラメーター化を行い、表示時には文脈に合った出力処理を使います。入力チェックだけで、すべての攻撃を防げるわけではありません。

6. HTTPSと外部からの接続設定

ログインやデータ通信がHTTPSになっているか、Cookieの属性や接続先の許可設定が適切かを確認します。CORSはブラウザーの制約であり、APIの認証・権限確認を置き換えるものではありません。

7〜8：エラー・ログ・公開後の運用

7. エラー画面やログに情報を出し過ぎないか

利用者へ返すエラーに、内部の接続情報や秘密情報が含まれていないか確認します。運用ログには原因を調べるための情報を残しつつ、パスワードやAPIキーなどは記録しない設計にします。ログ自体の閲覧権限も必要です。

8. 公開後に変更を確認する担当がいるか

ライブラリの更新、アクセス権限の見直し、障害時の連絡、バックアップの管理を誰が行うか決めます。一度確認したシステムも、コードや設定の変更によって状態が変わります。公開時点の確認範囲と、後で確認する項目を残しましょう。

セキュリティチェックと専門的な脆弱性診断を分ける

コードや設定のレビュー、ツールによる脆弱性診断、攻撃を模したペネトレーションテストは、目的も作業範囲も異なります。依頼時は、名称だけで判断せず、対象URL、確認方法、対象外の項目、修正の有無、成果物を具体的にすり合わせることが大切です。

N2iの公開支援では、現在のコードとインフラ設定をもとに、認証・権限・秘密情報・公開範囲などを確認し、必要な作業を整理します。専門的な診断やペネトレーションテストの対応可否は、相談時に個別に確認します。すべての脆弱性の検出や、情報漏洩の完全な防止を保証するものではありません。

8項目を、公開判断に使える確認記録へ落とし込む

チェックリストに丸を付けるだけでは、実際にどこまで安全性を確認したかが伝わりません。対象の機能、確認方法、期待する結果、実際の結果、担当者を一行ずつ記録すると、未対応の箇所を判断しやすくなります。設定を読んで確認した項目と、テストで挙動を確認した項目も区別しましょう。

検証は、自社が管理して検証を許可した環境で行い、ダミーデータを使います。負荷の高い試験や破壊的な操作は、通常の動作確認とは別に範囲を決めます。確認のために他社のシステムや、許可されていない環境へアクセスしてはいけません。

結果は「対応済み」「未対応」「未確認」に分け、未対応・未確認の項目は業務への影響と対応予定を記載します。たとえば利用者を限定して公開する場合も、認証や個人情報のアクセス制御を省いてよい理由にはなりません。公開範囲と、公開を判断する責任者を具体的に決めます。

AIで修正した後も、変更した範囲を確認する

AIへ修正を依頼すると、意図した機能以外のコードや設定が変わる場合があります。修正前後の差分を確認し、認証の処理が外れていないか、権限チェックが別の経路で抜けていないかを見ます。画面が正常に開くことに加え、拒否されるべき操作が引き続き拒否されるかも重要です。

修正後に秘密情報を追加した場合は、保存先と公開される範囲を確認します。開発環境でだけ必要な機能は本番から切り離し、本番用の設定で動かした結果を残します。確認したコードと公開したコードが違う状態にならないよう、どの版を検証したかも記録しましょう。

エラーが出なくなれば、公開して大丈夫ですか？

エラーがないことは操作が動く証拠にはなりますが、権限や秘密情報の管理まで確認した証拠にはなりません。正常な操作と、禁止したい操作を分けてテストする必要があります。

8項目を確認すれば、追加の診断は不要ですか？

扱うデータ、利用者数、外部公開の範囲、契約上の要件によって必要な確認は変わります。この記事は公開前の会話を始めるための観点です。追加の専門診断が必要な場合は、対象や方法を個別にすり合わせてください。

相談前は「作ったもの」と「不安」をまとめる

アプリの用途、使った開発ツール、扱うデータの種類、公開予定の利用者、現在のサーバー構成が分かると、確認範囲を決めやすくなります。完成していなくても、状況が分かる画面や説明から相談できます。

N2iでは初回30分の無料相談と、コード共有前のNDAに対応しています。APIキー・パスワード・実際の顧客データを初回予約フォームへ貼り付ける必要はありません。作業費は、システムの規模と対応範囲に応じた個別見積もりです。

参考・関連資料

• OWASP｜Authorization Cheat Sheet ↗
• OWASP｜Secrets Management Cheat Sheet ↗
• OWASP｜Input Validation Cheat Sheet ↗

本記事はN2iが開発・公開支援の観点からまとめた解説です。記載した業務例・表は説明用で、特定の顧客案件を紹介するものではありません。公式資料は2026年10月9日に確認しました。個別の対応範囲は、システムの構成に応じて確認します。