CloudflareとHonoを使ってHerokuのデフォルトドメインを（実質）封印したWebアプリケーションをつくるメモ

Posted at 2025-03-15

表題の通りだが…メモです。

本記事に記載している内容はすべてricemountainer個人の意見・見解であり、所属企業に帰属するものではありません。(お約束)

はじめに

HerokuはWebアプリを作るとデフォルトで[アプリ名]-[ランダム文字列].herokuapp.comというドメインでURLが公開される。（以後これを「デフォルトドメイン」と呼ぶこととする。）カスタムドメインも設定可能だが、設定してもこのデフォルトドメインは残ったままで、アクセス可能になる。このデフォルトドメインへのアクセスを封印したい、という場合のメモ。構成によって色々やり方はあると思うが、ここではCloudflare -> Herokuという構成において、これを実現する方法を考える。なお、CloudflareからHerokuへはDNS Proxyを設定している前提とする。この点に関してはこの記事が詳しい。

オーソドックスな方法（概要）

Private SpaceをつくってTrusted IP RangeにCloudflareのIPアドレスを設定する。多分これが一番オーソドックスで分かりやすい方法だと思う。これによってWebアプリケーション側でゴチャゴチャ実装する必要がなくなり、Cloudflareを経由しないデフォルトドメインへのアクセスは、HerokuのプラットフォームがWebアプリケーションに着く前に全部弾いてくれる。Private SpaceのTrusted IP Rangeについてはこちらに解説がある。Cloudflare（がオリジンにリクエストを送るとき）のIPアドレスもここで公開されているので設定可能。

Private Spaceは従来Heroku Enterpriseの機能だったが、2024年12月からHeroku Enterpriseでなくても作成可能になったので、やろうと思えば個人でも実現可能な構成である。

とはいうものの、CloudflareのIPアドレスは未来永劫固定というわけでもないだろうし、適宜メンテが必要になるだろう。どの程度の頻度で見ればいいのか不明だが、知らずに変更されると実質サービス停止になる可能性があるので（誰もWebアプリにアクセスできなくなる場合が考えられるので）、このやり方を取るならその辺はちゃんと押さえておきたいところである。ちなみに探したらIFTTTでCloudflareのIP変更トリガーのアプレットがあったので、これを使ってThen側にHerokuのPrivate Space Trusted IP Rangeのメンテ機構を組み入れれば、ある程度は自動化できるかもしれない。やったことがないのでわからないが。。

カスタムヘッダを使う方法

これが本題である（これを書きたかった）。同じCDN製品であるCloudFrontでは有名な（だと個人的に思っている）カスタムヘッダを用いる方法である。

Cloudflareでは、オリジンにリクエストをforwardする際にカスタムヘッダを追加できる。これを利用して、Cloudflare->Herokuでカスタムヘッダを追加し、Herokuアプリ側ではそのカスタムヘッダを参照して、正当なリクエストかどうかを判定する方法。これをHonoを使って実装する。

Cloudflareの設定

まずCloudflare側の設定をする。ダッシュボードのトップページ（アカウントホーム）から対象ドメインを選択し、左側のサイドバーのメニューから「ルール」>「概要」>「ルールを作成」>「Request Header Transform Rule」を選択する。

その後、カスタムヘッダ追加対象とするドメインを指定する。以下は「完全URI」指定でドメイン完全一致指定での設定例。

「ルール名」は日本語で書ける。
「受信リクエストが一致する場合」で「カスタムフィルタ式」か「すべての受信リクエスト」のどちらかを選択する。
「カスタムフィルタ式」の場合はさらに追加で条件を入力する。これは使用するドメインの内容や種類によって適宜変更が必要。
- 例えばhttps://herokutest.hogehoge.comというドメインでのアクセスを想定する場合は「フィールド」＝「完全URI」、「オペレータ」＝「次と等しい」、「値」＝https://herokutest.hogehoge.comを入力する。「オペレータ」にはワイルドカードの指定もできるので、例えばhttps://*.herokutest.hogehoge.comのように「特定のドメインのサブドメイン全部」みたいな指定も可能。
- ただしここで指定した値のドメインに関してはCloudflareのDNS設定が「Proxy」になっている必要がある。 これに関しては入力完了時にプロンプトで注意喚起がある。冒頭のドキュメントの内容に従えばProxyにはなっているはず。

画面下部に移動、「実行内容...」の項で「項目の選択」プルダウンを開き、実際に追加するカスタムヘッダのKEYとVALUEを設定する。

最初に「スタティック設定」「ダイナミック設定」「削除」の３種類の中からリクエストヘッダの操作の種類を選択する。リクエストヘッダの追加は前者２つなのでどちらかを選ぶ。ここでは「スタティック設定」を選択する。
- というか「ダイナミック」は正直個人的に使い方がわかっていない。このドキュメントを読む限りでは式を入力できるらしいが、具体的にどんなexpressionが使えるのかのプレースホルダーやドキュメントの記述がないので、どう扱えばいいかわからない。「スタティック設定」だと固定でそのカスタムヘッダを追加・上書きできるようなので一旦「スタティック設定」で進む。（個人的にはこれで十分）
「ヘッダー名」には実際に追加するヘッダー名を入力する。ここではX-Heroku-Tokenだが別になんでも良い。
「値」には適当な値を入力する。推測困難な値がよいだろう。UUID v4など。ここで指定した値は後ほどHerokuアプリ側で「正当なリクエストかどうか」を判定する際に使用するので記録しておく。

