最初に確認する2つのURLと、合否の目安

最初に確かめるのは、自社サイトの /.git/HEAD と /.env です。.git/HEAD はGitの管理フォルダに必ずある1行のファイルで、.gitフォルダが外から見えるかの目印になります。example.com を自社のドメインに置き換え、ターミナルで次のコマンドを実行します。

curl -I https://example.com/.git/HEAD
curl -I https://example.com/.env

# 出力の例(1行目の数字が応答コード)
HTTP/2 404
content-type: text/html

結果は、1行目の数字で次のように読みます。

• 404か403: その場所からは読めません。別の場所と入口は、後の章で確かめます。
• 200: ブラウザで同じURLを開いて中身を見ます。ref: refs/heads/main のような1行や、APP_KEY= などの行が並べば公開中です。
• 301や302: 別のURLへの転送です。curl -IL で転送先までたどり、最後の数字で判断します。

.gitと.envが公開される3つの経路

.gitや.envがURLで読めるのは、Webサーバーが外に配る「公開ディレクトリ」(ドキュメントルート)の中に置かれているからです。公開ディレクトリの外にあるファイルには、URLでは届きません。中に入り込む経路は、主に次の3つです。

1. プロジェクトの直下を公開している: 本来は public などの下位フォルダだけを公開する構成で、プロジェクト全体を公開している状態です。Laravelの公式文書も、プロジェクトの直下から配信すると多くの機密設定ファイルが公開されると注意しています。
2. 公開ディレクトリでGitを使う: 公開ディレクトリの中で git clone や git pull を実行して運用すると、.gitフォルダがそのまま残ります。FTPでプロジェクトのフォルダごとアップロードした時や、WordPressのテーマを開発フォルダのまま置いた時も同じです。
3. バックアップと作業ファイルを残す: 移行作業で作ったzipやデータベースのダンプ、サーバー上の編集で生まれた wp-config.php.bak などの控えが残るケースです。エディターが自動で作る、名前が ~ で終わるファイルや .swp も含みます。

公開されると何が読まれるか

.gitフォルダが読めると、ソースコードと変更の履歴が外に出ます。.envが読めると、書かれた鍵とパスワードがそのまま外に出ます。どちらも、一度読まれた値は相手の手元に残り、後から取り消せません。

.gitフォルダから読まれるもの

• ソースコード一式と変更の履歴。今は消したファイルや、過去に一度コミットしたパスワードも履歴に残ります。
• .git/config に書かれた接続先のURL。Gitの公式文書のとおり、URLには ユーザー名:パスワード@ の形で認証情報を書けます。トークン入りのURLで clone していると、その値も読まれます。
• コミットした人の名前とメールアドレス、ブランチ名など、開発体制の手がかり。

.envから読まれるもの

.envは、フレームワークやアプリが起動時に読み込む設定ファイルです。データベースの接続先とパスワード、決済、メール配信、クラウドのAPIキー、Laravelの APP_KEY のような暗号鍵が並ぶのが一般的です。.envが読まれた時点で、書かれていた値はすべて漏洩したものとして扱います。

.gitと.env以外にも、公開ディレクトリに残りやすいファイルがあります。主な例は次の表のとおりです。

自分のサイトで公開を確認する手順と、見落としやすい場所

確認は、ブラウザで中身を見る方法と、curlで応答コードを並べる方法を組み合わせます。見落としやすいのは、下位フォルダ、別のホスト名、HTTPの側、CDNの裏のサーバーです。

ブラウザで中身を見る

アドレス欄に https://example.com/.git/HEAD を入れて開きます。ref: refs/heads/main のような1行が出れば、.gitフォルダは公開中です。.env で KEY=値 の行が並んだ場合も同じで、表示された値は画面共有やスクリーンショットで広げないようにします。

curlで応答コードとサイズを並べる

候補をまとめて確かめるなら、応答コードと受け取ったバイト数を1行ずつ並べます。サイズがすべて同じなら、同じエラーページかトップページが返っている目安です。macOSやLinuxのターミナル、WindowsならGit BashかWSLで動きます。

