위험도 · 치명적

service_role 키 노출

모든 보안 규칙을 무시하는 마스터 키가 브라우저 번들에 박히면, 데이터베이스 전체가 사실상 공개됩니다.

이게 무슨 문제인가요?

Supabase 의 service_role 키는 RLS 를 포함한 모든 접근 규칙을 무시하는 관리자(마스터) 키입니다. 서버 안에서만 써야 하는데, 환경 변수 이름을 NEXT_PUBLIC_(또는 프레임워크의 공개 접두사)로 시작하면 빌드 결과물(브라우저로 내려가는 JS 번들)에 그대로 박혀 누구나 볼 수 있게 됩니다.

왜 위험한가요?

이 키를 손에 넣은 사람은 RLS·인증을 전부 무시하고 데이터베이스 전체를 읽고, 쓰고, 지울 수 있습니다. 사실상 데이터베이스 관리자 권한을 통째로 넘겨주는 것과 같습니다. 한 번 번들에 노출되면 이미 유출됐다고 가정해야 합니다.

내 앱도 해당되나요?

브라우저 개발자 도구의 Network/Sources 에서 앱 번들에 service_role 문자열이나 eyJ로 시작하는 긴 토큰(JWT)이 있는지 확인합니다. 토큰을 디코드했을 때 role 값이 service_role이면 위험합니다. 정확한 판별이 어렵다면 전문가 점검을 받는 것이 안전합니다.

어떻게 고치나요?

1
유출로 간주하고 키 즉시 회전
노출이 확인되면 이미 유출된 것으로 보고, Supabase 대시보드(Settings → API)에서 service_role 키를 즉시 새 키로 회전(rotate)합니다.
2
클라이언트에서 키 제거
환경 변수에서 공개 접두사(NEXT_PUBLIC_ 등)를 떼고, service_role 키를 서버 전용 변수로 옮깁니다. 클라이언트 코드에서는 절대 참조하지 않습니다.
3
프론트는 anon 키 + RLS 로만
브라우저에서 필요한 작업은 anon 키와 RLS 정책으로 처리합니다. 관리자 작업이 필요하면 서버(엣지 함수/백엔드)에서만 service_role을 사용합니다.
4
재배포 후 번들 재확인
수정 후 다시 배포하고, 새 번들에 키가 더 이상 포함되지 않는지 확인합니다. 값이 빌드 시점에 박히므로 재배포가 필수입니다.
5
유출 기간 접근 점검
키가 공개돼 있던 기간 동안의 의심스러운 데이터 접근·변경 흔적을 점검합니다.

자주 묻는 질문

anon 키와 뭐가 다른가요?

anon 키는 RLS 의 통제를 받는 공개용 키라 노출돼도 RLS 가 막아줍니다. 반면 service_role 키는 RLS 를 무시하는 마스터 키라, 노출되면 막아줄 안전장치가 없습니다.

NEXT_PUBLIC_ 에 넣으면 왜 위험한가요?

NEXT_PUBLIC_ 같은 공개 접두사가 붙은 환경 변수는 빌드 시 브라우저 번들에 그대로 포함됩니다. 마스터 키를 여기에 넣으면 전 세계에 공개하는 것과 같습니다.

키를 회전하면 앱이 멈추나요?

서버에서 키를 새 값으로 교체·재배포하면 정상 동작합니다. 잠깐의 교체 작업만 필요하며, 노출된 마스터 키를 그대로 두는 위험에 비할 바가 아닙니다.