웹 개발자를 위한 iFrame 보안: 모범 사례 (KO)

iFrame 샌드박싱항상 sandbox 속성을 사용하여 iFrame 기능을 제한하고, 신뢰할 수 없는 콘텐츠가 스크립트를 실행하거나 로컬 저장소에 액세스하거나 양식을 제출하는 것을 방지합니다.

강력한 CSP 구현콘텐츠 보안 정책(CSP) 헤더를 활용하여 페이지가 로드하고 실행할 수 있는 리소스를 제어하고, 특히 iFrame을 대상으로 혼합 콘텐츠 문제 및 스크립트 삽입을 방지합니다.

X-Frame-Options 및 CSP Frame-Ancestors 활용X-Frame-Options를 DENY 또는 SAMEORIGIN으로 설정하여 클릭재킹으로부터 사이트를 보호하고, 최신 브라우저의 경우 CSP에서 더 세분화된 frame-ancestors 지시문을 사용하세요.

외부 콘텐츠에 대한 주의iFrame을 통해 임베드된 모든 타사 콘텐츠는 해당 보안 관행을 암묵적으로 신뢰하는 것이므로 철저히 검토하세요. 강력한 보안 보장을 제공하거나 서버 측 처리를 허용하는 솔루션을 선호합니다.

iFrame의 양날의 검: 편리함 대 보안

iFrame(인라인 프레임)은 다른 소스의 콘텐츠를 웹 페이지에 원활하게 포함할 수 있도록 하는 최신 웹 개발의 필수적인 부분입니다. YouTube 동영상, 결제 게이트웨이, 소셜 미디어 위젯 또는 ID 확인 흐름 등 iFrame은 타의 추종을 불허하는 유연성을 제공합니다. 그러나 이러한 강력한 기능에는 상당한 보안 주의사항이 따릅니다. 적절한 예방 조치 없이는 iFrame이 클릭재킹, 교차 사이트 스크립팅(XSS) 및 데이터 유출을 포함한 다양한 공격의 벡터가 될 수 있습니다. 웹 애플리케이션이 더욱 복잡해지고 상호 연결됨에 따라 iFrame 보안 모범 사례를 이해하고 구현하는 것은 더 이상 선택 사항이 아니라 필수 사항입니다.

iFrame의 핵심 과제는 본질적으로 외부 콘텐츠가 자신의 페이지 컨텍스트 내에서 실행되도록 허용한다는 사실에 있습니다. 이 외부 콘텐츠는 애플리케이션과 동일한 보안 표준을 따르지 않거나 악성일 수도 있습니다. 따라서 iFrame 보안의 목표는 이 임베드된 콘텐츠를 가능한 한 많이 격리하여 상위 문서 및 사용자 데이터와 상호 작용하거나 손상시킬 가능성을 제한하는 것입니다.

필수 iFrame 보안 조치: 샌드박싱 및 CSP

1. sandbox 속성: 첫 번째 방어선

HTML5 sandbox 속성은 iFrame의 가장 중요한 보안 기능이라고 할 수 있습니다. iFrame 내의 콘텐츠에 엄격한 제한을 적용하여 페이지의 나머지 부분과 격리할 수 있습니다. 기본적으로 값 없이 sandbox 속성을 포함하기만 하면 가장 엄격한 제한이 적용되어 iFrame 콘텐츠를 고유한 출처에서 온 것처럼 처리하고 스크립트 실행, 양식 제출 및 로컬 저장소 액세스를 방지합니다.

매우 안전하지만 기본 샌드박스는 많은 사용 사례에 너무 제한적일 수 있습니다. sandbox 속성에 특정 키워드를 값으로 제공하여 선택적으로 제한을 해제할 수 있습니다:

• allow-forms: 양식 제출을 허용합니다.
• allow-modals: iFrame이 모달 창(예: alert(), confirm(), prompt())을 열 수 있도록 허용합니다.
• allow-popups: 팝업(예: window.open())을 허용합니다.
• allow-popups-to-escape-sandbox: 샌드박스 처리된 문서가 샌드박스 제한을 상속하지 않고 새 창을 열 수 있도록 허용합니다.
• allow-pointer-lock: 포인터 잠금 API를 허용합니다.
• allow-same-origin: iFrame 콘텐츠가 상위 문서와 동일한 출처에서 온 것으로 처리되도록 허용합니다. 이는 임베드된 콘텐츠가 제대로 작동하는 데 종종 필요합니다(예: 쿠키, 로컬 저장소 액세스). 극도로 주의해서 사용하십시오.
• allow-scripts: JavaScript 실행을 허용합니다. 이는 강력한 권한이며 신뢰할 수 있는 소스에만 부여해야 합니다.
• allow-top-navigation: iFrame이 최상위 브라우징 컨텍스트를 탐색할 수 있도록 허용합니다(즉, 상위 창의 URL 변경).

