Supabase API 키, 얼마나 위험한가요?
Supabase는 Firebase 대안으로 급부상한 BaaS(Backend as a Service) 플랫폼입니다. 빠른 개발이 가능하고 문서도 잘 되어 있어 1인 개발자와 스타트업에서 많이 씁니다. 그런데 바로 그 편의성이 보안 허점을 만들기도 합니다.
Supabase 프로젝트에는 두 가지 핵심 키가 있습니다. anon key(공개 클라이언트용)와 service_role key(서버 전용 관리자 키)입니다. 특히 service_role key가 노출되면 RLS(Row Level Security) 정책을 완전히 우회하여 전체 데이터베이스에 접근, 수정, 삭제가 가능합니다.
실제로 어떤 피해가 생기나요?
2023년 이후 GitHub에서 Supabase 키가 노출되어 발생한 사고들이 꾸준히 보고되고 있습니다. 대표적인 피해 유형은 다음과 같습니다.
- 사용자 데이터 탈취: 회원 이메일, 전화번호, 개인정보 전체 덤프
- 데이터 삭제/변조: 경쟁자나 악의적 공격자에 의한 서비스 파괴
- Storage 무단 접근: 업로드된 파일, 이미지, 문서 탈취
- Auth 우회: 임의 계정 생성 및 관리자 권한 탈취
GitHub에 코드를 올리는 순간, GitHub Secret Scanning이나 제3자 봇들이 자동으로 키를 탐지합니다. 공개 저장소라면 수 분 안에 악용될 수 있습니다.
노출 경로 3가지
1. 소스 코드에 직접 하드코딩
// 절대 하면 안 되는 예시
const supabase = createClient(
'https://xxxxx.supabase.co',
'eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...' // service_role key 직접 삽입
)
AI가 빠른 예시를 보여주다가 이런 코드를 생성하는 경우가 많습니다. 그대로 커밋하면 끝납니다.
2. .env 파일을 .gitignore에 등록하지 않음
.env 파일에 키를 관리해도 .gitignore에 등록하지 않으면 GitHub에 그대로 올라갑니다. 특히 저장소를 처음 만들 때 .gitignore 설정을 빠뜨리는 실수가 자주 발생합니다.
3. 프론트엔드 빌드 파일에 포함
Next.js, Vite 같은 빌드 도구에서 환경 변수 앞에 NEXT_PUBLIC_ 또는 VITE_를 붙이면 클라이언트 번들에 포함됩니다. service_role key를 이런 방식으로 노출하면 브라우저 개발자 도구로 바로 볼 수 있습니다.
실전 방어 방법
환경 변수로 관리
# .env.local (절대 커밋 금지)
SUPABASE_URL=https://xxxxx.supabase.co
SUPABASE_ANON_KEY=eyJ...
SUPABASE_SERVICE_KEY=eyJ... # 서버에서만 사용
# .gitignore에 반드시 추가
.env
.env.local
.env.*.local
RLS(Row Level Security) 정책 활성화
anon key가 노출되더라도 RLS가 제대로 설정되어 있다면 피해를 최소화할 수 있습니다. Supabase 대시보드에서 모든 테이블에 RLS를 활성화하고, 필요한 접근만 허용하는 정책을 설정하세요.
키 노출 여부 정기 점검
이미 코드를 GitHub에 올렸다면 즉시 Supabase 대시보드에서 키를 재생성(rotate)해야 합니다. 이전 키는 자동으로 무효화됩니다. CodeScan 같은 보안 점검 도구를 사용하면 사이트에서 API 키나 시크릿이 외부로 노출되고 있는지 자동으로 탐지할 수 있습니다.
정리
Supabase는 훌륭한 도구입니다. 다만 편의성이 높은 만큼 보안 실수도 쉽게 일어납니다. 키 관리 규칙 하나만 잘 지켜도 대부분의 사고를 예방할 수 있습니다. service_role key는 반드시 서버에서만, anon key는 RLS와 함께 사용하는 것이 원칙입니다.