Webサイト公開前チェックリスト：リリース前・移行後に確認したいセキュリティ8項目

1. 公開前チェックリストの全体像

公開しているすべての名前（通常はwwwなしのドメインとwww）を、http://とhttps://の両方で確認します。DNSを切り替える前でも、curl -sI --resolve example.com:443:203.0.113.10 https://example.com/のようにすれば、本番の名前で新しいサーバーを試せます。例のIPアドレスは新しいサーバーのものに置き換えてください。

この8行は、Sitelemetryの無料の公開準備スナップショットが1つの公開オリジンに対して登録なしで行う8項目のパッシブなチェックに対応しています。以下の手作業の手順は、1つのオリジンを1回調べるだけでは届かない範囲まで扱います。すべてのホスト名、両方のスキーム、エラーページ、DKIM、レジストラの設定です。

2. DNSの名前解決：すべての名前が新しいホストを指しているか

なぜ重要か。移行が中途半端になっていても気づきにくいものです。wwwなしのドメインは新しいサーバーに移ったのに、wwwは古いプラットフォームへのCNAMEのまま、ということがあります。残ったレコードはセキュリティの問題にもなります。OWASPのサブドメインテイクオーバー対策のチートシートは、削除済みのクラウドリソースを指すCNAMEがあると第三者がそのサブドメインを乗っ取れること、宙に浮いたMXレコードがあると攻撃者がそのドメイン宛てのメールを受け取り、メールによるドメイン認証で証明書まで取得できることを説明しています。

確かめ方。

dig +short A example.com
dig +short AAAA example.com
dig +short CNAME www.example.com
dig +short NS example.com

手元のネットワークがキャッシュした応答を返している場合に備えて、パブリックリゾルバーにも同じ問い合わせをします（dig @1.1.1.1 …）。そのうえで、DNS事業者の管理画面からゾーン全体をエクスポートして目を通します。

良い状態。公開しているすべての名前が想定どおりのホストに解決され、AAAAレコードは、そのホストが実際にIPv6でサイトを配信している場合にだけ存在します。ネームサーバーは少なくとも2台が応答し（RFC 1034が定める最低数です）、すべてのレコードについて目的と担当者が分かっています。

よくある直し方。古いレコードは向け直すか削除します。サービスを廃止するときは、OWASPが勧める順番に従います。DNSレコードを更新または削除し、少なくともTTLの時間だけ待ち、それからクラウドリソースを削除します。切り替えの前には、もとの長いTTLが切り替え時点で切れているよう早めにTTLを短くし、移行が落ち着いたら元に戻します。

3. SPF、DMARC、CAA：ドメインの使われ方を宣言するレコード

なぜ重要か。自社のドメインであっても、From行には誰でも書けます。SPFはそのドメインでメールを送ってよいサーバーを列挙し、DKIMはメッセージに署名し、DMARCは、目に見えるFromのドメインと整合した形でSPFもDKIMもpassしなかったメールを受信側がどう扱うべきかを伝えます。Gmail、Yahoo、Outlook.comは、大量送信者にこの3つすべてを求めています。CAAは、そのドメイン名の証明書を発行してよい認証局を指定するもので、公的に信頼された認証局は発行前にこれを確認しなければなりません。

確かめ方。Fromアドレスに使っているドメインを問い合わせます。通常はwwwではなく、登録したドメインそのものです。

dig +short TXT example.com
dig +short TXT _dmarc.example.com
dig +short CAA example.com

良い状態。

• SPF：v=spf1のレコードがちょうど1つあり、RFC 7208が定めるDNS問い合わせを伴う項目10個の上限（入れ子のincludeも数える）に収まり、末尾が~allか-allで、+allではない。
• DMARC：v=DMARC1; p=none; rua=mailto:dmarc@example.comのようなレコードがあり、ポリシーを強める前にレポートが届いている。現在の標準であるRFC 9989（2026年5月）は、利用者がメーリングリストに投稿しうるドメインはp=rejectを公開すべきでないとしています。それでもrejectにする場合は、まず少なくとも1か月はp=none、同じくらいの期間quarantineで運用し、レポートを比べてからにするよう求めています。
• DKIM：自社に代わってメールを送るすべての外部サービスが、自社のドメインで署名している。公開鍵はselector._domainkey.example.comにあるため、調べるにはセレクターが必要です。セレクターは、そのサービスが送ったメールのDKIM-Signatureヘッダーのs=タグに書かれています。
• CAA：利用中の認証局ごとに0 issue "letsencrypt.org"のようなレコードがある。CDNが使う認証局も含めます。CAAレコードを置かないことも認められています。また、CAAがあっても、許可された認証局による誤発行は防げません。