for p in /.git/HEAD /.git/config /.env /.env.production /wp-config.php.bak; do
  printf '%-22s ' "$p"
  curl -s -o /dev/null -w '%{http_code} %{size_download}B' "https://example.com$p"
  echo
done

# 出力の例
/.git/HEAD             404 153B
/.env                  404 153B

見落としやすい場所と入口

トップの /.git/HEAD が404でも、別の場所や入口から読めることがあります。次の4つも確かめます。

• 下位フォルダ: /blog/.git/HEAD や /wp-content/themes/テーマ名/.git/HEAD など、Gitで管理していたフォルダの直下。
• 別のホスト名: www の有無、stg. や dev. などの検証環境、使わなくなった旧ドメイン。
• HTTPとHTTPS: サーバーの設定が別々で、片方だけに拒否の設定が入っていることがあります。
• CDNの裏のサーバー: CDNやWAFで止めていても、元のサーバー(オリジン)にIPアドレスで届くと、その遮断を通りません。

# ホスト名と、HTTP、HTTPSの組み合わせを確かめる
for s in http https; do
  for h in example.com www.example.com; do
    printf '%-5s %-18s ' "$s" "$h"
    curl -s -o /dev/null -w '%{http_code}' "$s://$h/.env"; echo
  done
done

# CDNを通さず、オリジン(例: 203.0.113.10)へ直接確かめる
curl -sI --resolve example.com:443:203.0.113.10 https://example.com/.env | head -n 1

候補を1つずつ試す手間を省くなら、自社の無料ツール「Webサイトのセキュリティチェック」も使えます。対象は、.git、.svn、.env、wp-config.phpの控え、SQLダンプ、バックアップの圧縮ファイルです。ページの取得(GET、HEAD、OPTIONS)だけで確かめ、診断できるのは自社または管理権限のあるサイトに限られます。

200、403、404の読み方と、404でも安全と言い切れない理由

応答コードは「その場所から読めるか」を示すだけで、安全の証明ではありません。200は中身を見るまで判断できず、404は確かめた経路の結果でしかないからです。

表の「ソフト404」はGoogleの用語で、存在しないページにも200を返す状態を指します。迷った時は、次の図の順にたどります。

404でも安全と言い切れない4つの理由

1. 確かめた経路の結果でしかない: 前の章の下位フォルダ、別のホスト名、HTTP、オリジンは、それぞれ別に確かめる必要があります。
2. 過去の公開は分からない: 今日の404は、昨日まで読めなかった証明になりません。過去の公開は、アクセスログで確かめます。
3. HEADとGETで応答が違う場合がある: HTTPの仕様(RFC 9110)は、HEADにGETと同じヘッダーを返すことを『SHOULD』(推奨)にとどめています。curl -I が404や405でも、-I を外したGETでも確かめます。
4. 拒否が一部のファイルにしか効いていない: 設定の書き方によっては、/.env は403でも /.git/HEAD は200のまま、という状態が起きます。実例は、後の章のApacheの表に載せています。

他人のサイトを調べてはいけない理由

他人のサイトに .git や .env があるかを、管理者の許可なく確かめるのはやめてください。見つけた値を使えば法律に触れるおそれがあり、URLを試すこと自体も、相手のログには攻撃の下調べと同じ形で残ります。主な論点は次の3つです。

• 不正アクセス禁止法: 警察庁の解説によると、「不正アクセス行為」には2つの類型があります。他人のIDやパスワードを無断で入力して利用制限を外す行為と、設定ミスなどの不備を突いて制限を免れる行為です。.envで見つけたパスワードでデータベースや管理画面に入れば、これに当たるおそれがあります。
• 取得、保管、提供: 不正アクセスに使う目的で他人のIDやパスワードを取得、保管することや、正当な理由なく人に渡すことも禁じられています。同じ解説は、検索中にたまたま表示された場合は、取得の罪に当たらないとも説明しています。
• 試し方と負荷: IPAなどが定める情報セキュリティ早期警戒パートナーシップガイドラインは、URLの数字を積極的に多数変えて試す行為を例に挙げています。こうした行為は、制限を免れる目的とみなされる可能性があるという説明です。故意にサーバーの性能を落とす行為は、業務妨害罪に触れる可能性があるとも述べています。

