Supabase vs Firebase 보안 비교

둘 다 "안전하다"고 말하지만, 디테일은 다르다

Supabase와 Firebase 모두 강력한 보안 기능을 제공한다. 하지만 작동 방식이 근본적으로 달라서 "어느 쪽이 더 안전한가"라는 질문에는 정답이 없다. 안전을 결정하는 건 플랫폼이 아니라 설정하는 사람이다. SENTRIX 레드팀이 AI 코딩 도구로 만든 앱을 진단할 때 가장 많이 뚫리는 지점도 두 플랫폼의 기능 부재가 아니라, 개발자가 기본 설정을 그대로 두거나 편의상 규칙을 열어둔 흔적이다.

두 서비스는 접근 제어, 인증, 데이터 노출 방식이 다르기 때문에 실수하는 패턴도 다르다. 이 차이를 이해하면 내 스택에서 무엇을 먼저 점검해야 하는지가 분명해진다.

접근 제어 방식 비교

Supabase, RLS (Row Level Security)

Supabase는 PostgreSQL 위에 올라간 서비스라, 데이터 접근 제어도 PostgreSQL의 RLS(Row Level Security)를 그대로 쓴다. SQL 문법으로 "어떤 사용자가 어떤 행(row)에 접근할 수 있는지"를 정책(policy)으로 정의한다.

-- 본인 데이터만 조회 가능
CREATE POLICY "users_own_data" ON profiles
FOR SELECT USING (auth.uid() = user_id);

RLS는 강력하지만 테이블마다 직접 켜야 한다는 게 함정이다. 기본값이 비활성화(disabled)라, RLS를 켜지 않은 테이블은 anon key(공개 키)만으로도 전체 데이터가 읽힌다. 문제는 Supabase의 anon key가 프론트엔드 코드에 그대로 박혀 브라우저로 배포된다는 점이다. 즉 RLS가 꺼진 테이블은 "인증 없이 누구나 접근 가능한 공개 API"와 동일해진다.

공격자는 이렇게 악용한다. 개발자 도구 Network 탭을 열면 https://xxxx.supabase.co 형태의 프로젝트 URL과 anon key가 그대로 노출된다. 공격자는 이 두 값만 챙기면 브라우저 콘솔에서 다음 한 줄로 전체 테이블을 긁어간다.

// 공격자가 anon key만으로 실행 — RLS 미설정 테이블이면 전부 응답한다
fetch('https://xxxx.supabase.co/rest/v1/customers?select=*', {
  headers: { apikey: 'eyJhbGciOi...(노출된 anon key)' }
}).then(r => r.json()).then(console.log)
// [{ "name": "홍길동", "phone": "010-...", "email": "..." }, ...]

2025년 다수의 AI 코딩 플랫폼 발(發) 앱에서 RLS 미설정으로 고객 DB가 통째로 노출된 사건이 반복된 것도 정확히 이 구조 때문이다. 코드는 잘 돌아가고 화면도 멀쩡하지만, 뒤에서 데이터가 열려 있다.

Firebase, Security Rules

Firebase(Firestore/Realtime Database)는 JSON에 가까운 전용 Security Rules 언어를 쓴다. SQL이 아니라 컬렉션/문서 경로 단위로 읽기·쓰기 권한을 선언한다.

rules_version = '2';
service cloud.firestore {
    match /databases/{database}/documents {
        match /users/{userId} {
            allow read, write: if request.auth != null
                               && request.auth.uid == userId;
        }
    }
}

Firebase는 Supabase와 반대로 기본값이 "모두 거부"라 첫 배포 시점엔 오히려 안전하다. 진짜 위험은 개발 과정에서 발생한다. "왜 데이터가 안 나오지?"라며 디버깅하다가 편의상 아래처럼 전부 열어놓고, 그대로 배포해버리는 패턴이다.

// 절대 배포하면 안 되는 규칙 — 인증도 소유권도 검사하지 않는다
match /{document=**} {
    allow read, write: if true;
}

이 규칙이 살아있으면 Firestore REST API로 인증 토큰 없이 컬렉션 전체를 읽고 쓸 수 있다. 더 나아가 allow write: if true는 공격자가 남의 데이터를 덮어쓰거나 삭제할 수 있게 만든다. 읽기 노출보다 파괴적이다. Firebase는 콘솔 상단에 "Your security rules are defined as public"이라는 경고 배너를 띄우지만, 배포 압박 속에서 이 경고는 쉽게 무시된다.

정리: 실수의 방향이 다르다

• Supabase: 기본이 열림 → "켜는 걸 깜빡"해서 뚫린다. (누락형 실수)
• Firebase: 기본이 닫힘 → "편의상 열어놓고" 그대로 배포해서 뚫린다. (방치형 실수)

어느 쪽이든 결과는 같다. 인증 없이 데이터가 열린다. 그래서 "무엇을 점검하느냐"도 플랫폼별로 달라져야 한다.

인증 방식 비교

접근 제어의 뿌리는 결국 "이 요청이 누구인지"를 판별하는 인증(authentication)이다. 두 플랫폼 모두 소셜 로그인과 MFA를 제공하지만, 세션을 다루는 방식이 달라 보안 검토 포인트도 갈린다.