よくある直し方。重複したSPFレコードをまとめ、廃止したサービスのincludeを外し、DMARCはレポート付きのp=noneから始めます。ハードフェイルのほうが自動的に安全というわけではありません。RFC 9989は、-allの場合、整合したDKIM署名があればpassしたはずのメールでも、DMARCの評価前にSPFの結果だけで拒否されることがあり、その拒否はDMARCレポートに現れないと注意しています。サブドメインにDMARCレコードがなければ、受信側はDNSの階層をさかのぼって親ドメインのポリシーを使います。認証局も、Let's EncryptのCAAの説明にあるとおり、発行対象の名前かその上位にある最も近いCAAレコードを使います。したがって、wwwに_dmarcやCAAのレコードがないこと自体は、それだけでは抜けではありません。レコードの読み方と直し方はSPF・DMARCの確認方法で詳しく説明しています。

4. TLS証明書：有効で、名前が合っていて、誰かが更新しているか

なぜ重要か。期限切れや名前の合わない証明書があると、訪問者はブラウザの警告画面で止まります。HSTSを使っているホストでは、その警告を越えて先へ進むこともできません。更新の頻度も上がっています。CA/Browser ForumのBallot SC081v3により、2026年3月15日以降に発行される公的に信頼された証明書の有効期間は最長200日になり、2027年3月からは100日、2029年3月からは47日に短くなります。Let's Encryptは2025年6月4日に有効期限の通知メールを終了しました。

確かめ方。ホスト名ごとに実行します。

openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null \
  | openssl x509 -noout -issuer -enddate -ext subjectAltName

s_clientは単独でも実行してください。出力にVerify return code: 0 (ok)が含まれ、ネゴシエートされたプロトコルが表示されるはずです。

良い状態。サーバーが送る中間証明書でチェーンを検証でき、公開しているすべての名前が証明書に含まれ、接続にはTLS 1.3か1.2が使われます。更新は自動化され、運用手順書に担当者が書かれています。認証局からの通知に頼らない、自前の有効期限アラートもあります。

よくある直し方。ACMEで更新を自動化します。Let's Encryptは、ACME Renewal Information（ARI）を使うか、有効期間の3分の2ほどが過ぎた時点で更新することを勧めており、証明書の有効期間が45日になると60日ごとの固定の更新間隔では足りなくなると注意しています。移行後は、新しいプラットフォームで実際に更新が動くことを確認します。1回のハンドシェイクで分かるのはネゴシエートされたプロトコルだけなので、TLS 1.0と1.1が無効になっていることは、対応バージョンをすべて列挙するスキャナーで確かめてください。

証明書、HSTS、そのほかのブラウザの保護がHTTPSでの訪問の中でどう組み合わさるかは、HTTPSとTLSの解説ガイドで説明しています。

5. HTTPSリダイレクト：1回でHTTPSへ、正規のホストは1つ、そしてHSTS

なぜ重要か。古いリンク、ブックマーク、スクリプト、古いクライアントは、今もhttp://のアドレスにアクセスしてきます。リダイレクトでHTTPSに移せますが、hstspreload.orgが指摘するとおり、通信経路上の攻撃者はそのリダイレクトを横取りして書き換えられます。HSTSは、最初の安全な訪問より後のすべての訪問でこの隙間を閉じます。

確かめ方。

curl -sI http://example.com/
curl -sI http://www.example.com/
curl -sIL "http://example.com/page?x=1" | grep -iE '^(HTTP|location)'

良い状態。

• MDNのTLSガイドが勧めるとおり、同じホストのHTTPSの同じパスへ恒久的にリダイレクトし（301、またはリクエストメソッドを保つなら308）、正規のホストへのリダイレクトはその後の多くても1回。パスとクエリ文字列が残っている。
• HTTPSのレスポンスがStrict-Transport-Securityを送っている。平文のHTTPではブラウザがこのヘッダーを無視するので、リダイレクト自体には不要です。
• 混在コンテンツがない。ブラウザは、HTTPSのページがhttp://で読み込むスクリプトをブロックします。

