AI 코딩으로 하루 만에 만든 서비스가, 하루 만에 전체 회원 DB를 통째로 내주는 일이 실제로 벌어진다.
공격 코드도 필요 없다. 브라우저 개발자 도구를 열고, 프런트엔드가 이미 쓰고 있는 키를 그대로 복사해 요청 한 번 보내면 된다.
SENTRIX가 AI 기반 웹서비스를 진단하면서 반복적으로 마주치는 데이터 유출 원인은 대부분 정교한 해킹이 아니다.
"설정을 안 켰거나, 안 지웠거나, 방치한" 세 가지다. 하나씩 원리와 자가 점검법을 짚는다.
실수 1 — Supabase RLS 미설정: 익명 키로 전체 테이블이 뚫린다
왜 위험한가
Supabase는 프런트엔드에서 쓰라고 anon(익명) 키를 공개적으로 내준다. 이 키는 노출돼도 "설계상 괜찮은" 키다. 단, 전제 조건이 있다 — 테이블마다 RLS(Row Level Security)가 켜져 있고 정책이 걸려 있을 때만.
문제는 AI 코딩 도구가 테이블을 만들 때 RLS를 자동으로 켜주지 않는 경우가 많다는 점이다. Data API에 노출된 테이블에서 anon 역할에 권한이 부여돼 있고 RLS가 꺼져 있으면, anon 키만으로 그 권한 범위의 조회·추가·수정·삭제가 행 제한 없이 허용된다.
즉 공격자는 이렇게 한다.
- 브라우저 개발자 도구 → Network 탭에서 이미 노출된 프로젝트 URL과 anon 키 확보
- https://[프로젝트ID].supabase.co/rest/v1/users?select=* 같은 요청 전송
- 회원 이메일·전화번호·주소·결제정보가 통째로 응답
키가 "공개용"이라는 사실과, 그 키로 "전체 데이터가 조회된다"는 사실은 완전히 다른 이야기다. 역할 권한과 RLS 정책이 함께 그 경계를 지키는데, RLS가 꺼져 있으면 행 단위 경계가 사라진다.
자가 점검법
- Q. RLS가 켜져 있는지 30초 안에 확인하려면?
- A. Supabase 대시보드 → Table Editor에서 각 테이블을 보면 RLS 상태 뱃지가 표시됩니다. "Unrestricted" 또는 RLS 비활성 경고가 뜬 테이블이 하나라도 있으면 즉시 위험 대상입니다.
- Q. 실제로 뚫리는지 직접 테스트하려면?
- A. 로그아웃 상태(비인증)에서 anon 키만으로 민감 테이블에
select=*요청을 보내보세요. 비공개여야 할 데이터가 나오면 RLS가 꺼져 있거나 익명 조회를 허용하는 정책이 있는 것이니 접근통제 설정을 확인하세요. 사내 관리자 계정 없이도 조회되면 그대로 유출 경로입니다.
점검 순서:
1. 모든 테이블 RLS ON 확인 (예외 없이 전부)
2. 테이블별 정책이 "본인 데이터만" 범위로 걸려 있는지 확인
3. service_role 키는 절대 프런트엔드에 노출되지 않았는지 확인
실수 2 — 프런트엔드 번들에 박힌 시크릿
왜 위험한가
.env 파일에 넣었으니 안전하다고 생각하기 쉽다. 하지만 프런트엔드 빌드에서 NEXT_PUBLIC_, VITE_, REACT_APP_ 접두사가 붙은 환경변수는 전부 브라우저 번들에 그대로 박힌다.
여기에 실수로 들어가는 것들:
- Supabase service_role 키 (RLS를 우회하는 마스터 키)
- 결제 PG 시크릿 키, 외부 API 서버 키
- 관리자 엔드포인트 토큰
공격자는 배포된 JS 번들을 내려받아 문자열 검색만 하면 된다. 소스맵이 열려 있으면 원본 코드까지 복원된다.
자가 점검법
| 점검 항목 | 확인 방법 |
|---|---|
| 번들 내 시크릿 문자열 | 배포된 사이트에서 개발자 도구 → Sources → JS 파일에서 service_role, secret, sk_ 검색 |
| 소스맵 노출 | https://사이트/.../main.js.map 접근 시 원본 코드가 보이면 위험 |
| 공개돼선 안 될 키 구분 | anon/publishable = 공개 OK / service_role·secret = 절대 프런트 금지 |
원칙은 단순하다. "브라우저가 볼 수 있는 곳에 있는 키는 이미 공개된 키"다. RLS 우회 키·결제 키·서버 키는 반드시 백엔드(서버리스 함수, API 라우트) 뒤에 숨겨야 한다.
실수 3 — 방치된 서브도메인
왜 위험한가
staging. dev. test. old. 같은 서브도메인은 개발 중에 만들어 놓고 잊힌다. 이 방치된 자산이 유출의 뒷문이 된다.
- 스테이징 환경엔 보안 설정이 느슨하다 — RLS 미적용, 디버그 모드 ON, 실데이터 복사본 존재
- 서브도메인 탈취(Subdomain Takeover) — 삭제된 클라우드 리소스를 가리키는 DNS 레코드가 남아 있으면, 공격자가 그 리소스를 선점해 정식 도메인처럼 피싱에 악용
- 오래된 배포본이 이미 패치된 취약점을 그대로 노출
운영 도메인만 열심히 지키고, 서브도메인은 아무도 안 본다. 공격자는 정확히 그 지점을 먼저 본다.
자가 점검법
- 보유 도메인의 전체 서브도메인 목록을 뽑는다 (인증서 투명성 로그·DNS 조회 기반)
- 각 서브도메인이 지금도 살아있는 목적이 있는지 확인 — 없으면 DNS 레코드 삭제
- 살아있는 스테이징/개발 서브도메인은 접근 제한(IP 화이트리스트·인증) 적용
- 실데이터 복사본이 스테이징에 남아있지 않은지 확인
3가지를 한 번에: 자동 탐지가 필요한 이유
세 가지 모두 "한 번 보면 알 수 있는" 문제다. 하지만 배포할 때마다, 서브도메인이 늘 때마다, 키가 추가될 때마다 다시 새어 나온다. 사람이 매번 손으로 점검하기엔 놓치는 지점이 생긴다.
SENTRIX의 CodeScan은 URL 하나만 넣으면 30초 안에 20여 개 항목을 자동 점검한다. 위 3대 실수도 여기에 포함된다.
- 노출된 API 키·시크릿 문자열 탐지
- 인증 없이 접근되는 엔드포인트·데이터 노출 점검
- 외부 노출 자산(서브도메인 포함) 스캔
무료 URL 스캔은 IP당 시간당 10회까지 이용할 수 있고, 정기 모니터링이 필요하면 Pro(월 29,900원)로 확장한다.
자동 스캔으로 1차로 걸러낸 뒤, RLS 정책 설계·권한 구조처럼 사람이 판단해야 하는 영역은 SENTRIX 보안 컨설팅(수동 모의해킹)으로 깊게 파고들 수 있다. SENTRIX는 2025 식약처 주최 AI 레드팀 챌린지 최우수상(구성원), 국가취약점(KVE-2024-0142 인증우회 등) 제보 실적을 가진 공격자 관점 진단 전문 기업이다.
오늘 바로 할 것 (요약 체크리스트)
- ☐ Supabase 모든 테이블 RLS ON + 정책 확인
- ☐
service_role키가 프런트 번들·.env(공개 접두사)에 없는지 확인 - ☐ 배포된 JS 번들에서 시크릿 문자열·소스맵 노출 검색
- ☐ 전체 서브도메인 목록화 → 미사용 DNS 레코드 삭제
- ☐ 스테이징/개발 환경에 실데이터·디버그 모드 방치 여부 확인
AI로 빠르게 만든 서비스일수록, 출시 전 외부 노출을 점검하고 발견된 문제부터 조치해야 한다.
- 지금 확인 → codescan.kr 30초 무료 스캔
- 상담 → SENTRIX 문의하기 (영업일 24시간 내 회신)