Supabase의 JWT는 서명된 토큰이라 백엔드에서 직접 검증할 수 있어 투명하다. 대신 service_role key(서버 전용, RLS를 우회하는 마스터 키)를 실수로 프론트엔드에 노출하면 인증·RLS가 모두 무력화된다. AI 코딩 도구가 "빠르게 데이터 넣는 코드"를 만들면서 service_role key를 클라이언트에 박아두는 경우가 잦으니, 이 키가 브라우저 번들에 들어갔는지 반드시 확인해야 한다.

Firebase의 세션은 SDK가 토큰 갱신까지 알아서 처리해 편하지만, 그만큼 내부가 블랙박스라 "지금 이 요청이 정말 인증됐는가"를 개발자가 놓치기 쉽다. Security Rules에서 request.auth != null 검사를 빼먹으면, 로그인 화면은 멀쩡히 있는데 데이터 계층은 인증을 전혀 요구하지 않는 상태가 된다.

데이터 암호화와 노출 관점

두 플랫폼 모두 전송 구간(HTTPS/TLS)과 저장 데이터(at rest) 암호화를 기본 제공한다. 이 계층에서 차이가 나는 경우는 드물다. 실무에서 사고가 나는 지점은 암호화가 아니라 "암호화된 데이터에 누가 접근하는가"다. 아무리 디스크가 암호화돼 있어도 anon key로 SELECT가 뚫리면 데이터는 평문으로 응답된다. 암호화는 서버 도난·백업 유출 같은 물리적 위협을 막을 뿐, 잘못된 접근 제어를 대신 막아주지 않는다. 그래서 Supabase RLS와 Firebase Security Rules가 사실상 두 플랫폼 보안의 승부처다.

직접 확인하는 법 (자가점검)

내 앱이 열려 있는지 5분 안에 스스로 확인할 수 있다.

Supabase 사용자

• anon key 찾기: 브라우저에서 내 앱 접속 → F12 개발자도구 → Network 탭 → supabase.co/rest/v1 요청의 apikey 헤더 확인. 이 값이 곧 공개 키다.
• 노출 테스트: 콘솔에 위의 fetch(...customers?select=*) 스니펫을 내 프로젝트 URL로 바꿔 실행. 데이터가 돌아오면 그 테이블은 RLS가 꺼져 있거나 정책이 허술한 것이다.
• 대시보드 확인: Supabase → Table Editor에서 각 테이블 옆 방패 아이콘이 초록(Enabled)인지 점검. "Unrestricted" 배지가 붙은 테이블이 최우선 위험군이다.
• service_role key 검색: 배포된 JS 번들에서 service_role 문자열을 찾아본다. 나오면 즉시 키를 재발급(rotate)하고 서버로 옮겨야 한다.

Firebase 사용자

• 규칙 점검: Firebase 콘솔 → Firestore Database → Rules에서 if true가 있는지 확인. 있으면 그 경로는 전면 개방 상태다.
• 비인증 접근 테스트: 로그아웃 상태(또는 시크릿 창)에서 앱을 열어 데이터가 그대로 보이면 규칙이 인증을 요구하지 않는 것이다.
• 에뮬레이터 활용: Firebase Local Emulator Suite로 규칙을 로컬에서 테스트하면 배포 전에 취약한 규칙을 걸러낼 수 있다. 이게 Firebase의 진짜 강점이다.

실무 관점 정리, 그래서 뭘 해야 하나

Supabase는 SQL을 잘 아는 팀에게 유리하다. 복잡한 접근 제어 로직을 SQL로 표현할 수 있고, 기존 PostgreSQL 보안 모범사례를 그대로 적용할 수 있다. 대신 "모든 테이블 RLS 켜기 + service_role key 서버 격리"를 배포 체크리스트에 못박아야 한다.

Firebase는 NoSQL 패턴에 익숙한 팀에게 적합하다. Security Rules 문법이 직관적이고 에뮬레이터로 로컬 검증이 가능하다. 대신 개발 중 열어둔 if true 규칙이 프로덕션까지 새어나가지 않도록, 배포 직전 규칙을 한 번 더 확인하는 습관이 필요하다.

결론: 둘 다 제대로 설정하면 충분히 안전하다. 문제는 언제나 "설정을 제대로 안 했을 때" 발생하고, AI 코딩 도구는 기능은 만들어줘도 이 설정을 대신 챙겨주지 않는다. 우선순위는 명확하다, (1) 접근 제어(RLS / Security Rules)부터, (2) 키 관리(anon vs service_role), (3) 그다음 나머지. 앞의 두 개만 막아도 실제 유출 사고의 대부분이 사라진다.

배포 전에 CodeScan으로 Supabase RLS 설정 여부와 JS 내 키 노출을 URL 하나로 자동 점검할 수 있다. 직접 콘솔을 열어 확인하기 어렵다면, 스캐너가 30초 만에 열린 지점을 짚어준다.

→ 지금 무료로 내 백엔드 보안 점검하기