라떼군 이야기
Vue.js도 뚫렸다? 프론트엔드에 방치된 39개의 Algolia 어드민 API 키 추적기
TL;DR 한 보안 연구원이 유명 오픈소스 문서 사이트들을 조사해 39개의 Algolia 어드민 API 키가 프론트엔드에 노출된 것을 발견했습니다. 개발자가 자체 크롤러를 설정하면서 실수로 ‘읽기 전용’ 키 대신 ‘관리자’ 키를 프론트엔드에 주입한 것이 원인이며, 이를 악용하면 검색 결과를 조작해 피싱을 유도하거나 전체 검색 인덱스를 삭제할 수 있습니다.
우리는 종종 서드파티 서비스(SaaS)를 연동할 때 발급받은 API 키를 무심코 프론트엔드 환경 변수에 넣곤 합니다. 특히 정적 문서 사이트에서 검색 기능을 구현할 때 많이 쓰이는 Algolia DocSearch의 경우, 이 사소한 실수가 치명적인 보안 취약점으로 이어질 수 있습니다. 한 보안 연구원이 Vue.js 공식 문서에서 어드민 키가 노출된 것을 발견한 후, 15,000개의 사이트를 스크래핑하여 동일한 취약점을 가진 39개의 대형 오픈소스 프로젝트를 찾아냈습니다. 이는 단순한 해프닝을 넘어 프론트엔드 환경 변수 관리의 중요성을 다시 한번 일깨워주는 흥미로운 사례입니다.
핵심 내용
연구원은 Algolia의 공개 저장소를 기반으로 15,000개의 배포된 문서 사이트를 스크래핑하고, TruffleHog를 이용해 Git 히스토리까지 분석하여 총 39개의 활성화된 어드민 키를 찾아냈습니다. 놀랍게도 이 중 35개는 소스 코드가 아닌 배포된 프론트엔드 사이트에서 직접 추출되었는데, 이는 빌드 과정에서 환경 변수로 주입되었기 때문입니다. 노출된 키들은 단순한 검색을 넘어 인덱스 추가, 삭제, 설정 변경 등의 막강한 권한을 가지고 있었습니다. Home Assistant, KEDA 같은 대형 프로젝트도 포함되어 있었으며, 악의적인 공격자가 이를 이용해 검색 결과에 피싱 링크를 심거나 검색 시스템 자체를 마비시킬 수 있는 위험한 상태였습니다. 이 문제의 근본 원인은 프로젝트들이 자체 크롤러를 운영하면서, 프론트엔드에는 ‘검색 전용 키’를 넣어야 한다는 사실을 간과하고 ‘쓰기/관리자 키’를 그대로 사용했기 때문입니다.
기술적 인사이트
소프트웨어 엔지니어 관점에서 이 사건은 ‘비밀키 관리(Secret Management)‘의 사각지대를 정확히 짚어냅니다. 많은 개발자들이 Git 저장소에 키를 하드코딩하지 않으면 안전하다고 믿지만, CI/CD 파이프라인에서 주입된 환경 변수가 클라이언트 사이드 번들(JS)에 포함되어 배포된다면 결국 퍼블릭에 노출되는 것과 같습니다. 특히 Algolia처럼 읽기와 쓰기 권한이 분리된 토큰 시스템을 제공함에도 불구하고, 편의성이나 설정의 복잡성 때문에 마스터 키나 어드민 키를 남용하는 ‘최소 권한의 원칙(PoLP)’ 위반 사례가 빈번함을 보여줍니다. 이는 SaaS 연동 시 제공자가 아무리 안전한 구조를 만들어두어도, 이를 소비하는 클라이언트 측의 오설정이 대규모 보안 위협으로 이어질 수 있다는 ‘공유 책임 모델’의 딜레마를 보여주는 전형적인 기술적 트레이드오프입니다.
시사점
이 사례는 당장 우리 팀의 프론트엔드 환경 변수 설정과 배포 파이프라인을 점검해봐야 할 강력한 동기를 부여합니다. VUE_APP_, REACT_APP_, NEXT_PUBLIC_ 등의 접두사가 붙어 클라이언트에 노출되는 환경 변수에는 절대 쓰기/수정 권한이 있는 API 키가 들어가서는 안 됩니다. 또한, 보안 스캐닝 툴을 CI 과정에 도입하여 커밋 히스토리뿐만 아니라 빌드 결과물(정적 파일)에 대한 검증도 수행하는 등, 방어적이고 선제적인 보안 프로세스 구축이 필수적입니다.
우리 서비스의 프론트엔드 코드에 숨겨진 시한폭탄은 없을까요? 서드파티 API를 연동할 때 단순히 ‘동작하는 것’에 만족하지 않고, 해당 키가 가진 권한의 범위가 적절한지 끊임없이 의심하는 습관이 필요합니다.