同ガイドラインは、IPAが届出を受け付けても、発見の方法についての法的な責任は免除されないと明記しています。善意の確認であっても、許可の無い調査は自分を守る根拠になりません。

漏洩が見つかった時の対処: 優先順位つきの7手順

公開を見つけたら、すでに読まれた前提で、公開の停止、鍵の作り直し、ログの調査の順に進めます。1と2を最優先で終え、調査と連絡はその後に回します。

1. 公開を止めるファイルやフォルダを公開ディレクトリの外へ移すか、後の章の拒否の設定を入れ、URLが404か403になったことを確かめます。消す前に、書かれていた値の一覧と、ファイルの更新日時を控えます。アクセスログは調査に使うので、消さずに残してください。
2. 鍵とパスワードを失効させ、作り直す書かれていた値は、使っていないものも含めてすべて対象です。.gitが公開されていた場合は、履歴の全期間に一度でもコミットされた値まで含めます。新しい値は、公開ディレクトリの外にある設定に入れてから切り替えます。
3. アクセスログで読まれたかを調べる該当URLに、いつ、どのIPアドレスへ、何バイトを返したかを確かめます。コマンドの例は、この手順の下に載せています。
4. 不正利用の跡を調べるデータベースへの見知らぬ接続や操作、管理画面の不明なアカウント、クラウドやAPIの請求額、メールの送信履歴を確かめます。
5. Git履歴から取り除くリポジトリに秘密の値が入っていた場合は、履歴からも取り除きます。手順と注意点は次の章で説明します。
6. 関係者に連絡する社内の責任者、制作や保守の委託先、APIの提供元に、何が、いつから公開されていたかを伝えます。個人情報を扱うデータベースに入られたおそれがあれば、個人情報保護委員会への報告が必要かを確かめます。
7. 再発防止を入れ、もう一度確かめる後の章の配置と設定を入れたあと、最初の章のcurlで、すべての場所と入口が404か403になることを確かめます。

手順2で作り直す主な値と、切り替える時の注意は次のとおりです。

Laravelは、旧鍵を APP_PREVIOUS_KEYS に並べると、旧鍵で暗号化した値も復号できる仕組みを持っています。漏洩した鍵をここに残すと、その鍵で作られた値も受け付け続けるため、保存データを新しい鍵で暗号化し直したら外します。

手順3のログ確認では、該当URLへの要求のうち、200で返したものを抜き出します。ログの場所は、Nginxなら /var/log/nginx/、Apacheなら /var/log/apache2/ や /var/log/httpd/ が一般的です。レンタルサーバーでは、管理画面から取り出したログに同じ検索をかけます。

# 200で返した .git と .env への要求(日時、IPアドレス、URL、返したバイト数)
zgrep -hE '/[.](git|env)' /var/log/nginx/access.log* |
  awk '$9 == 200 {print $4, $1, $7, $10}'

# IPアドレスごとの件数
zgrep -hE '/[.](git|env)' /var/log/nginx/access.log* |
  awk '$9 == 200 {print $1}' | sort | uniq -c | sort -rn

標準のログ形式(combined)では、9番目の欄が応答コード、10番目が返したバイト数です。バイト数がトップページやエラーページと同じなら、ファイルの中身は渡っていない可能性が高いと読めます。見知らぬIPアドレスの国や組織は、自社の無料ツール「IPアドレスから位置を調べるツール」でも調べられますが、結果は目安です。

Git履歴から消すだけでは足りない理由と、消す手順

Git履歴から秘密の値を消しても、すでに複製されたものは消えません。公開されていた.gitを取得した人の手元、開発者のクローン、フォークには古い履歴が残ります。GitHubの公式文書も、秘密の値は最初に失効させるか作り直すべきだとしています。

そのうえで履歴から取り除くのは、古い値の再利用や、別の人による再公開を防ぐためです。GitHubが示す手順の要点は、新しいクローンで書き換えて、まとめて送り直すことです。

# 1. 作業用に、新しくクローンする
git clone https://github.com/組織名/リポジトリ名.git
cd リポジトリ名

