Notion 공개 페이지가 편집자 이메일을 줄줄 새고 있다는 보안 경고

"공개"라는 단어의 함정

협업 도구 Notion에서 공개 페이지(public page)의 편집자 이메일 주소가 그대로 노출되는 취약점이 공개됐어요. weezerOSINT라는 보안 연구자가 X(트위터)에 이 문제를 공유하면서 알려졌는데요. 많은 팀과 개인이 블로그, 포트폴리오, 문서 공유용으로 Notion 공개 페이지를 쓰고 있다 보니 파급력이 작지 않은 사안이에요.

문제의 핵심은 이거예요. 누군가가 Notion 페이지를 "웹에 게시"해서 공개 상태로 만들면, 그 페이지를 편집한 적 있는 모든 사용자의 이메일 주소를 외부에서 조회할 수 있는 방식으로 데이터가 노출됩니다. 페이지 방문자는 볼 수 없지만, Notion의 내부 API를 특정 방식으로 호출하면 편집자 목록과 각자의 이메일이 딸려 나오는 구조인 거예요.

왜 이게 심각한 문제인가

먼저 이메일 주소가 왜 민감한지부터 짚어볼게요. 이메일은 단순한 연락 수단이 아니라, 대부분의 온라인 계정의 열쇠예요. 이메일이 공개되면 피싱 공격의 표적이 될 수 있고, 과거 유출된 비밀번호 데이터베이스와 대조해서 크리덴셜 스터핑(credential stuffing) 공격에 악용될 수도 있어요. 크리덴셜 스터핑이 뭐냐면, 다른 사이트에서 털린 이메일+비밀번호 쌍을 Notion이나 구글, 회사 내부 시스템에 자동으로 입력해보면서 들어갈 수 있는 계정을 찾는 공격이에요.

더 큰 문제는 OSINT(Open Source Intelligence) 관점의 위험이에요. 어떤 회사의 Notion 공개 블로그를 통해 편집자 이메일이 유출되면, 공격자는 그 회사의 직원 이메일 도메인 구조, 직원 명단, 조직 구성을 추측할 수 있어요. 예를 들어 firstname.lastname@company.com 같은 패턴이 드러나면, 그 회사의 누구든 이메일 주소를 추정할 수 있게 되거든요. 스피어 피싱(특정인을 노린 맞춤형 피싱)의 성공률이 극적으로 올라가는 거죠.

또 하나, 개인 크리에이터에게도 심각해요. Notion으로 익명 블로그를 운영하던 사람의 실명이 박힌 이메일이 노출되면, 신원 비식별성(pseudonymity) 이 한순간에 깨지거든요. 회사를 떠난 전 직원의 이메일이 여전히 과거 공개 페이지에 남아 있는 경우도 있고요.

기술적으로 어떤 구조인가

자세한 내부 API 동작은 책임 있게 공개되진 않았지만, 일반적인 패턴을 보면 대략 짐작이 가요. Notion은 페이지의 블록 구조, 편집 이력, 권한 정보를 JSON 형태로 API가 반환하는데요. 이 페이지 메타데이터에 편집자 식별 정보가 포함되어 있고, 공개 페이지의 경우 이 정보를 인증 없이도 가져올 수 있었던 게 원인으로 보여요. 즉, 권한 체크가 "페이지를 볼 수 있느냐"에만 걸려 있고, "편집자 정보를 볼 수 있느냐"에는 별도 체크가 없었던 셈이죠.

이런 종류의 버그를 업계에서는 BOLA(Broken Object Level Authorization) 또는 IDOR(Insecure Direct Object Reference) 의 변종으로 분류하곤 해요. OWASP API Security Top 10에서 항상 1~2위를 다투는 고전적이면서도 여전히 흔한 취약점 유형이에요. 기능 자체는 작동하는데, 접근 권한 체크만 빠져 있거나 부실한 경우죠.

비슷한 선례들

과거에도 비슷한 사례가 많았어요. 2018년 Google+의 API 버그로 5천만 명 사용자 정보가 노출됐고, 2021년에는 LinkedIn의 공개 프로필 스크래핑으로 7억 건 데이터가 유출됐어요. 더 가까운 예로는 Slack도 2022년에 워크스페이스 초대 링크를 통해 이메일이 일부 노출되는 문제가 있었고, Trello 역시 공개 보드에서 민감 정보 노출 이슈가 반복적으로 지적돼왔어요.

공통점은 명확해요. "편의성"과 "공유 기능"을 강화한 협업 도구일수록, 공개와 비공개의 경계가 흐려지고 뜻밖의 정보 노출이 생긴다는 거예요. 기능이 많아질수록 권한 매트릭스가 복잡해지고, 그 틈에서 IDOR 같은 버그가 새어 나오죠.

한국 개발자와 팀에게 주는 시사점

한국에서도 Notion은 스타트업, 중소기업, 심지어 대기업의 일부 팀에서까지 광범위하게 쓰이고 있어요. 채용 공고, 회사 소개, 제품 문서, 오픈소스 프로젝트 페이지를 Notion으로 관리하는 경우가 정말 많죠. 이번 사안을 계기로 몇 가지 점검을 권해드릴게요.

첫째, 지금 당장 회사/팀의 Notion 공개 페이지를 전부 목록화해보세요. 생각보다 많을 거예요. 그리고 각 페이지의 편집 이력에 퇴사자나 외부 협력자가 포함되어 있는지 확인하세요. 이메일 노출이 원치 않는 경우라면 해당 페이지를 비공개로 돌리거나, 내용을 새 페이지에 복사해서 편집자 이력을 초기화하는 방법을 고려할 수 있어요.

둘째, 공개 블로그/포트폴리오 용도라면 Notion이 최선인지 다시 생각해볼 만해요. 대안으로는 GitHub Pages + Jekyll/Hugo, Vercel + Next.js, 또는 Notion 콘텐츠를 정적 사이트로 빌드해서 배포하는 super.so 같은 서비스가 있어요. 이런 방식은 편집자 메타데이터가 최종 결과물에 포함되지 않아요.

셋째, 회사에서 API 기반 제품을 만들고 있다면 이번 사안을 자기 제품의 권한 모델을 재점검하는 계기로 삼으세요. "이 리소스를 볼 수 있는가"뿐 아니라, 그 리소스에 딸린 메타데이터 각각도 따로 권한을 체크하고 있는가를 확인해야 해요. 편집자 정보, 생성 시각, IP 주소, 워크스페이스 ID 같은 필드가 의도치 않게 새고 있을 수 있거든요.

마무리

"공개"라는 버튼은 생각보다 많은 것을 함께 공개할 수 있어요. 협업 도구를 쓸 때는 내가 공유한 콘텐츠뿐 아니라, 그 옆에 딸린 메타데이터까지 머릿속에 그려봐야 해요.

여러분 팀에서는 협업 도구의 공개 설정을 주기적으로 점검하고 있나요? 그리고 개인 정보 노출을 막기 위해 조직 차원에서 세운 규칙이 있다면 공유해주세요.