웹사이트 빌더가 API 키를 보관하고 있을 때: STUDIO 침해 사고

게시일 2026-10-19

2026년 10월 16일, 일본에서 널리 쓰이는 노코드 웹사이트 빌더 STUDIO(studio.design)가 무단 접근에 관한 공지를 발표했습니다(10월 18일 갱신). 제3자가 STUDIO 기능의 취약점을 악용하여 회사의 클라우드 환경에 접근했다는 내용입니다. 현재까지 확인된 접근 기간은 2026년 9월 30일부터 10월 1일(일본 시간)까지입니다. STUDIO는 10월 13일에 이를 발견하고 13~14일에 침입 경로를 차단했습니다. 데이터가 실제로 유출되었는지는 확인되지 않았지만, STUDIO는 유출된 것으로 간주하고 대응하고 있으며 일본 개인정보보호위원회에도 보고했습니다.

ITmedia 보도에 따르면 STUDIO 사용자는 90만 명이 넘습니다. 대부분은 이를 비밀번호 유출로 받아들일 것입니다. 그러나 많은 사이트에 더 큰 문제는 API 키입니다.

노출되었을 수 있는 정보

• 계정 정보: 사용자 이름, 이메일 주소, 해시된 비밀번호.
• 디자인 에디터와 CMS 콘텐츠, 폼 제출 내용, Live Preview URL.
• API 연동(Data Connect, API Connect 베타)에 등록한 외부 서비스의 API 키와 토큰.
• Google 스프레드시트 연동 인증 정보, 사용자 지정 프록시 키, reCAPTCHA v3 설정, Webhook 알림 URL.
• 비밀번호로 보호된 페이지의 비밀번호(해시 처리됨).

일부는 암호화되어 저장되어 있었지만 복호화에 필요한 키에도 접근이 있었기 때문에, 읽혔을 가능성이 있다고 STUDIO는 설명합니다. STUDIO는 10월 14일에 Google 스프레드시트 연동 키를 갱신했고, 17일에 폼 제출 내용과 API 키의 암호화 키를 교체했습니다. 결제 정보는 대상에 포함되지 않았습니다.

비밀번호 유출보다 심각한 이유

다른 서비스에서 콘텐츠를 가져오는 웹사이트 빌더는 그 서비스의 키를 보관해야 합니다. STUDIO 사이트가 Data Connect를 통해 microCMS에서 글을 읽어 오거나, OpenAI를 호출하거나, Google과 연동하고 있었다면 각 서비스의 키가 STUDIO 안에 있었던 것입니다. 그 사본을 가진 사람은 STUDIO를 거치지 않고 해당 서비스에 키를 직접 사용할 수 있습니다.

STUDIO 비밀번호를 바꿔도 이 키들에는 아무 효과가 없습니다. 키는 하나씩 각 공급업체에서 교체해야 합니다. 공급업체에서 새 키를 발급하고, STUDIO에 붙여넣은 다음, 이전 키를 폐기합니다. 게다가 이전 키가 STUDIO 안에만 있는 경우는 드뭅니다. 같은 값이 .env 파일, 서버, 누군가의 노트북에 있는 스크립트에도 들어 있는 경우가 많습니다. 이전 키를 폐기하기 전에 이 모든 사본을 새 키로 바꾸지 않으면 다른 곳이 작동을 멈춥니다.

지금 해야 할 일

STUDIO는 고객에게 다음 조치를 요청하고 있습니다. 대부분의 사이트에서는 세 번째 항목이 작업의 중심이 됩니다.

1. 이메일로 로그인한다면 STUDIO 비밀번호를 변경하고, 같은 비밀번호를 쓰는 다른 곳에서도 변경하십시오.
2. Live Preview URL을 삭제하고 다시 발급하십시오.
3. STUDIO에 저장한 외부 서비스의 API 키와 토큰을 모두 교체하십시오. 공급업체에서 새 키를 발급하여 STUDIO에 붙여넣고, 같은 키를 사용하는 다른 모든 곳을 갱신한 뒤 이전 키를 폐기하십시오. 각 공급업체의 로그와 청구 내역을 9월 30일부터 확인하여 알 수 없는 사용이 없는지 살펴보십시오.
4. 비밀번호로 보호된 페이지의 비밀번호를 변경하십시오.
5. Google 스프레드시트: 동기화를 중지(Stop Sync)하고, Google 계정의 연결된 앱에서 STUDIO를 삭제한 다음, 연동을 다시 설정하십시오.
6. 사용자 지정 프록시: 새 프록시 키로 전환하고, 10월 16일 이메일을 받은 날로부터 30일 이내에 STUDIO에 알리십시오.
7. Webhook 알림 URL을 변경하십시오.
8. STUDIO 비밀번호를 묻는 연락은 피싱으로 간주하십시오.

FrontierStack이 돕는 방법

FrontierStack은 STUDIO 내부를 변경할 수 없습니다. 그러나 다음 업데이트부터는 어떤 사이트가 영향을 받는지 알려 주고, 대응이 잊히지 않도록 합니다.

