postMessage 출처 검증 안 하면 생기는 일

1. postMessage를 사용할 때 왜 출처 검증이 중요한가

1) 브라우저 간 통신에서 자주 쓰이는 방식

웹에서는 서로 다른 페이지나 도메인 사이에서 데이터를 주고받아야 하는 상황이 꽤 많습니다. 이때 자주 사용되는 방식이 postMessage입니다. 특히 iframe 안의 콘텐츠와 부모 페이지가 통신해야 할 때 유용하게 쓰입니다.
문제는 편리한 만큼 origin검증을 생략하면 보안 위험이 생길 수 있다는 점입니다. postMessage는 구조상 외부 창이나 다른 출처의 메시지도 받을 수 있기 때문에, 누가 보낸 메시지인지 확인하지 않으면 예상치 못한 동작으로 이어질 수 있습니다.

2) 개발자들이 검색하는 이유

postMessage 관련 이슈는 기능 구현보다 보안 사고와 연결될 때 더 많이 주목받습니다. 처음에는 단순한 데이터 전달처럼 보이지만, 잘못 설계하면 민감한 정보가 노출되거나 잘못된 명령이 실행될 수 있습니다. 그래서 많은 개발자들이 postMessage, origin검증, iframe통신보안, 자바스크립트보안 같은 키워드를 함께 찾아보게 됩니다.
특히 외부 서비스와 연동하거나, 광고·결제·인증처럼 iframe을 활용하는 경우에는 기본적인 보안 점검이 더 중요해집니다.

3) 이 글에서 다룰 내용

이 글에서는 postMessage를 사용할 때 왜 출처 확인이 필요한지, 검증이 없으면 어떤 문제가 생길 수 있는지 살펴봅니다. 또 iframe통신보안 관점에서 실제로 주의해야 할 부분과, 자바스크립트보안 관점에서 점검하면 좋은 포인트도 함께 정리합니다.
단순히 “조심해야 한다”에서 끝내지 않고, 어떤 상황에서 origin검증이 필요한지 이해할 수 있도록 설명하겠습니다.

2. postMessage는 어떤 방식으로 동작하나

1) 메시지 전달의 기본 구조

postMessage는 한 창에서 다른 창으로 메시지를 보내는 브라우저 API입니다. 부모 창과 iframe, 혹은 서로 다른 도메인의 팝업 사이에서도 사용할 수 있습니다.
이 기능의 장점은 출처가 달라도 통신이 가능하다는 점인데, 바로 이 특성이 보안 측면에서는 주의가 필요한 이유가 됩니다.

2) iframe통신보안에서 자주 등장하는 이유

iframe통신보안이 중요한 서비스에서는 보통 부모 페이지가 iframe에게 명령을 보내거나, iframe이 부모에게 결과를 전달합니다. 예를 들어 결제창, 인증창, 문서 편집기, 외부 위젯 등이 대표적입니다.
이때 postMessage는 거의 표준처럼 쓰이지만, 메시지 내용을 믿어도 되는지 확인하는 과정이 빠지면 문제가 생깁니다. 단순히 “메시지가 왔다”는 사실만으로 처리하는 것은 위험할 수 있습니다.

3) 메시지 수신 쪽이 더 중요할 때가 많음

보통 postMessage를 보낼 때는 대상 창과 대상 출처를 어느 정도 지정할 수 있습니다. 하지만 실제 보안 사고는 메시지를 받는 쪽에서 발생하는 경우가 많습니다.
수신 측이 origin검증 없이 메시지 내용을 바로 처리하면, 공격자가 만든 페이지나 악성 iframe이 임의의 값을 보내는 상황도 생길 수 있습니다. 따라서 postMessage는 송신보다 수신 검증이 핵심이라고 보는 편이 좋습니다.

3. origin검증을 안 하면 생길 수 있는 문제

1) 잘못된 명령 실행

가장 흔한 위험은 의도하지 않은 명령이 실행되는 것입니다. 예를 들어 메시지로 “로그인 상태 확인”, “설정 변경”, “버튼 클릭 후속 처리” 같은 로직을 수행한다면, 신뢰할 수 없는 출처에서 보낸 값도 같은 방식으로 처리될 수 있습니다.
이런 경우 사용자는 정상적으로 보이지만, 내부 동작은 공격자가 유도한 방향으로 흘러갈 수 있습니다.

2) 민감 정보 노출