# 2. 全履歴から .env を取り除く(git-filter-repo 2.47以降)
git filter-repo --sensitive-data-removal --invert-paths --path .env

# 3. 書き換えた履歴を送る(共同作業者へ事前に知らせる)
git push --force --mirror origin

# 4. 今後は追跡しないよう .gitignore に加える
echo ".env" >> .gitignore
git add .gitignore
git commit -m "Ignore .env"
git push origin main

書き換えのあと、古いクローンを持つ人はクローンし直します。GitHubの文書は、古い履歴から作ったブランチを、mergeではなくrebaseするよう求めています。GitHubの画面に残るキャッシュや、プルリクエストが参照する古いコミットの削除は、GitHubサポートへの依頼が必要です。

再発防止の基本: 公開ディレクトリの外に置く

根本の対策は、秘密の値と管理用のフォルダを、公開ディレクトリの外に置く配置にすることです。サーバーの拒否設定は、移行や設定の書き換えで消えることがあるため、2段目の守りと考えます。

• Laravelなど: 公開ディレクトリを public に設定し、.env や .git はその1つ上に置きます。
• WordPress: 公式の手引きのとおり、wp-config.php はインストール先の1つ上の階層へ移しても動きます。
• バックアップ: 圧縮ファイルやダンプは、公開ディレクトリの外か別の保管場所に置き、作業後に消すことを手順書に入れます。
• 公開先を変えられないサーバー: サーバー会社の案内で、公開フォルダの外に置ける場所があるかを確かめます。

サーバー設定で拒否する: Apache、Nginx、WordPressの例

配置を直すまでの応急処置と、置き忘れへの備えとして、ドットで始まるファイルとフォルダ、バックアップのような名前を拒否します。ここでの設定例と表の応答は、nginx 1.30.5とApache 2.4.69での動作確認に基づきます。

Apache(.htaccess)

公開ディレクトリの .htaccess の先頭に、次の2行を書きます。正規表現の [.] は、ドットそのものを表す書き方です。

# ドットで始まるファイルとフォルダを 404 にする(.well-known は除く)
RedirectMatch 404 /[.](?!well-known/)
# バックアップや作業用のファイルを 404 にする
RedirectMatch 404 (?i)([.](bak|old|orig|save|swp|sql)|~)$

.well-known を除くのは、SSL/TLS証明書の自動更新(Let’s Encryptなど)や security.txt がこの場所を使うためです。除外を忘れると証明書の更新が失敗するので、更新の状況は「SSL/TLS証明書のチェック方法」の手順で確かめます。サイトでzipなどを配布していなければ、2行目に zip や gz を足せます。

表の「FilesMatchだけ」は、<FilesMatch "^[.]"> と Require all denied の組み合わせです。Apacheの公式文書のとおり、FilesMatchはファイル名(パスの最後の部分)だけを見ます。そのため /.git/HEAD は HEAD という名前で判定され、拒否されません。

.htaccessは、サーバーが上書きを許している時だけ効く仕組みです。許可が無いとエラーも出ずに何も効かないため、書いた後は /.env が404になるかをcurlで確かめます。

一覧表示を止める Options -Indexes は、上書きの許可が無いと、書いただけでサイト全体が500エラーになります。追加したら、すぐにトップページを開いて確かめてください。

Nginx

Nginxは.htaccessを読まないため、サーバー設定の server ブロックに書きます。書いたら nginx -t で構文を確かめてから、設定を再読み込みします。

# ほかの正規表現の location より前に書く
location ~ /[.](?!well-known/) {
    return 404;
}
location ~* ([.](bak|old|orig|save|swp|sql)|~)$ {
    return 404;
}

# ^~ を付けた location の中では上の規則が効かないため、中にも書く
location ^~ /assets/ {
    location ~ /[.] {
        return 404;
    }
}

Nginxの公式文書のとおり、正規表現のlocationは書いた順に調べられ、最初に当てはまったものが使われます。静的ファイル用の正規表現を先に書くと、/.notes.txt のようなファイルがそちらで配られます。また、^~ を付けたlocationの下では正規表現が調べられないため、例の /assets/.env は中に拒否を書くまで200のままです。