よくある直し方。リダイレクトはJavaScriptではなく、サーバーかCDNで行います。HSTSのmax-ageは段階的に延ばして31536000（1年）のような長い値にし、includeSubDomainsはすべてのサブドメインがHTTPSで配信されてから追加します。hstspreload.orgは現在、HSTSは勧める一方でプリロードは勧めていません。証明書の取得にACMEのHTTP-01チャレンジを使っている場合は、80番ポートに到達できる状態を保ちます。無料の公開準備スナップショットでこの項目をテストするには、http://のアドレスを入力してください。ドメイン名だけを入力した場合やhttps://のアドレスを入力した場合は、リダイレクトの代わりにHSTSのmax-ageと混在コンテンツを確認します。

6. セキュリティヘッダー：最終レスポンスとエラーページを確認する

なぜ重要か。セキュリティヘッダーは、ページが何を読み込めるか、誰がページをフレームに埋め込めるか、コンテンツのタイプをどう扱うかをブラウザに伝えます。サーバーやCDNの設定に書かれていることが多く、ホスティングを移すと抜け落ちがちです。クロスサイトスクリプティングのようなバグの被害を抑えるものであって、バグそのものを直すわけではありません。

確かめ方。

curl -sIL https://example.com/
curl -sI https://example.com/no-such-page

エラーページも確認してください。OWASP HTTP Headers Cheat Sheetにあるとおり、nginxはalwaysパラメーターがないと、特定のステータスコードでしかadd_headerの値を送りません。

良い状態。シンプルなサイトなら、次が妥当な出発点です。

Content-Security-Policy: default-src 'self'; object-src 'none'; base-uri 'self'; frame-ancestors 'none'
Strict-Transport-Security: max-age=31536000
X-Content-Type-Options: nosniff
Referrer-Policy: strict-origin-when-cross-origin
Permissions-Policy: geolocation=(), camera=(), microphone=()

• CSPは、まずContent-Security-Policy-Report-Onlyとして展開します。ページが正当に読み込むものはすべて許可する必要があり、'unsafe-inline'を入れると効果の多くが失われます。
• frame-ancestorsはdefault-srcを引き継がず、<meta>タグでは無視されます。X-Frame-Options: DENYは古いブラウザ向けの代替手段です。
• セッションCookieにSecure、HttpOnly、明示的なSameSiteが付いている（MDNのSet-Cookieを参照）。HttpOnlyは、ページ上のスクリプトがCookieを読み取ること（たとえばdocument.cookie経由）を防ぎますが、ブラウザは条件に合うリクエストに引き続きCookieを付けて送ります。XSSによるCookieの盗用は抑えられても、XSSそのものを防ぐわけではありません。
• X-XSS-Protectionヘッダーは送らないか、0にする。

よくある直し方。ヘッダーは一つの層（サーバー、アプリケーション、CDNのいずれか）で設定し、エラーページを含むすべてのレスポンスに各ヘッダーがちょうど1回付くようにします。各ヘッダーの詳しい説明はセキュリティヘッダーのチェック方法にあります。

7. 技術情報の露出、キャッシュ、圧縮

技術情報の露出

なぜ重要か。Server、X-Powered-By、generatorタグは、使っているソフトウェアを誰にでも教えます。MDNは、詳しいバージョン番号があると既知の脆弱性を探しやすくなると指摘しています。ただし、隠すこと自体は防御になりません。OWASPのテストガイドはこれを「隠蔽によるセキュリティ」と呼び、MDNもパッチを当てるほうが確実な方法だとしています。

確かめ方。curl -sI https://example.com/ | grep -iE '^(server|x-powered-by):'を実行し、ページのソースでgeneratorと、バージョン番号を含むスクリプトのファイル名を探します。

良い状態。Serverはバージョン番号のないServer: nginxのような値で、X-Powered-Byは送られていません。

よくある直し方。nginxならserver_tokens off;、php.iniならexpose_php = Off、Expressならapp.disable('x-powered-by')です。ページから古いライブラリが分かる場合は、隠すのではなく更新します。

キャッシュ、圧縮、CDN

なぜ重要か。キャッシュのルールは、レスポンスの保存されたコピーを誰が受け取るかを決めます。CDNにキャッシュされた個人向けのページは、次の訪問者に配信されかねません。MDNが、個人向けのレスポンスにはCache-Control: privateが必要だとしているのはそのためです。

確かめ方。curl -sI -H 'Accept-Encoding: br, gzip' https://example.com/を実行し、続いてログインしてアカウントのページを開き、ブラウザの開発者ツールでそのレスポンスヘッダーを読みます。

良い状態。HTMLがContent-Encoding: brまたはgzipで配信され、すべてのレスポンスにCache-Controlが明示されています。長いmax-ageとimmutableはバージョン付きの静的ファイルにだけ付き、利用者のデータを含むページにはprivateかno-storeが付いています（no-cacheは保存自体は許します）。

