위험도 · 높음

anon 키 노출 — 정상일까, 위험일까

anon 키는 공개되도록 만들어진 키입니다. 진짜 위험은 키가 보이는 것 자체가 아니라, 그 키로 무엇이 가능한지에 달려 있습니다.

이게 무슨 문제인가요?

Supabase 의 anon(공개) 키는 설계상 브라우저에 노출돼도 되는 publishable 키입니다. 그래서 "키가 보인다"는 사실만으로는 취약점이 아닙니다. 문제가 되는 경우는 두 가지입니다: (1) RLS 가 없어서 그 공개 키로 데이터 전체에 접근되는 경우, (2) 환경 변수 이름은 anon인데 실제 값으로 service_role을 잘못 넣어, 공개돼도 되는 줄 알았던 키가 사실은 마스터 키인 경우입니다.

왜 위험한가요?

(1)의 경우 공개 키 = 데이터베이스 전체 열림이고, (2)의 경우는 마스터 키 노출이라 데이터베이스 장악으로 이어집니다. 즉 "anon 키 노출"이라는 같은 겉모습 아래, 실제로는 치명적 문제가 숨어 있을 수 있습니다.

내 앱도 해당되나요?

노출된 키를 디코드해 role 필드가 anon인지 service_role인지 확인하세요. service_role이면 즉시 회전이 필요합니다. anon이 맞다면, RLS 가 모든 테이블에 적용돼 있는지 점검합니다.

어떻게 고치나요?

1
키의 실제 role 확인
노출된 JWT 를 디코드해 role을 확인합니다. service_role이면 마스터 키 노출이므로 즉시 회전하고 service_role 노출 대응을 따릅니다.
2
anon 이 맞으면 RLS 점검
role 이 anon이라면 키 노출은 정상 범위입니다. 대신 모든 공개 테이블에 RLS 정책이 있는지 점검해, 공개 키로 접근 가능한 데이터를 통제합니다.
3
환경 변수 이름과 값 일치 확인
NEXT_PUBLIC_SUPABASE_ANON_KEY 같은 변수에 정말 anon 값이 들어 있는지, service_role 값이 잘못 들어가지 않았는지 확인합니다. 이름과 실제 값이 어긋나는 실수가 의외로 흔합니다.
4
공개/비공개 키 분리 운영
공개해도 되는 키와 서버 전용 키를 코드·배포에서 명확히 분리하고, 서버 키는 빌드 산출물에 절대 포함되지 않게 합니다.

자주 묻는 질문

anon 키를 숨겨야 하나요?

숨길 필요는 없습니다. 브라우저에서 동작하려면 어차피 공개돼야 하는 키입니다. 보안은 키를 숨기는 게 아니라 RLS 로 "그 키로 무엇이 가능한지"를 통제해서 만듭니다.

노출됐는데 RLS 가 있으면 안전한가요?

role 이 진짜 anon이고 RLS 가 모든 테이블에 제대로 적용돼 있다면, anon 키 노출은 정상 범위입니다.

anon 과 service_role 을 어떻게 구분하나요?

키(JWT)를 디코드하면 role 필드에 anon 또는 service_role이 적혀 있습니다. 온라인 JWT 디코더나 개발자 도구로 확인할 수 있습니다.