WordPress

Apacheで動くWordPressでは、上の2行に wp-config.php の拒否を加えたものを、.htaccess の先頭に置く形が基本です。WordPressの公式の手引きによると、# BEGIN WordPress と # END WordPress の間は、WordPressが書き換えることがあります。そのため、追加する行はこの範囲の外に書きます。

# 既存の「# BEGIN WordPress」より上に、次の行を足す
RedirectMatch 404 /[.](?!well-known/)
RedirectMatch 404 (?i)([.](bak|old|orig|save|swp|sql)|~)$
<Files "wp-config.php">
    Require all denied
</Files>

# (この下に、WordPressが管理する「# BEGIN WordPress」から
#  「# END WordPress」までが続く。その間には書き足さない)

あわせて、wp-config.php の WP_DEBUG_LOG の値も確認が必要です。true にすると、エラーは既定で wp-content/debug.log に書かれ、公開ディレクトリの中に残ります。本体やプラグインの更新状況も合わせて点検するなら、「WordPressの脆弱性を確認する方法」の手順が使えます。

サーバー設定を開く機会に、セキュリティヘッダーも一緒に見直すと、作業が1回で済みます。設定例は「セキュリティヘッダーの設定方法」にまとめています。

デプロイ手順と.gitignoreで、混入を防ぐ

.gitや.envを公開先へ持ち込まない手順にすれば、拒否の設定に頼る場面が減ります。要点は、公開するファイルだけを、決まった手順で送ることです。

• 送るのはビルド後の成果物だけ: dist や public など、公開用のフォルダだけを送ります。git archive で作るアーカイブには、.gitフォルダが入りません。
• 公開ディレクトリでcloneしない: Gitの操作は公開ディレクトリの外で行い、成果物だけを配置します。
• FTPでフォルダごと上げない: 送る前に、ドットで始まる隠しファイルを表示して、中身を確かめます。
• 検証環境も同じ扱いにする: stg. などの検証環境は、IP制限やBasic認証で関係者だけに絞ります。

.gitignoreは、秘密の値をリポジトリに入れないための設定です。ただしGitの公式文書のとおり、すでに追跡しているファイルには効かないため、git rm --cached で追跡を外してから使います。

# .gitignore の例(.env.example だけは共有する)
.env
.env.*
!.env.example
*.log
*.sql
*.bak

# すでに追跡している .env を外す(手元のファイルは残る)
git rm --cached .env

デプロイ前に自動で止める

人の注意に頼らず、公開用のフォルダに置いてはいけないファイルがあれば、デプロイを止める確認を手順に組み込みます。次の例は、見つかった時に終了コード1で止まるため、CIの1工程として使えます。

# 公開するフォルダ(ここでは dist)に、置いてはいけないファイルが無いか確かめる
found=$(find dist -name '.git' -o -name '.env*' -o -name '*.sql' -o -name '*.bak')
if [ -n "$found" ]; then
  echo "公開してはいけないファイルがあります:"
  echo "$found"
  exit 1
fi

コミットの段階では、OSSのGitleaksなど、パスワードやAPIキーの形の文字列を見つける道具を、コミット前の確認(pre-commit)に入れられます。GitHubの公開リポジトリでは、シークレットスキャンが無料で自動的に動く仕組みです。公開後は、同じURLを外から定期的に確かめる処理をサーバー監視の項目に加えると、設定の巻き戻りに気づけます。

公開前と更新後のチェックリスト

• 公開ディレクトリが public などの公開用フォルダだけを指している
• /.git/HEAD、/.env、/wp-config.php.bak が、すべてのホスト名とHTTP、HTTPSで404か403になる
• CDNを使う場合、オリジンへ直接確かめても同じ結果になる
• 拒否の設定を入れた後も、トップページと /.well-known/ の下が表示される
• 公開ディレクトリに、zip、SQLダンプ、debug.log、phpinfoのページが残っていない
• .gitignoreに .env が入り、git ls-files の一覧に .env が出てこない
• デプロイの手順に、置いてはいけないファイルの確認が入っている

