個人用WebアプリをCloudflare Accessで保護する。メールOTPだけの一番簡単な構成

自分専用のWebアプリ(タスク管理ツール)をCloudflare Workersにデプロイしたのですが、URLを知っていれば誰でも開ける状態は避けたい。かといって、自分しか使わないアプリのためにログイン機能を実装するのは大袈裟です。

この用途にはCloudflare Accessがちょうど良かったので、設定手順と、やってみて分かったことを書きます。コードの変更はゼロで、workers.devのURLにメール認証(ワンタイムコード)を付けられます。無料です。

自前ログインではなくAccessを選んだ理由

最初に検討の結論だけ書いておきます。

• アプリが静的アセット+APIの構成だと、アプリ内にログイン画面を足してもJSバンドル自体はURL直叩きで取得できてしまう。中にデータが入っていれば見えます
• Accessはリクエストがアプリに届く**前段(エッジ)**で認証を要求するので、HTML・JS・APIすべてが保護されます
• 実装・保守コストがゼロ。パスワード管理も不要(メールにコードが届く方式)

「本気で守るなら前段で」というのは自前実装だとそれなりの工事ですが、Cloudflareに乗っているならスイッチ1つでした。

設定手順

1. workers.devのURLにAccessを有効化する

CloudflareダッシュボードのWorkers & Pages → 対象のWorker → ドメイン(Domains & Routes)を開くと、workers.devのURLの下に「公開」というプルダウンがあります。これを開くとAccessで保護する選択肢が出てくるので、選ぶだけです。

有効化すると「訪問者はサインインし、WorkerがロードされるまえにAccessポリシーに一致する必要があります」という確認が出ます。これで前段保護が効いた状態です。

2. 許可するメールアドレスを設定する

そのまま「Cloudflare Accessを管理」から、アクセスを許可するメールアドレスを自分のアドレスだけに絞ります。以降、このURLを開くと:

1. Accessのログイン画面にリダイレクトされる
2. メールアドレスを入れると、6桁のワンタイムコードが届く
3. コードを入力すると本来のアプリが表示される

という動線になります。スマホからも同じように使えます。

3. プレビューURLも忘れずに閉じる

見落としがちですが、同じ画面にプレビューURL(*-プロジェクト名.サブドメイン.workers.dev)の設定もあります。本体を保護してもこちらが公開のままだと、プレビュー経由で最新デプロイが見えてしまいます。使っていないならトグルをオフにして無効化、使うなら同様にAccessをかけておきます。

4. Zero Trustの初回セットアップ(必要な場合)

Accessの管理画面(Zero Trustダッシュボード)に初めて入るとき、プラン選択を求められます。Freeプラン(50ユーザーまで$0) を選べばOKです。途中で支払い方法の登録を求められる場合がありますが、Freeプランのままなら課金は発生しません。

セッションの有効期間もここで変更できます。デフォルトは短めなので、個人利用なら Access → Applications → 対象アプリ → Session Duration を伸ばしておくと、毎日コードを入力せずに済みます(最長1ヶ月)。

効いていることの確認

シークレットウィンドウで開いてログイン画面が出ることを確認するのが基本ですが、curlでも確認できます。

$ curl -s -o /dev/null -w "%{http_code}\n" https://my-app.example.workers.dev/
302

未認証のリクエストがアプリに到達せず、*.cloudflareaccess.com のログインへ302リダイレクトされていれば保護されています。ページだけでなく /api/... へのリクエストも同じ302になることを確認しておくと安心です。

補足: 「Access JWTを検証せよ」という警告について

有効化のときに「Workerが機密データを扱う場合は、Access JWTを検証してAccessをバイパスしたリクエストを拒否してください」という注意書きが表示されます。

これは、Accessを通らない経路が生まれた場合に備えて、アプリ側でもトークンを検証するための注意です。現在はworkers.devのURLだけを入口にし、そのURLへAccessを設定しています。ただし、カスタムドメインや別ルートを追加すると前提が変わります。機密性の高いデータを扱う場合は、入口の設定だけに依存せず、Worker側でもAccess JWTを検証する方が安全です。検証に使うAUDタグとJWKの公開鍵URLは、パスワードやAPIキーのような秘密情報ではありません。

まとめ

• 個人アプリでは、Accessを使うとアプリへログイン機能を実装せずに入口を制限できる
• workers.devのURLならダッシュボードのプルダウンから直接有効化できる(カスタムドメイン不要)
• プレビューURLの閉じ忘れに注意
• セッション期間を伸ばせば使い勝手はほぼ普通のアプリ

「外に出したいが公開はしたくない」個人プロジェクトの定番構成としておすすめです。

環境

• Cloudflare Workers(workers.devドメイン)+ Cloudflare Access(Zero Trust Freeプラン)
• アプリ側はNext.js + @opennextjs/cloudflareですが、Accessの設定はアプリの実装に依存しません