Cloudflare Pagesで行うべきセキュリティ設定

静的サイトを Cloudflare Pages で公開すると、それだけである程度は守られます。ただし既定のままでは穴が残ります。

公開したその日から、自動化されたアクセスが来ます。管理画面を探す巡回、古い脆弱性を試す通信、ドメインを騙ったメールの送信などです。どれも狙い撃ちではなく、機械的に全世界のドメインへ向けられているものです。

ここでは無料の範囲でできる設定を、効果の大きい順に並べます。

前提：設定する場所が2つに分かれている

最初に混乱する点です。同じ Cloudflare の管理画面でも、設定の置き場所が2か所あります。

セキュリティ設定のほとんどはドメイン側です。Pagesプロジェクトの画面をいくら探しても見つかりません。

優先度の一覧

上から順に片付ければよいです。6番のHSTSだけは、理解してから触ってください。

1. 常時HTTPS

最優先です。http:// で来た通信を、自動的に https:// へ転送する設定です。

通信が暗号化されていないと、公衆無線LANなどの経路上で内容を読まれたり、書き換えられたりする可能性があります。読むだけのサイトでも、書き換えられて別の内容を表示されるのが問題です。

手順

1. 「アカウント ホーム」→ ドメイン名をクリック
2. 左メニュー「SSL/TLS」→「概要」をクリック
3. 暗号化モードが「オフ」になっていないことを確認
4. 左メニュー「SSL/TLS」→「エッジ証明書」をクリック
5. 「Always Use HTTPS」をオンに切り替え

暗号化モードが「オフ」のままだと、4番の項目自体が画面に出てきません。見つからない場合は3番を先に確認してください。

注意

サイト内の画像やスクリプトを http:// で読み込んでいる場合、この設定だけでは解決しません。ブラウザは読み込む前に判定するためです。該当する場合は、記述側を https:// か相対パスに直します。

2. メールのなりすまし防止

見落とされやすいですが、優先度は高いです。

何が起きるか

ドメインを取得すると、そのドメインを差出人に偽装したメールを、誰でも送れる状態になります。「@自分のドメイン」から送られた請求書や依頼のメールが、取引先に届く可能性があります。

防ぐ仕組みは3つです。

分岐：メールを受け取るか

ここで対応が2つに分かれます。先に決めます。

受け取らない場合

1. ドメインの画面で、左メニュー「DNS」→「設定」をクリック
2. 「メールのなりすまし防止」の項目からウィザードを開始
3. 「このドメインからメールを送信しない」に相当する選択肢を選びます
4. 提案されたレコードを確認して適用

追加されるのは次の内容です。手で入れる場合の値は次のとおりです。

p=none で止めません。参考記事でよく見かける値ですが、これは「様子を見るだけで何もしない」という意味です。なりすましは防げません。送らないドメインであれば、最初から p=reject でよいです。

受け取りたい場合

Cloudflare には無料の転送機能があります。独自ドメイン宛のメールを、普段使っているアドレスへ転送する仕組みです。

1. ドメインの画面で、左メニュー「メール」→「メールルーティング」をクリック
2. 画面の指示に従い、転送先のアドレスを登録
3. 転送先アドレス側に届く確認メールのリンクを開きます
4. 必要なDNSレコードの追加を承認

MXレコードは自動で追加されます。手で書く必要はありません。

この場合、DMARCは段階的に上げます。

いきなり3段階目にすると、正規のメールまで拒否される場合があります。送信に使っているサービスをすべて把握してから上げます。

3. www の名前解決

example.com は開けるが www.example.com は開けない、という状態になりやすいです。Cloudflare の管理画面に警告として表示されます。

放置してよいものではありません。名刺やメールに www 付きで書かれた場合、到達しません。

対応は2択

Bを推す理由です。同じ内容が2つのURLで見られる状態は、検索エンジンから見て重複にあたります。どちらを正としてよいか判断させる手間が増えます。

Bの手順

1. Pagesプロジェクトの画面で「Custom domains」タブをクリック
2. 「Set up a custom domain」から www.（自分のドメイン） を追加
3. DNSレコードが自動生成されることを確認
4. ドメインの画面へ戻り、左メニュー「ルール」→「リダイレクト ルール」をクリック
5. テンプレートから「www をルートへリダイレクト」に相当するものを選択
6. 内容を確認して保存

転送の種類は 301（恒久的） を選びます。302（一時的）だと、検索エンジンが正規のURLを切り替えてくれません。

4. ボット対策

自動化されたアクセスに、計算負荷の高い処理を課す機能です。攻撃側の採算を悪化させます。

手順

1. ドメインの画面で、左メニュー「セキュリティ」→「設定」をクリック
2. 絞り込みで「ボットトラフィック」を選択
3. 「ボット ファイト モード」をオンに切り替え

検索エンジンなど、Cloudflare が正規と認めているクローラは通過します。有効化してもSEOへの影響はありません。

注意点