サーバーの入れ替え、デプロイ方法の変更、制作会社の交代の後が、このリストを最初からやり直す時期です。公開ファイル以外の点検項目は、「Webサイトのセキュリティチェック項目30選」にまとめています。無料の簡易チェックで分かる範囲と、専門の診断が要る場面の違いは、「簡易チェックと脆弱性診断の違い」で説明しています。

よくある質問

関連記事Webサイトのセキュリティチェック項目30選｜確認方法つき一覧表関連記事簡易チェックと脆弱性診断の違い｜無料ツールでできることと、専門業者が必要な場面関連記事WordPressの脆弱性を確認する方法｜本体、プラグインの更新と対処の手順関連記事セキュリティヘッダーの設定方法｜HSTS、CSPの設定例つき

The post .gitや.envが公開されていないか確認する方法と、見つかった時の対処 first appeared on 総合デジタルマーケティング企業 エスライン・テクノロジーズ.

セキュリティチェックの30項目は、外から17、管理画面と契約で13を確かめる

セキュリティチェックの30項目は、確かめる場所で2つに分かれます。公開ファイル、通信、HTTPヘッダー、DNSの17項目は外から、更新、ログイン、運用の13項目は管理画面と契約書で確かめます。

外から確かめられる設定は、攻撃者にも同じように見えています。証明書の期限切れや公開されたファイルは、URLを知っていれば誰でも気づけます。

管理画面の項目は外から見えないため、無料ツールでは確かめられません。IPAの『安全なウェブサイトの運用管理に向けての20ヶ条』も、パスワード、アカウント、ログといった運用の条項を多く含みます。

今日15分でできる最初の点検

最初の15分は、見つかったときの被害が大きい5点に絞ります。ブラウザとCMSの管理画面があれば、専門の道具は要りません。

1. 公開ファイルを開いてみる(2分)ブラウザで自社ドメインの /.git/HEAD と /.env を開きます。『見つかりません』や『Forbidden』と出れば合格です。設定値のような文字が表示されたら、ほかの作業より先に項目1の対処へ進みます。
2. 証明書の期限を見る(2分)アドレスバーの鍵アイコンから証明書を開き、有効期限を確かめます。残りが30日を切っていたら、自動更新が動いているかをサーバーの管理画面で見ます。
3. 更新とログインの守りを見る(5分)CMSの管理画面で、本体とプラグインに未適用の更新がないかを見ます。管理者アカウントで2段階認証が有効か、パスワードをほかのサービスと使い回していないかも確かめます。
4. バックアップの最終日を見る(3分)サーバーの管理画面で、最後に取得した日と保存先を確かめます。更新を当てるのは、この確認の後です。
5. 外から見える設定をまとめて診断する(3分)無料のWebサイトセキュリティチェックにURLを入れ、重大度が『緊急』と『高』の指摘だけを書き出します。登録は要らず、通常30秒から90秒で結果が出ます。

ターミナルを使える場合は、次の2行で項目5、6、9、11〜13の応答をまとめて確かめられます。1行目のようにスキームを省くと、curlはhttpで接続します。

curl -I example.com
curl -I https://example.com/

例: 1行目の応答(この形なら項目6は合格)
HTTP/1.1 301 Moved Permanently
Location: https://example.com/

例: 2行目の応答で探すヘッダー
strict-transport-security: max-age=31536000
x-frame-options: SAMEORIGIN
x-content-type-options: nosniff

外から確かめる17項目(公開ファイル、通信、ヘッダー、DNS)

外から確かめる17項目は、ログインせずに、ブラウザ、curl、無料ツールで確かめられます。表は、確認方法と合格の目安、放置の危険、直し方の順に並べています。

公開してはいけないファイルとページ(項目1〜5)

よく使われるファイル名は、URLを推測して機械的に試せます。OWASPの検査ガイド(WSTG-CONF-04)も、.bak などの古い写しがソースコードや認証情報を表示する危険を挙げています。確認は、自社のサイトだけに限ります。

# Apache(.htaccess)の例: .git、.svn、.env を含むURLに404を返す
RedirectMatch 404 /\.(git|svn|env)

