【要約】【CloudFront OAC × Lambda Function URL】SSRアプリのPOSTだけ403になった話 [Qiita_Trend] | Summary by TechDistill
> Source: Qiita_Trend
Execute Primary Source
// Problem
開発者がAWS CDKを用いて、CloudFront OAC経由でLambda Function URLを保護する構成を構築した際、POSTリクエストのみが403エラーで失敗する問題に直面した。\n・GETリクエストは正常に動作するが、POST/PUTリクエストのみが拒否される。\n・原因は、OACが要求するSigV4署名において、クライアント側でのペイロードハッシュ計算が必要なためである。\n・一般的なブラウザのfetch()ではこの計算が行われないため、アプリ層に到達する前にAWS側で拒否される。
// Approach
開発者は、OACによる厳格なIAM署名検証を避け、CloudFrontのカスタムヘッダー機能を利用した「シークレットヘッダー方式」を採用した。\n・Lambda Function URLの認証をauthType: NONEに変更する。\n・CloudFrontのcustomHeaders設定により、オリジンへ特定のシークレットヘッダーを付与する。\n・Next.jsのMiddlewareにて、リクエストヘッダーのシークレット値を検証する。\n・SSM Parameter Store（String型）を用いて、シークレット値を固定値で管理する。
// Result
構成変更後、Next.jsのAPI Routesを用いたPOSTリクエストが正常に動作し、DynamoDBへのデータ保存が成功した。\n・ブラウザからのPOSTリクエストが403エラーにならず、200 OKを返すようになった。\n・CloudFront経由以外の直接アクセスは、アプリ側の検証により拒否される。\n・SSMのString型利用により、KMSのコストを抑えた運用を実現した。
Senior Engineer Insight
> OACは公式推奨だが、ペイロードハッシュの要件がWebアプリの挙動と致命的に相性が悪い。この「ドキュメントの行間」を読み解く力が重要だ。シークレットヘッダー方式は、IAMによる厳格な認可ではないが、実用的な防御層として機能する。ただし、ヘッダーの偽装リスクやSSMでの管理コストを考慮し、機密性のレベルに応じた適切な選択が求められる。