よくある直し方。ルートの種類ごとにCache-Controlを設定し、ログイン後のパスはCDNのキャッシュから外し、テキストはサーバーかCDNで圧縮します。CDNを使っていないこと自体はリスクではありません。表示速度についてはWebパフォーマンスの解説で扱っています。

8. ドメインの登録情報：有効期限、ロック、連絡先

なぜ重要か。.comなどの分野別トップレベルドメイン（gTLD）が期限切れになると、ICANNのExpired Registration Recovery Policyにより、レジストラは一定期間そのドメインのDNSの名前解決を止めなければなりません。サイトとメールが同時に止まります。.jpのような国別コードトップレベルドメイン（ccTLD）の扱いはレジストリと登録事業者の規則によるので、契約先の案内を確認しておきます。更新の案内は登録されている連絡先に届きますが、その連絡先が退職者や制作会社の元担当者だったり、期限切れになるドメイン自体のメールアドレスだったりすることがあります。

確かめ方。ICANNの検索ツールを使います。2025年1月28日以降、gTLDの登録情報の正式な情報源はRDAPで、WHOISが引き続き必須なのは.com、.name、.postだけです。.jpドメインは、レジストリであるJPRSのWHOISで登録情報を検索できます。それ以外の国別ドメインは、そのレジストリかレジストラの検索サービスを使います。そのうえでレジストラ（登録事業者）のアカウントにログインし、設定を確認します。

良い状態。

• 有効期限まで数か月以上あり、自動更新が有効で、更新日の時点でも使える支払い方法が登録されている。
• gTLDではclientTransferProhibitedが設定され、レジストラが提供していれば更新ロックと削除ロックも有効。clientHoldやserverHoldは付いていない（これらがあるとドメインはDNSから外れます）。.jpでは、登録事業者が提供する移転ロックなどの設定を確認します。
• 連絡先が複数の人に届き、少なくとも一つはそのドメイン以外のアドレスで、レジストラのアカウントに多要素認証が設定されている。

よくある直し方。自動更新を有効にし、数年分まとめて更新し、レジストラにロックのステータスを設定してもらい（各ステータスはICANNのEPPステータスコードの解説にあります）、連絡先を更新します。

9. このチェックリストで扱わないこと

この8項目が示すのは、サイトを取り巻く公開された設定です。すべてを満たしていても、侵入しやすいサイトはありえます。どの項目も、アプリケーションそのものや運用の仕方を見ていないからです。次は別に見直してください。

• アプリケーションの脆弱性：インジェクション、テンプレートでのクロスサイトスクリプティング、安全でないファイルアップロード、アカウント間のアクセス。
• 認証とセッション：ログイン、パスワードの再設定、多要素認証、管理画面。
• 依存関係とサーバー：CMSのプラグイン、パッケージ、OSのパッチ。
• 秘密情報とアクセス権：リポジトリやフロントエンドのバンドルに含まれた鍵、本番環境・DNS事業者・レジストラに誰がアクセスできるか。
• バックアップ：実際に試した復元。

この8項目は脆弱性診断の代わりにはなりません。ログイン、権限などアプリケーション側の確認はWebセキュリティ監査のガイドで扱っています。日本語の資料では、IPAの「安全なウェブサイトの作り方」が、届出の多い脆弱性や影響の大きい脆弱性ごとに開発者・運営者向けの対策をまとめています。IPAは同じページで、検査パターンを絞り込んだ「ウェブ健康診断」で脆弱性が検出されなくても安全宣言にはつながらないと明記しています。範囲を絞った外からの確認には、どれも同じことが言えます。詳しいテストケースはOWASP Web Security Testing Guideにあります。

1つのオリジンをすばやく一巡する。無料の公開準備スナップショットは登録なしで使えます。1つの公開オリジンについて、公開DNS、メール関連のDNSレコード、ドメインの登録情報、TLSハンドシェイク、トップページのHTTPレスポンスを読み、攻撃コードの送信、ポートスキャン、ログインの試行、負荷をかけるアクセスは行いません。結果は、スコア、堅牢化グレード、リスクシグナルと合格チェックの数、最初に見るべき最大3件のシグナルです。ペネトレーションテストではありません。良いスコアが意味するのは、その時点でこれらの公開シグナルが健全に見えたということです。Freeプランはセキュリティチェックのみで、6つの監査領域（セキュリティ、テクニカルSEO、AI可視性、アクセシビリティ、パフォーマンス、連携）は月額49ドルのStarterプランから使えます。