• STUDIO로 만든 사이트를 찾습니다. 도메인 상태가 각 홈페이지의 generator 태그를 읽기 때문에, STUDIO로 만든 사이트에는 호스트로 STUDIO가 표시됩니다. Wix, Webflow, Framer도 같은 방식으로 식별합니다. 해당 빌더에 최근 침해가 있었다면 도메인에 “침해된 빌더”가 표시됩니다.
• 체크리스트를 눈앞에 둡니다. 사이트 패널의 배너에 영향을 받는 도메인이 나열되고, 공급업체의 대응 절차가 체크리스트로 표시되며 진행 상황이 저장됩니다. 처리 완료로 표시할 때까지 보안 알림이 계속 유지됩니다.
• iPhone에도 전달됩니다. 알림은 FrontierStack의 푸시 릴레이를 통해 페어링한 iPhone에 전용 “공급업체 침해” 알림으로 전달됩니다. 알림에는 내용이 담기지 않으며, 도메인 이름이나 키 이름이 Mac 밖으로 나가지 않습니다.
• “영향을 받았는가?”에 답합니다. AI 관리자에는 공급업체 침해를 조회하는 읽기 전용 도구가 있어, 어떤 사이트가 해당되는지 물어볼 수 있습니다.
• KeyRotate로 이어집니다. KeyRotate에서 키 확인…을 선택하면 해당 침해를 연 상태로 KeyRotate가 열립니다.
• 앱 업데이트를 기다리지 않습니다. 새로운 침해 정보는 Enfour가 서명한 권고로 전달되며, 앱에 내장된 키로 검증됩니다.

FrontierStack에는 STUDIO 전용 패널도 있습니다. STUDIO의 공개 상태 페이지(Hosted Websites, Editor, Dashboard, Live Preview, Store)를 인증 정보 없이 감시하고, 장애가 발생하면 알림을 보냅니다. 자세한 내용은 맥에서 STUDIO를 참조하십시오.

KeyRotate가 돕는 방법

KeyRotate는 API 키를 보관하고, 각 키를 어떤 파일과 서버가 사용하는지 파악합니다. 다음 KeyRotate 업데이트는 이번 침해로 드러난 부분, 즉 웹 서비스에 직접 붙여넣은 키까지 다룹니다.

• 키를 붙여넣은 곳을 기록합니다. 키마다 붙여넣은 웹 서비스를 등록할 수 있습니다. 대상은 STUDIO, Wix, Webflow, Framer, Bubble, Zapier, Make, n8n Cloud, Vercel, Netlify, Retool입니다. 교체가 끝나면 KeyRotate가 새 키를 그곳에 붙여넣도록 알려 줍니다.
• 아직 노출된 키를 보여 줍니다. 이 서비스들 중 하나가 침해되면, 침해가 차단된 이후 값을 교체하지 않은 키에 “공급업체 침해로 노출”이 표시되고 확인 필요 목록 맨 위에 나타납니다. 침해 이후에 키를 KeyRotate에 추가한 것은 교체한 것으로 간주하지 않습니다.
• 한 번에 교체합니다. 개요의 카드에서 STUDIO에 저장한 키를 선택합니다. 이어서 노출된 키 교체…를 선택하면 Touch ID 한 번으로, 공급업체 API가 새 키를 발급할 수 있는 노출된 키를 모두 새로 발급하고, 그 키를 사용하는 파일(.env 파일, 설정 파일, 서버)을 갱신 대상으로 표시합니다. 이 방법으로 발급할 수 없는 키에는 공급업체 콘솔 링크가 표시됩니다.
• 이전 키는 그대로 둡니다. STUDIO는 새 키를 붙여넣을 때까지 이전 키를 계속 사용하므로, KeyRotate는 이전 키를 자동으로 폐기하지 않습니다. 사이트가 새 키로 작동하는 것을 확인한 뒤 직접 폐기하십시오.
• 끝날 때까지 알려 줍니다. 노출된 키가 남아 있는 동안 3일마다 알림을 보내며, 직접 운영하는 ntfy나 Gotify 서버가 있다면 그곳에도 보냅니다. STUDIO의 나머지 절차는 같은 카드에 체크리스트로 표시됩니다.

한계도 있습니다. 두 앱 모두 STUDIO에 키를 써 넣을 수 없으며, 그 작업은 직접 하셔야 합니다. KeyRotate는 체크하기 전까지 어떤 키가 STUDIO에 있었는지 알 수 없습니다. 또한 모든 공급업체의 API가 새 키를 발급할 수 있는 것은 아니므로, 공급업체 콘솔에서 작업해야 하는 경우도 있습니다. KeyRotate의 기능도 참조하십시오.

여기서 얻는 교훈

키를 붙여넣은 서비스는 모두 그 키가 유출될 수 있는 곳이 됩니다. 다음 침해의 피해를 줄이는 세 가지 습관을 권합니다.

• 키를 어디에 붙여넣었는지 목록으로 관리하십시오. 가지고 있는 키뿐 아니라 어떤 사이트 빌더, 자동화 도구, 호스팅 대시보드가 사본을 가지고 있는지 기록하십시오. 그중 하나가 침해되면 교체할 키 목록이 이미 준비되어 있습니다.
• 권한을 좁힌 키를 사용하십시오. CMS 하나만 읽을 수 있는 키나, 사용 한도를 정한 API 하나만 호출할 수 있는 키는 복사되더라도 가치가 훨씬 낮습니다. 웹사이트 빌더에는 내부 업무용 키가 아니라 그 사이트 전용으로 만든 키를 주십시오.
• 정기적으로 교체하십시오. 몇 달마다 교체하는 키는 유출되더라도 쓸 수 있는 기간이 짧습니다. 평소에 익숙한 교체 작업이라면 갑자기 급해졌을 때도 빠르게 진행할 수 있습니다.

함께 읽을 글(영어): STUDIO 사용자가 더 큰 피해를 입은 이유(Matthew Ketchum, LinkedIn), 이번 침해 정리(Substack).