Une entreprise utilise Amazon CloudFront avec deux origines : une application dynamique sur Amazon EC2 et un compartiment Amazon S3 pour le contenu statique. Un audit de sécurité a révélé que les réponses HTTPS de l'application ne contiennent pas l'en-tête HTTP X-Frame-Options requis pour atténuer le détournement de clics (clickjacking). Un ingénieur de sécurité doit s'assurer que l'ensemble de la pile est conforme en ajoutant l'en-tête aux réponses. Quelle approche répond à cette exigence ?

L'option correcte est de déployer une fonction Lambda@Edge déclenchée par l'événement de réponse d'origine (origin response). Cet événement se produit après que CloudFront a reçu la réponse de l'origine (EC2 ou S3) mais avant de la mettre en cache et de la renvoyer au visualiseur. Cela permet à Lambda@Edge d'inspecter et de modifier les en-têtes de la réponse, y compris l'ajout de X-Frame-Options, pour tout le contenu servi par CloudFront, assurant ainsi une conformité uniforme. Déclencher sur l'événement de requête du visualiseur (viewer request) est incorrect car cet événement se produit avant que CloudFront ne contacte l'origine, donc la réponse n'est pas encore disponible pour modification. Ajouter l'en-tête comme en-tête personnalisé dans les paramètres d'origine de CloudFront est incorrect car cela concerne les en-têtes envoyés à l'origine, pas ceux reçus de l'origine. Modifier l'application EC2 directement serait une solution partielle, car elle ne couvrirait pas le contenu statique servi par S3, et l'objectif est une solution CloudFront-centrique pour l'ensemble de la pile.