# nginxの例: 同じURLへのアクセスを拒否する(403を返す)
location ~ /\.(git|svn|env) {
    deny all;
}

どちらの例も、証明書の自動更新が使う /.well-known/ には影響しません。見つかった後の手順は、.gitや.envが公開されていたときの確認と対処で扱っています。

通信の暗号化と証明書(項目6〜10)

HTTPSは、入力内容を盗み見と書き換えから守る土台です。20ヶ条でも、通信の暗号化は独立した1条になっています。SSL/TLS証明書の詳しい見方は、SSL/TLS証明書のチェック方法で扱っています。

HTTPヘッダーとCookie(項目11〜14)

セキュリティヘッダーは、ブラウザに備わった防御を有効にする設定です。確認はどれも、curl -I の応答を1回見れば済みます。書き方の例は、セキュリティヘッダーの設定方法にまとめています。

APIを公開しているサイトは、Access-Control-Allow-Origin が * や、受け取ったオリジンをそのまま返す設定になっていないかも確かめます。

DNSとメール認証(項目15〜17)

自社ドメインを名乗るなりすましメールは、サイトに触れずに顧客や取引先を狙います。IPAの情報セキュリティ10大脅威2026でも、ビジネスメール詐欺が組織向けの10位に入りました。メール認証は、受け取る側に本物かどうかを判断させる仕組みです。

# Mac、Linux
dig TXT example.com +short
dig TXT _dmarc.example.com +short

# Windows(コマンドプロンプト、PowerShell)
nslookup -type=TXT example.com
nslookup -type=TXT _dmarc.example.com

例: 合格の形(SPFは1行だけ、DMARCはレポートの宛先あり)
"v=spf1 include:_spf.example.net ~all"
"v=DMARC1; p=none; rua=mailto:dmarc-report@example.com"

Gmailの送信者のガイドラインは、すべての送信者にSPFかDKIMを求め、1日5,000件以上を送る送信者にはSPF、DKIM、DMARCのすべてを求めています。コマンドを使わない場合は、ドメイン名を入れるだけのDMARC、SPF、DKIMの無料診断ツールでも設定の状況を確かめられます。

管理画面と契約で確かめる13項目(更新、ログイン、運用)

管理画面と契約で確かめる13項目は、外からは見えませんが、乗っ取りを防げるか、被害から戻れるかを決めます。CMS、サーバー、ドメインの管理画面と、制作会社やサーバー事業者との契約書を手元に置いて確かめます。

ソフトウェアの更新(項目18〜21)

公表された脆弱性には、CVEという共通の番号が付きます。攻撃者はその情報を使い、対策していないシステムを狙います。10大脅威2026でも、『システムの脆弱性を悪用した攻撃』が組織向けの4位でした。

WordPressでの具体的な手順は、WordPressの脆弱性を確認する方法で扱っています。

ログインとアカウント(項目22〜25)

管理画面のパスワードは、ほかで漏れたパスワードの一覧を使って機械的に試されます。20ヶ条も、不正ログインの対策、不要なアカウント、推測されやすいパスワードを、それぞれ独立した条項にしています。CMSだけでなく、サーバー、ドメイン、DNS、メール配信の管理画面も同じ扱いです。

バックアップ、監視、体制(項目26〜30)

被害をゼロにはできないため、気づく仕組みと戻す手段を先に用意します。IPAが2026年10月9日に出した不正アクセスによる漏えい等の事案を踏まえた注意喚起も、ログの保持期間、保有データ、外部サービスの見直しを求めています。

直す順番は、被害の大きさ、見つかりやすさ、手間の3つで決める

30項目は、被害の大きさ、見つかりやすさ、直す手間と副作用の3つの物差しで、3段階に分けて直します。被害が大きく機械的に見つかるものから先に直し、表示を壊すおそれのあるものは試しながら進めます。

点検の計画: 今日15分、毎月30分、変更時と年1回の見直し

点検は一度で終わらせず、頻度を決めて回します。目安は、初回15分、毎月30分、変更したときと公開前に10分から20分、四半期に1時間、年1回に半日です。

