はじめに

CloudFront + Lambda@EdgeでのBasic認証 + WAFでのアクセス制御という構成で、「エラー403より先にベーシック認証のポップアップが出る？」という現象に遭遇しました。
これについての原因と対処方法をメモとしてまとめておきます。

本記事で扱う内容

CloudFrontでIP制限（WAF）とBasic認証（Lambda@Edge）を併用したときの問題
ベーシック認証がWAFの前に出てしまうように見える原因
カスタムエラーレスポンス設定による403レスポンスのすり替わり
正しく403が出るようにするための設定変更

構成概要

以下のような構成で運用していました。

CloudFront
- S3（SPA）オリジン + API Gatewayオリジン
WAF
- 許可されたIP以外は BLOCK（403）
Lambda@Edge
- S3オリジンに対して Basic認証を実装（Vierwer Requestイベントで実行）

やりたいこと

許可IPのみアクセス許可（WAFがBLOCK）
通った人だけベーシック認証（Lambda@Edgeが401を返す）

起きていた問題

意図と反して、WAFで弾かれるはずのリクエストでもベーシック認証のポップアップが出るという現象が発生。

WAFのログ → 正しく BLOCK（403）が記録されている
ブラウザのDevTools → 401 Unauthorized が返っている
Lambda@Edgeのログ → WAFブロックされたはずのリクエストが到達してる？

原因

CloudFrontの「エラーページ」の設定が原因

CloudFrontでは「WAFの403」も「オリジンからの403」も区別なく扱われるということで、

403 が返ってきたら → S3の index.html を返す
という設定があると
CloudFrontは「WAFの403」にも同じように反応し、エラーページを取得するために再度オリジンへアクセスしようとしてしまう。
→ その再アクセス時に、Lambda@Edge（Basic認証）を実行してしまい、401 を返してしまう

解決方法

カスタムエラーレスポンスの設定から403を削除

CloudFrontディストリビューションの「エラーページ」の設定から、以下を削除：

HTTPエラーコード: 403
レスポンスページのパス: /index.html などにリダイレクト

結果

非許可IP → 403 Forbidden（認証ポップアップが出ない）
許可IP → Lambda@Edgeで認証チェック → 未認証なら401（認証ポップアップが出る）

ということで理想通りの制御順序になりました。

補足メモ

WAFは CloudFront の Viewer Request の直後に評価される
CloudFrontは403の中身を見分けないので、カスタムエラー処理があるとすべて置き換えてしまう

まとめ

CloudFront + WAF + Lambda@Edge の組み合わせでWAFの403をそのまま返させるためには、CloudFrontで403のカスタムエラーレスポンスに設定してはいけない。

参考リンク