X-Frame-Options와 CSP frame-ancestors는 무엇이 다를까? 클릭재킹 방어 기준 정리

X-Frame-Options와 CSP frame-ancestors는 무엇이 다를까? 클릭재킹 방어 기준 정리

X-Frame-Options와 Content-Security-Policy: frame-ancestors는 다른 사이트가 내 페이지를 <iframe> 같은 프레임 안에 넣을 수 있는지 제어하는 HTTP 응답 헤더다. 2026년 5월 15일 기준 MDN과 OWASP 문서를 보면, 둘 다 클릭재킹 방어에 쓰이지만 표현력과 권장 용도가 다르다.

실무에서는 관리자 화면, 결제 화면, 설정 화면처럼 사용자가 로그인한 상태에서 중요한 동작을 수행하는 페이지가 특히 대상이 된다. 이 글은 공식 문서를 기준으로 두 헤더의 차이, 함께 넣어야 하는 경우, 그리고 자주 놓치는 설정 포인트를 객관적인 사실만 정리한다.

클릭재킹은 무엇이고 왜 프레임 제어가 필요할까?

클릭재킹은 공격자가 자기 페이지 위에 투명하거나 위장된 프레임을 올려 두고, 사용자가 실제로는 다른 사이트의 버튼이나 링크를 누르게 만드는 공격이다. MDN과 OWASP는 이런 상황을 막는 대표적인 방법으로 프레임 임베딩 제한과 SameSite 쿠키를 함께 언급한다.

즉 핵심은 내 문서가 어떤 상위 문서 안에서 렌더링될 수 있는지를 제한하는 것이다. 이 지점에서 X-Frame-Options와 frame-ancestors가 역할을 한다.

X-Frame-Options는 무엇을 할 수 있을까?

MDN 기준 X-Frame-Options는 문서의 프레임 임베딩 가능 여부를 제어하는 응답 헤더다. 값은 사실상 DENY와 SAMEORIGIN 두 가지로 보면 된다.

• DENY: 어떤 출처에서도 이 문서를 프레임에 넣을 수 없다.
• SAMEORIGIN: 모든 상위 프레임이 현재 문서와 같은 origin일 때만 임베딩할 수 있다.

ALLOW-FROM은 MDN이 obsolete로 설명하는 값이다. 현대 브라우저는 이 값을 만나면 헤더 전체를 무시할 수 있으므로, 허용 목록이 필요하면 frame-ancestors를 써야 한다.

CSP frame-ancestors는 무엇이 다를까?

frame-ancestors는 CSP의 navigation directive로, 어떤 부모 문서가 현재 페이지를 임베딩할 수 있는지 더 세밀하게 지정한다. MDN은 이 지시어가 <frame>, <iframe>, <object>, <embed>에 대한 부모를 제한한다고 설명한다.

• frame-ancestors 'none': 어떤 부모도 허용하지 않는다.
• frame-ancestors 'self': 같은 origin 부모만 허용한다.
• frame-ancestors 'self' https://partner.example: 같은 origin과 특정 파트너 도메인 같은 여러 출처를 허용할 수 있다.

여기서 중요한 차이는 허용 대상을 여러 개 나열할 수 있다는 점이다. 사내 포털, 결제 파트너, 관리자 셸처럼 일부 외부 도메인만 임베딩을 허용해야 하는 경우에는 X-Frame-Options만으로 표현하기 어렵다.

둘의 핵심 차이는 무엇일까?

항목	X-Frame-Options	CSP frame-ancestors
표현력	DENY, SAMEORIGIN 중심	여러 허용 출처를 명시 가능
권장 위치	HTTP 응답 헤더	HTTP 응답 헤더
메타 태그 지원	지원하지 않음	지원하지 않음
기본값	없으면 임베딩 허용	없으면 임베딩 허용
세부 제어	낮음	높음

MDN은 frame-ancestors를 X-Frame-Options의 replacement로 설명한다. 동시에 브라우저가 frame-ancestors를 지원하면 같은 응답에 X-Frame-Options가 함께 있어도 X-Frame-Options는 무시된다고 적고 있다.

둘 다 같이 넣어야 할까?

MDN의 클릭재킹 가이드는 frame-ancestors와 X-Frame-Options를 함께 설정하면, frame-ancestors를 지원하지 않는 브라우저에서도 임베딩 차단 효과를 기대할 수 있다고 설명한다. 다만 최신 브라우저에서는 frame-ancestors 지원이 매우 좋기 때문에 주된 정책은 보통 이쪽에 둔다.

실무 기준으로 정리하면 다음과 같다.