公開前と変更したときは、次の8点を確かめてから切り替えます。作業の途中で作ったファイルやアカウントは、消し忘れやすいためです。

• 作業で作った .zip、.sql、.bak を消した(項目2)
• テスト用のアカウントと、制作会社の一時的なアカウントを消した(項目25)
• 本番のデバッグ表示を切った。WordPressは WP_DEBUG、PHPは display_errors(項目5)
• テスト環境は、Basic認証などで社外から見えない(項目4)
• 全ページがhttpsで開き、Consoleに混在コンテンツの警告がない(項目6、10)
• curl -I で、ヘッダーが意図どおりに返る(項目11〜13)
• フォームを送信し、WAFに止められず、確認メールが届いた(項目28)
• 新しく作ったサブドメインに、使い終えたら消す担当を決めた(項目17)

問題が見つかったときの初動: 記録、停止、鍵の作り直し、報告

公開ファイルや改ざんが見つかったら、記録、停止、作り直し、調査、報告の判断、再発防止の順で動きます。先にファイルを消すと、調査と報告に要る証拠まで失うためです。

1. 記録を残す見つけた日時、URL、画面のスクリーンショットを残し、サーバーのログを保全します。
2. 公開を止める問題のファイルを公開フォルダから外すか、サーバー設定で拒否します。改ざんであれば、メンテナンス表示に切り替えます。
3. 鍵とパスワードを作り直す読まれたおそれのある .env のパスワード、APIキー、管理者のパスワードを変えます。ファイルを消しても、写しを取られた鍵は使えるままです。
4. ログで範囲を調べるアクセスログで、そのURLに外部から届いたリクエストの有無と日時を確かめます。
5. 報告と通知の要否を判断する個人データが漏れたおそれがあれば、個人情報保護委員会への報告と本人への通知が必要かを判断します。
6. 再発を防ぐ原因になった手順、権限、更新の漏れを直し、点検の計画に組み込みます。

自社だけで判断が難しい場合は、制作や保守を担う会社に早めに連絡します。診断結果の読み方や直す順番の相談は、エスライン・テクノロジーズのお問い合わせ窓口でも受け付けています。

IPAの20ヶ条と、この点検表の対応

この30項目は、IPAの20ヶ条の観点を、小規模なサイトで確かめられる形に置き換えたものです。20ヶ条は2005年に掲載が始まり、2015年の全面改訂を経て、2019年3月6日に最終更新されています。

20ヶ条の3条目にある『安全なウェブサイトの作り方』の脆弱性対策は、入力フォームなどの作りを調べる必要があり、この点検表には含めていません。ただし、項目11〜14のヘッダーとCookieは、その被害を和らげる設定にあたります。

反対に、メール認証(項目15、16)、参照先のないCNAME(項目17)、証明書の自動更新(項目7)は、20ヶ条にない観点として加えました。メールの送信者への要件や、証明書の有効期間の短縮といった、最終更新後の変化に対応するためです。

無料ツール、手作業、専門家の診断の使い分け

外から見える項目は無料ツールでまとめて確かめ、管理画面の項目は自分の目で確かめます。入力フォームや会員機能の作りは、専門家の脆弱性診断が担う領域です。

手順5で使った無料ツール『Security Checker X』は、公開ページの取得、DNSの照会、TLSの接続確認だけで診断し、ログインの試行や攻撃用データの送信はしません。各指摘には『確認済み』『推定』『可能性』の確度が付くため、事実と推測を分けて読めます。診断できるのは、自社か管理権限のあるサイトだけです。

専門家に依頼するかどうかの判断は、簡易チェックと脆弱性診断の違いで整理しています。

よくある質問

項目ごとに詳しく確かめる関連記事

関連記事.gitや.envが公開されていないか確認する方法と、見つかった時の対処 関連記事SSL/TLS証明書のチェック方法 関連記事セキュリティヘッダーの設定方法 関連記事WordPressの脆弱性を確認する方法 関連記事簡易チェックと脆弱性診断の違い

The post Webサイトのセキュリティチェック項目30選｜確認方法つき一覧表 first appeared on 総合デジタルマーケティング企業 エスライン・テクノロジーズ.