「場所:」はこのルールを実行するタイミングを指定する。「最初」か「最後」かになる。試したことないのでわからないが「最初」を指定した後別のルールで条件に当てはまるものに遭遇した場合、意図せずリクエストヘッダが書き換わる可能性もある。確実に遂行したいなら「最後」の方が良いのだろう。そもそも複数一致するような条件のルールを作らない方がいいと個人的には思うけども。。

Herokuアプリの実装

Herokuアプリを実装する。ここではHonoを使う。npm create hono@latestあるいはyarn create hono等の後templateでnodejsを選択。アプリ名やらパッケージマネージャやらなんやらは好みで適当に指定してください。

% yarn create hono
yarn create v1.22.22
[1/4] 🔍  Resolving packages...
[2/4] 🚚  Fetching packages...
[3/4] 🔗  Linking dependencies...
[4/4] 🔨  Building fresh packages...
success Installed "create-hono@0.15.3" with binaries:
      - create-hono
[##] 2/2create-hono version 0.15.3
? Target directory my-app
? Which template do you want to use? nodejs
? Do you want to install project dependencies? yes
? Which package manager do you want to use? yarn
✔ Cloning the template
✔ Installing project dependencies
🎉 Copied project files
Get started with: cd my-app
✨  Done in 28.35s.

src/index.tsを開いて以下のコードを追加。

src/index.ts

const CLOUDFLARE_CUSTOM_HEADER_TOKEN = process.env['CLOUDFLARE_CUSTOM_HEADER_TOKEN'];

app.use(async (c, next) => {
  const herokuToken = c.req.header('X-Heroku-Token');
  if (herokuToken && CLOUDFLARE_CUSTOM_HEADER_TOKEN && herokuToken == CLOUDFLARE_CUSTOM_HEADER_TOKEN) {
    await next();
  } else {
    return c.text('invalid access', 403);
  }
})

難しいことは特に何もしていない。X-Heroku-Tokenというキーのリクエストヘッダの値を取ってアプリの環境変数と照合し、一致していたら先に進む、一致していなければ403を返す、という処理だけだ。シンプルだがこれが肝であり、これにより「リクエストヘッダに正しい値が設定されているリクエスト（Cloudflare経由＝カスタムドメイン経由のアクセス（のはず））だけを許容し他はすべて拒否」という動作をする。403と上のレスポンスはあくまで例であり、別に他のHTTPステータスコードでもいいし、なんなら何もレスポンスしなくても良い。ここは自由である。

この照合のため、アプリにCLOUDFLARE_CUSTOM_HEADER_TOKENという名前の環境変数を設定することを前提としている。この名前の環境変数に、↑でCloudflareに指定したカスタムヘッダの「値」を指定する。

まず以下コマンドでHerokuアプリを作成して

% heroku apps:create [Herokuアプリ名]

以下のコマンドで環境変数をセットする。

% heroku config:set CLOUDFLARE_CUSTOM_HEADER_TOKEN=[↑でCloudflareに指定したカスタムヘッダの「値」] -a [Herokuアプリ名]

HerokuへのDeployは色々やり方あるので好きな方法で実施してください。。以下参考。

ちなみにちょっと注意点として、Honoの初期セットだとtsxがdevDependenciesにだけいるのだが、

  "devDependencies": {
    "@types/node": "^20.11.17",
    "tsx": "^4.7.1"
  }

Herokuは基本的にdevDependenciesのパッケージはアプリの実行開始前にすべて削除するので、そのままdeployしても「tsxが見つからない」というエラーで起動できない。このため使用するパッケージマネージャに応じて事前に環境変数の設定が必要になる。例えばyarnなら以下。

% heroku config:set YARN_PRODUCTION=false -a [Herokuアプリ名]

これで準備は整った。カスタムドメイン経由ならちゃんとリクエストが通るが

% curl https://[カスタムドメイン]
Hello Hono!

デフォルトドメインに対してはリクエストが通らず拒否される。

% curl -i -v https://[アプリ名]-[ランダム文字列].herokuapp.com
...
< HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
...
invalid access

注意点としては。。。

このやり方はあくまで「X-Heroku-Tokenというリクエストヘッダに正しい値が設定されている」＝「カスタムドメイン経由でのアクセスに違いない」という前提に基づく動作であり、ある意味性善説である。このリクエストヘッダに正しい値が設定されていればいいのだから、curl -H "X-Heroku-Token: [Cloudflareで設定した値]" https://[アプリ名]-[ランダム文字列].herokuapp.comのような形で直接カスタムヘッダを指定してリクエストすれば、デフォルトドメインに対してもリクエストは通る、という点には注意が必要である。
これはアプリ側で処理することになるので、拒否するにしても少なからずアプリ側のリソースを使ってしまうことになる。そういう意味で、プラットフォーム側で全部弾ける（＝アプリのリソースを使うことなく拒否できる）Private SpaceのTrusted IPの方が理想的ではある。「アプリ側でできる手軽な防御策」という程度に捉えておく必要がある。

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up