• 임베딩을 완전히 막고 싶다면 frame-ancestors 'none'와 X-Frame-Options: DENY 조합이 가장 단순하다.
• 같은 사이트 내부에서만 임베딩이 필요하다면 frame-ancestors 'self'와 X-Frame-Options: SAMEORIGIN 조합이 대응된다.
• 특정 외부 파트너 도메인을 허용해야 한다면 실제 제어는 frame-ancestors로 하고, 필요 시 보조적으로 X-Frame-Options를 함께 둔다.

자주 놓치는 설정 포인트는 무엇일까?

1. 메타 태그로는 충분하지 않을까?

아니다. MDN과 OWASP는 둘 다 이 정책들을 HTTP 응답 헤더로 적용해야 한다고 설명한다. <meta http-equiv="X-Frame-Options">는 효과가 없고, frame-ancestors도 <meta> 요소에서 지원되지 않는다.

2. default-src 'none'만 있으면 프레임도 막힐까?

아니다. MDN은 frame-ancestors가 default-src의 fallback을 받지 않는다고 명시한다. 즉 default-src 'none'를 선언해도 frame-ancestors를 따로 쓰지 않으면 다른 사이트가 페이지를 임베딩할 수 있다.

3. 중첩 프레임에서도 한 번만 검사할까?

아니다. MDN은 frame-ancestors가 각 ancestor를 검사한다고 설명한다. 중첩 프레임 구조에서 상위 조상 중 하나라도 정책에 맞지 않으면 로드가 취소된다.

SameSite 쿠키는 왜 같이 언급될까?

OWASP와 MDN은 SameSite=Lax 또는 SameSite=Strict를 세션 쿠키에 적용하면, 다른 사이트의 <iframe> 안에서 요청이 발생할 때 세션 쿠키가 함께 가지 않도록 도와줄 수 있다고 설명한다. 이는 클릭재킹을 직접 막는 프레임 정책의 대체재는 아니지만, 로그인이 필요한 공격 시나리오를 약화시키는 방어층이 될 수 있다.

다만 이 속성만으로 모든 클릭재킹을 막을 수 있다는 뜻은 아니다. 공격이 인증 상태를 필요로 하지 않으면 보호 효과가 제한될 수 있다.

어떤 기준으로 선택하면 될까?

• 완전 차단이 목표면 frame-ancestors 'none'를 기준으로 설계하고, 호환성 보조용으로 X-Frame-Options: DENY를 함께 검토하면 된다.
• 같은 origin만 허용하면 충분한 일반 서비스라면 'self'와 SAMEORIGIN 조합이 가장 이해하기 쉽다.
• 여러 파트너나 서브도메인을 구체적으로 허용해야 하면 frame-ancestors가 사실상 필수다.
• 보안 헤더를 이미 강하게 설정했더라도 frame-ancestors를 별도로 선언했는지 확인해야 한다.

FAQ

Q. X-Frame-Options만 써도 충분할까?

완전 차단이나 same-origin 허용 정도라면 동작 자체는 가능하다. 다만 여러 허용 출처를 표현할 수 없고, MDN도 더 포괄적인 대안으로 frame-ancestors를 안내한다.

Q. 파트너 사이트 한 곳만 프레임 허용하려면 어떻게 해야 할까?

X-Frame-Options의 ALLOW-FROM은 현대 브라우저에서 사실상 쓸 수 없으므로, Content-Security-Policy: frame-ancestors 'self' https://partner.example처럼 허용 출처를 명시하는 방식이 맞다.

Q. iframe 안에 내가 불러오는 외부 페이지 출처 제어도 같은 설정일까?

아니다. MDN은 frame-ancestors가 누가 나를 감쌀 수 있는지 정하는 정책이고, frame-src는 내 페이지 안의 iframe이 어디에서 로드될 수 있는지 정하는 정책이라고 구분한다.

정리

2026년 5월 15일 기준 공식 문서를 기준으로 보면, 클릭재킹 방어의 주력 정책은 CSP frame-ancestors이고 X-Frame-Options는 더 단순한 구형 호환용 성격에 가깝다. 둘 다 응답 헤더로 보내야 하며, 메타 태그로는 대체되지 않는다.

중요한 페이지를 운영 중이라면 현재 응답에 frame-ancestors가 실제로 있는지, default-src만 믿고 있지는 않은지, 그리고 세션 쿠키의 SameSite 속성이 어떤 값인지 함께 점검하는 편이 안전하다.

참고 자료

• MDN: X-Frame-Options header
• MDN: CSP frame-ancestors directive
• MDN: Clickjacking
• OWASP: Clickjacking Defense Cheat Sheet