origin검증이 없으면 응답 메시지에 포함된 정보가 외부로 새어 나갈 가능성도 있습니다. 예를 들어 토큰, 사용자 식별값, 내부 상태값을 메시지로 넘기는 구조라면, 이를 받아서는 안 되는 곳이 가져갈 수 있습니다.
특히 postMessage는 서로 다른 출처 간 통신을 전제로 하므로, “상대가 우리 페이지일 것”이라는 가정만으로는 충분하지 않습니다.

3) XSS와 결합될 수 있는 구조

postMessage 자체가 곧바로 XSS를 일으키는 것은 아니지만, 수신한 데이터를 그대로 DOM에 넣거나 스크립트처럼 처리하면 문제가 커집니다.
이럴 때 자바스크립트보안 관점에서 중요한 것은 “메시지 내용은 신뢰할 수 없는 외부 입력”으로 취급하는 것입니다. 출처 확인 없이 HTML 삽입, eval 사용, 동적 스크립트 처리로 이어지면 공격 가능성이 훨씬 높아집니다.

4) 운영 중인 서비스의 신뢰도 하락

보안 문제는 눈에 띄지 않게 쌓이다가 한 번에 드러나는 경우가 많습니다. postMessage의 origin검증이 빠진 상태로 서비스가 운영되면, 문제를 파악하기 전까지는 겉으로 정상처럼 보여도 내부적으로는 취약한 구조일 수 있습니다.
이런 상태가 길어지면 수정 범위도 커지고, 디버깅과 장애 대응 부담도 함께 늘어납니다.

4. iframe통신보안에서 꼭 확인할 점

1) 허용할 origin을 명확히 정하기

가장 기본적인 원칙은 허용할 출처를 명확하게 제한하는 것입니다. postMessage를 받을 때는 메시지의 origin이 예상한 도메인인지 비교해야 합니다.
와일드카드처럼 느슨하게 처리하면 편해 보일 수 있지만, 보안 관점에서는 가급적 피하는 편이 좋습니다. 실무에서는 운영 환경, 스테이징 환경, 외부 연동 도메인을 각각 분리해 관리하는 경우가 많습니다.

2) 메시지 형식도 함께 검증하기

출처만 맞다고 해서 모든 메시지를 받아도 되는 것은 아닙니다. 메시지 내용의 구조, 타입, 허용 가능한 값 범위도 함께 확인해야 합니다.
예를 들어 문자열 하나만 기대하는데 객체 전체가 들어오거나, 숫자만 와야 하는데 임의의 스크립트 조각이 들어오는 경우를 막아야 합니다. iframe통신보안은 출처와 데이터 형식을 같이 보는 것이 기본입니다.

3) 필요한 정보만 주고받기

메시지로 너무 많은 정보를 주고받는 구조는 위험합니다. 꼭 필요한 상태값만 전달하고, 민감한 정보는 별도 서버 검증을 거치는 방식이 더 안전한 편입니다.
postMessage는 편리한 보조 수단이지, 모든 인증과 권한 확인을 대신하는 도구는 아닙니다. 이 점을 분리해서 설계하는 것이 중요합니다.

4) 개발과 운영 환경을 분리해서 테스트하기

실제 사고는 운영 환경에서만 드러나는 경우가 많습니다. 로컬에서는 잘 되던 코드가 배포 후 외부 iframe과 연결되면서 문제가 생기기도 합니다.
그래서 iframe통신보안을 점검할 때는 개발용 도메인과 운영용 도메인의 origin이 제대로 구분되는지 함께 살펴보는 것이 좋습니다.

5. 자바스크립트보안 관점에서 함께 봐야 할 부분

1) 메시지 데이터를 DOM에 바로 넣지 않기

postMessage로 받은 값을 바로 innerHTML에 넣는 방식은 위험할 수 있습니다. 외부 입력을 HTML로 해석하게 되면 예상치 못한 스크립트 실행으로 이어질 수 있기 때문입니다.
이럴 때는 텍스트로 출력할지, 허용된 형식만 렌더링할지 명확히 정하는 편이 좋습니다.

2) 문자열 기반 실행 함수 피하기

eval, new Function, 동적 스크립트 삽입 같은 방식은 자바스크립트보안에서 특히 주의 대상입니다. postMessage로 받은 데이터가 이런 함수에 들어가면 취약점으로 연결되기 쉽습니다.
실무에서는 편의를 위해 이런 방식을 쓰는 경우도 있지만, 보안 점검에서는 우선적으로 제거 후보로 보는 편이 좋습니다.

3) 이벤트 리스너의 범위를 최소화하기