自作のスクリプトから定期的にサイトを叩いている場合は、先に確認してください。

5. セキュリティヘッダー

ブラウザに対して「この範囲を超えた動作はさせない」と指示する仕組みです。Pages では _headers という名前のファイルを置くだけで設定できます。

置く場所

拡張子なしのテキストファイルです。public フォルダの直下に置きます。

public/_headers

書き方

1行目に対象のURLパターン、2行目以降に字下げしてヘッダー名と値を書きます。

/*
  X-Frame-Options: DENY
  X-Content-Type-Options: nosniff
  Referrer-Policy: strict-origin-when-cross-origin
  Permissions-Policy: camera=(), microphone=(), geolocation=()

各行の意味は次のとおりです。

4行とも、静的サイトであれば副作用なく入れられます。

上級者向け：CSP

Content-Security-Policy は最も強力ですが、最も壊れやすいです。読み込むスクリプトの許可先を1つずつ列挙する形になるため、タグマネージャーや外部の計測ツールを使っている場合、設定を誤ると計測が止まります。

入れる場合は、まず監視だけを行う Content-Security-Policy-Report-Only から始めます。いきなり本番へ適用しません。

制限事項

もう1点あります。サーバー側で処理を行う機能（Pages Functions）の応答には、このファイルの指定が適用されません。静的なファイルのみが対象です。

6. HSTS

ここから注意が必要です。

「このサイトには今後必ずHTTPSで接続すること」をブラウザに記憶させる仕組みです。一度記憶させると、指定した期間が過ぎるまで取り消せません。

何が危険か

HTTPSをやめた場合、または証明書に問題が起きた場合、記憶している期間中は訪問者がサイトに一切アクセスできなくなります。「あとで戻す」ができない設定です。

手順

1. 左メニュー「SSL/TLS」→「エッジ証明書」をクリック
2. 「HSTSを有効にする」をクリック
3. 警告文を読み、「理解しました」を選択
4. 「次へ」をクリック
5. 設定項目を入力

6. 「保存」をクリック

Preload を有効にしない理由

ブラウザに最初から組み込まれるリストへ登録する機能です。一度載ると、解除の申請から実際に反映されるまで数か月かかります。個人サイトで得られる効果に対して、取り返しのつかなさが釣り合いません。

進め方

1か月で設定 → 1か月運用して問題なし → 6か月へ延長 → 問題なし → 12か月

急いで長くしません。

補足：最小TLSバージョン

同じ画面に「最小TLSバージョン」という項目があります。ただし Pages のホスト名に対しては設定できない仕様です。ここは触らなくてよいです。

7. プレビューURLを検索結果に出さない

Pages は、本番用ブランチ以外への反映時にプレビュー用のURLを自動生成します。既定では誰でも閲覧可能で、検索結果にも出る可能性があります。

公開前の内容が検索に載ると面倒です。_headers に1行加えて防ぎます。

https://:project.pages.dev/*
  X-Robots-Tag: noindex

:project の部分はそのまま書いてよいです。Cloudflare 側で置き換えられます。

閲覧そのものを制限したい場合は、Pagesプロジェクトの「設定」→「プレビュー アクセス」から制限をかけられます。ただしアクセス管理の初期設定が必要になるため、個人サイトでは検索除外までで十分です。

8. ファイアウォールの個別ルール

ここまでで大半は足ります。特定の攻撃が継続している場合のみ追加します。

先に現状を見る

1. 左メニュー「セキュリティ」→「分析」をクリック
2. 期間を「過去24時間」に設定
3. アクセスされているパス、国、User Agent を確認

攻撃が来ていないのにルールを足さないでください。誤って正規の訪問者を締め出すほうが損失は大きいです。

遮断ルールの例

1. 「セキュリティ」→「セキュリティ ルール」→「ルールを作成」→「カスタム ルール」
2. 条件を設定

存在しないパスのため、遮断しても正規の訪問者に影響はありません。

やってはいけない設定

国で絞る場合は、必ず「検証済みボットを除外する」条件を併せて設定します。

設定後の確認

最後の2つが重要です。設定した直後ではなく、1週間後に見てください。影響は遅れて出ます。

失敗例

まとめ

• セキュリティ設定の大半は Pages ではなくドメイン側の画面にあります
• 最優先は常時HTTPSです。1クリックで終わり、副作用もありません
• メールのなりすまし防止は見落としやすいです。送らないドメインでも設定が要ります
• DMARCは p=none で止めません。送らないなら p=reject まで進めます
• www は転送で統一します。転送は301を選びます
• ボット対策は無料で効果が大きいです。検索エンジンへの影響なし
• セキュリティヘッダーは public/_headers に4行書くだけです。CSPだけは慎重に
• HSTSは取り消せない設定です。1か月から始め、段階的に延ばします
• ファイアウォールの個別ルールは、実際に攻撃が来てから追加します

最初にやることは、常時HTTPSをオンにすることです。1分で終わり、他のどの設定よりも効果が大きいです。