모범 사례: 항상 sandbox 속성을 사용하십시오. 기본값(값 없음)으로 시작하고 최소한의 필요한 권한만 추가하십시오. 예를 들어, 결제 양식을 임베드하는 경우 allow-forms allow-scripts가 필요할 수 있지만, 절대적으로 필요하고 철저히 검증되지 않는 한 allow-same-origin은 원하지 않을 것입니다.

<iframe src="https://trusted-payment-gateway.com/form" sandbox="allow-forms allow-scripts"></iframe>

2. 콘텐츠 보안 정책(CSP): 콘텐츠 로딩 제어

콘텐츠 보안 정책(CSP)은 XSS 및 데이터 삽입을 포함한 다양한 유형의 공격을 완화하는 데 도움이 되는 강력한 보안 메커니즘입니다. HTTP 헤더(Content-Security-Policy) 또는 <meta> 태그를 통해 CSP를 정의함으로써 브라우저가 로드하고 실행할 수 있는 콘텐츠 소스를 지정할 수 있습니다.

iFrame 보안의 경우 CSP는 주로 두 가지 방식으로 중요합니다:

• iFrame으로부터 상위 보호: 상위 페이지의 강력한 CSP는 악용된 iFrame이 악성 스크립트나 콘텐츠를 주 애플리케이션으로 로드하는 것을 방지할 수 있습니다.
• 상위로부터 iFrame 보호(및 그 반대): frame-src 지시문은 iFrame에 대한 유효한 소스를 특별히 제어합니다. frame-ancestors 지시문은 현재 리소스(페이지)를 iFrame에 임베드할 수 있는 출처를 지정하여 클릭재킹을 방지합니다.

CSP 헤더 예시:

Content-Security-Policy: default-src 'self'; script-src 'self' https://trusted-cdn.com; frame-src 'self' https://trusted-iframe-source.com; frame-ancestors 'self';

이 CSP는 자신의 출처 및 trusted-cdn.com에서만 스크립트를 허용하고, 자신의 출처 및 trusted-iframe-source.com에서만 iFrame을 허용합니다. 결정적으로, frame-ancestors 'self'는 페이지가 자신에 의해서만 임베드될 수 있도록 보장하여 클릭재킹을 효과적으로 방지합니다.

클릭재킹으로부터 보호: X-Frame-Options 및 frame-ancestors

클릭재킹(UI 재정의)은 악성 웹사이트가 자신의 사이트 위에 투명한 iFrame을 오버레이하여 사용자가 악성 사이트와 상호 작용한다고 생각하면서 자신의 사이트 요소를 클릭하도록 속이는 공격입니다. 이는 구매, 설정 변경 또는 민감한 정보 공개와 같은 무단 작업으로 이어질 수 있습니다.

1. X-Frame-Options HTTP 헤더

X-Frame-Options HTTP 헤더는 클릭재킹을 방지하는 전통적인 방법입니다. 페이지를 <frame>, <iframe>, <embed> 또는 <object>에 렌더링할 수 있는지 여부를 브라우저에 알려줍니다.

• X-Frame-Options: DENY: 페이지를 프레임에 표시할 수 없습니다. 시도하는 사이트에 관계없이. 이것이 가장 안전한 옵션입니다.
• X-Frame-Options: SAMEORIGIN: 페이지는 페이지 자체와 동일한 출처의 프레임에만 표시될 수 있습니다.

모범 사례: 다른 사이트에 페이지를 명시적으로 임베드해야 하는 경우가 아니라면(그렇다면 frame-ancestors를 신중하게 사용), 민감한 사용자 작업을 처리하는 모든 페이지에 X-Frame-Options: DENY를 설정하십시오.

2. CSP의 frame-ancestors 지시문

콘텐츠 보안 정책 내의 frame-ancestors 지시문은 X-Frame-Options에 대한 더 현대적이고 유연한 대안입니다. 콘텐츠를 임베드할 수 있는 여러 출처를 지정할 수 있습니다.

예시:

Content-Security-Policy: frame-ancestors 'self' https://partner-site.com;

이것은 페이지가 자신과 partner-site.com에 의해 임베드될 수 있도록 허용합니다. X-Frame-Options와 frame-ancestors가 모두 존재하면 최신 브라우저에서는 일반적으로 frame-ancestors가 우선합니다. 더 광범위한 브라우저 호환성을 위해 둘 다 사용하는 것이 좋습니다.

책임감 있는 데이터 처리 및 통신

iFrame이 상위 창과 통신해야 할 때(또는 그 반대), 동일 출처 정책에 의해 직접적인 JavaScript 액세스가 일반적으로 차단됩니다. 교차 출처 통신을 위한 권장하는 보안 방법은 window.postMessage()입니다.