메시지를 받는 로직이 여러 곳에 흩어져 있으면 검증 누락이 생기기 쉽습니다. 한 곳에서만 origin검증과 데이터 검사를 수행하도록 구조를 정리하면 관리가 쉬워집니다.
자바스크립트보안은 특정 한 줄의 코드보다도, 검증이 일관되게 적용되는 구조를 만드는 것이 중요합니다.

4) 브라우저 보안 기능과 같이 보기

postMessage 문제는 단독으로만 보지 않고 CSP, 보안 헤더, 쿠키 설정, CORS 같은 기본 보안 요소와 함께 보는 것이 좋습니다.
웹사이트의 전반적인 기본 보안 상태를 빠르게 점검해주는 도구를 활용하면, postMessage 외에도 HTTPS 설정, 보안 헤더, 민감 정보 노출 같은 항목을 함께 확인하는 데 도움이 됩니다.

6. 실제로 점검할 때 유용한 체크포인트

1) 내가 받는 메시지 출처가 고정되어 있는가

가장 먼저 확인할 것은 메시지 출처가 명확히 정의되어 있는지입니다. 허용할 도메인이 정해져 있고, 코드에서 그 값을 비교하고 있어야 합니다.
이 부분이 없다면 origin검증이 사실상 빠져 있다고 봐도 됩니다.

2) 메시지 값이 검증된 뒤에만 처리되는가

메시지가 도착했다고 바로 처리하지 말고, 타입과 구조를 확인한 뒤에 분기해야 합니다.
예를 들어 type, action, status 같은 필드를 기준으로 허용 가능한 값만 처리하는 방식이 일반적입니다. 이 과정을 거치면 postMessage 기반 통신의 안정성이 높아집니다.

3) 민감한 값이 메시지로 오가지 않는가

토큰, 비밀번호, 개인 정보처럼 보안상 중요한 값은 가급적 메시지로 주고받지 않는 것이 좋습니다.
꼭 필요한 경우에도 서버 측 검증과 결합해 안전하게 설계해야 합니다. iframe통신보안은 편의보다 원칙이 우선인 영역입니다.

4) 잘못된 origin이나 예상 밖 데이터에 대한 처리 코드가 있는가

검증 실패 시 어떻게 처리할지도 중요합니다. 단순히 무시하는 수준을 넘어, 로그를 남기고 예외 상황을 추적할 수 있어야 합니다.
이런 기본적인 예외 처리가 있으면 운영 중 문제를 발견하기가 훨씬 수월합니다.

7. postMessage 출처 검증이 필요한 상황과 마무리

1) 이런 경우라면 특히 주의가 필요함

postMessage를 사용하면서 외부 iframe, 제휴사 페이지, 인증 창, 결제 모듈, 임베드 위젯 등이 포함된다면 origin검증은 거의 필수에 가깝습니다.
또한 메시지를 받아서 화면을 갱신하거나 권한을 바꾸거나, 내부 로직을 분기하는 구조라면 iframe통신보안과 자바스크립트보안을 함께 점검하는 것이 좋습니다. 이런 상황에서는 작은 실수도 보안 이슈로 이어질 수 있기 때문입니다.

2) 직접 전화와 비교했을 때의 차이

보안 이슈를 확인하거나 기능 상태를 점검할 때, 직접 전화로 물어보는 방식은 확인 범위가 제한적일 수 있습니다. 반면 postMessage처럼 브라우저에서 실제로 오가는 흐름을 보면, 어떤 출처에서 어떤 데이터가 전달되는지 더 구체적으로 파악할 수 있습니다.
즉, 직접 전화가 “현재 상태를 묻는 방법”에 가깝다면, postMessage 점검은 실제 통신 구조와 보안 설정을 함께 확인하는 방식에 가깝습니다. 이런 차이 때문에 웹사이트 기본 보안 상태를 살필 때는 origin검증 여부까지 함께 보는 것이 유용한 경우가 많습니다.

3) 결론적으로 어떤 상황에서 고려하면 좋은가

정리하면 postMessage는 편리하지만, origin검증이 빠지면 예상치 못한 메시지 수신과 잘못된 처리로 이어질 수 있습니다. 특히 iframe을 활용하는 서비스, 외부 연동이 많은 서비스, 민감한 상태값을 주고받는 서비스라면 iframe통신보안을 우선적으로 점검하는 편이 좋습니다.
기본적인 웹 보안 상태를 빠르게 확인하고 싶거나, 자바스크립트보안 관점에서 메시지 처리 흐름을 살펴보고 싶다면 이런 항목들을 함께 점검하는 방식이 도움이 됩니다.