window.postMessage()를 안전하게 사용하기

window.postMessage()는 서로 다른 출처 간에 창이 안전하게 통신할 수 있도록 합니다. 그러나 취약점을 피하려면 올바르게 사용하는 것이 중요합니다.

• 항상 보낸 사람의 출처를 확인하세요: 메시지를 받을 때 항상 event.origin 속성을 확인하여 메시지가 예상되는 소스에서 왔는지 확인하십시오.
• 대상 출처를 지정하세요: 메시지를 보낼 때 '*' 대신 정확한 대상 출처를 제공하십시오(예: iframeWindow.postMessage('hello', 'https://expected-origin.com');). '*'를 사용하면 모든 창이 메시지를 받을 수 있어 보안 위험이 됩니다.
• 수신된 데이터를 정리하십시오: postMessage()를 통해 수신된 모든 데이터를 신뢰할 수 없는 입력으로 처리하고 XSS를 방지하기 위해 사용하기 전에 정리하십시오.

예시 (상위에서 iFrame으로 전송):

const iframe = document.getElementById('myIframe');
iframe.contentWindow.postMessage('Hello from parent!', 'https://trusted-iframe-source.com');

예시 (iFrame이 상위로부터 수신):

window.addEventListener('message', (event) => {
  if (event.origin !== 'https://parent-domain.com') {
    // 예상 출처에서 온 메시지가 아님, 무시하거나 기록.
    return;
  }
  console.log('Message from parent:', event.data);
  // 데이터를 처리하되, 먼저 정리하세요!
});

Didit이 안전한 임베드 가능한 워크플로우를 돕는 방법

Didit은 올인원 ID 플랫폼으로서 ID 확인 흐름에 임베드 가능한 구성 요소를 자주 활용합니다. 당사의 접근 방식은 강력한 iFrame 및 워크플로우 격리의 중요한 필요성을 이해하고 보안을 핵심으로 구축되었습니다. Didit은 최고 보안 표준을 준수하면서 원활하게 통합되도록 설계된 안전한 호스팅 확인 링크 및 웹 SDK를 제공합니다.

• 호스팅 확인 링크: Didit은 각 확인 세션에 대해 안전하고 고유한 URL을 생성합니다. 이 링크는 사용자를 Didit이 호스팅하는 격리된 환경으로 리디렉션하여 민감한 확인 프로세스를 애플리케이션 도메인과 완전히 분리합니다. 이렇게 하면 핵심 확인을 위해 복잡한 iFrame 샌드박싱이 필요하지 않습니다.
• 강력한 격리가 적용된 웹 SDK: 인컨텍스트 임베딩이 필요한 시나리오의 경우 Didit의 웹 SDK는 가장 엄격하게 필요한 sandbox 속성을 활용하여 보안 iFrame 내에서 작동하도록 설계되었습니다. 우리는 postMessage()를 사용하여 안전한 교차 출처 통신의 복잡성을 관리하여 iFrame과 애플리케이션 간에 필요한 정리된 데이터만 교환되도록 합니다.
• 규정 준수 및 인증: Didit은 SOC 2 Type II 및 ISO 27001 인증을 받았으며 GDPR을 준수합니다. 당사의 인프라 및 프로세스는 민감한 ID 데이터를 안전하게 처리하도록 구축되어 규정 준수 부담 및 위험을 줄입니다.
• 최소한의 데이터 노출: Didit의 아키텍처는 프라이버시를 고려하여 설계되었습니다. 생체 인식 확인을 위해 셀카는 메모리에서 처리되고 삭제되며, 애플리케이션은 원시 생체 인식 데이터가 아닌 부울 값(예: '확인됨')을 수신합니다. 이는 임베드 가능한 구성 요소 내에서 처리되는 민감한 정보를 최소화합니다.

Didit의 사전 구축된 안전한 임베드 가능한 솔루션을 사용함으로써 기업은 iFrame 보안 전문가가 되지 않고도 고급 ID 확인을 통합하여 사용자 신뢰와 데이터 보호를 보장하면서 핵심 제품에 집중할 수 있습니다.

시작할 준비가 되셨습니까?

iFrame을 보호하는 것은 복원력 있고 신뢰할 수 있는 웹 애플리케이션을 구축하는 데 중요한 단계입니다. 샌드박싱, CSP, X-Frame-Options 및 안전한 postMessage() 관행을 부지런히 적용함으로써 사용자 또는 애플리케이션을 불필요한 위험에 노출시키지 않고 임베드된 콘텐츠의 강력한 기능을 활용할 수 있습니다. Didit의 안전한 ID 확인 솔루션을 탐색하여 워크플로우에 강력한 보안을 통합하는 것이 얼마나 쉬운지 확인하십시오.

Didit 가격 보기 | Didit 문서 탐색 | 데모 체험