점검 가이드 · 보안
Supabase RLS 안 켜면 생기는 일 — 행 수준 보안 정리
2026-10-24 기준
- Supabase 의 공개 키(publishable·anon)는 브라우저에 그대로 보이므로, 데이터를 지키는 것은 키가 아니라 RLS 규칙입니다.
- RLS 가 꺼진 표는 공개 키만 있으면 누구나 읽고 쓸 수 있는 상태가 될 수 있습니다.
- RLS 를 켜도 "누구나 허용(true)" 규칙을 넣으면 꺼 둔 것과 비슷해집니다. 규칙 내용까지 확인하세요.
왜 Supabase 에서는 RLS 가 특히 중요한가
보통의 웹 서비스는 브라우저 → 내 서버 → DB 순서로 가서, 서버가 "이 사람이 볼 수 있는 데이터인가"를 걸러 줍니다. Supabase 는 브라우저가 공개 키를 들고 DB 에 바로 요청하는 구조를 많이 씁니다.
그래서 Supabase 문서는 공개되는 스키마(보통 public)의 모든 표에 RLS 를 켜라고 안내합니다. RLS 는 "표의 줄(행)마다 누가 읽고 쓸 수 있는지"를 DB 가 직접 따지는 규칙입니다.
RLS 를 안 켜거나 잘못 켰을 때 생기는 일
- RLS 가 꺼져 있으면: 브라우저 개발자 도구에서 공개 키와 주소를 보고, 누구나 그 표 전체를 읽거나 고치거나 지울 수 있는 상태가 될 수 있습니다.
- RLS 를 켰지만 규칙이 없으면: 반대로 공개 키로는 아무 데이터도 안 나옵니다. "갑자기 목록이 비었다"는 증상이 이것입니다. 이때 AI 가 RLS 를 다시 끄자고 하는 경우가 있는데, 끄지 말고 규칙을 추가해야 합니다.
- 규칙이 "누구나(true)"이면: 켜져 있어도 모든 줄이 모든 방문자에게 열립니다. 공지사항처럼 정말 공개할 데이터에만 씁니다.
- 로그인 안 한 요청에서는 auth.uid() 가 비어 있습니다(null). 규칙을 쓸 때 이 경우도 막히는지 확인해야 합니다.
내 프로젝트에서 확인하는 방법
- Supabase 대시보드에서 「Advisors → Security Advisor」를 엽니다. 공개 스키마에 RLS 가 꺼진 표가 있으면 경고(rls_disabled_in_public)로 나옵니다.
- Table Editor 에서 표마다 RLS 가 켜져 있는지 봅니다.
- 「Authentication → Policies」에서 표마다 어떤 규칙이 있는지 봅니다. using (true) 처럼 조건 없이 모두 허용하는 규칙이 개인정보 표에 붙어 있지 않은지 확인합니다.
- 시험 계정 두 개로 로그인해, A 가 만든 데이터가 B 에게 보이지 않는지 실제로 확인합니다.
기본 규칙의 모양
가장 흔한 규칙은 "로그인한 사람은 자기 줄만 본다"입니다. Supabase 문서의 예시는 표에 user_id 칸을 두고, 로그인한 사람의 아이디(auth.uid())와 같을 때만 허용하는 방식입니다.
읽기(select)만이 아니라 쓰기(insert)·고치기(update)·지우기(delete)도 각각 규칙이 필요합니다. 특히 update 는 "남의 줄을 고칠 수 없게"와 "고친 뒤에도 user_id 를 남의 것으로 바꿀 수 없게" 둘 다 막아야 합니다.
service_role·secret 키는 RLS 를 모두 건너뜁니다. 이 키는 서버에서만 쓰고, 브라우저 코드에 절대 넣지 않습니다.
내 AI 코딩 도구에 이렇게 맡겨 보세요
자주 묻는 질문
anon 키(공개 키)가 브라우저에 보이는데 바꿔야 하나요?
공개 키는 원래 공개되는 것을 전제로 만든 키라서 보이는 것 자체는 문제가 아닙니다. 대신 RLS 규칙이 제대로 걸려 있어야 합니다. secret·service_role 키가 보인다면 바로 새로 발급하세요.
RLS 를 켰더니 화면에 데이터가 안 나와요.
규칙이 없어서 모두 막힌 상태입니다. RLS 를 끄지 말고, 그 표에 맞는 읽기 규칙(예: 본인 줄만, 공개 글은 모두)을 추가하세요.
서버에서만 DB 에 접근하면 RLS 가 필요 없나요?
브라우저가 공개 키로 DB 에 직접 접근하지 않는 구조라면 위험이 줄지만, 공개 키가 살아 있고 표가 열려 있으면 여전히 접근될 수 있습니다. 공개 스키마의 표에는 RLS 를 켜 두는 것이 안전합니다.
삼심은 Claude·GPT·Gemini 가 서로 모르게 점검하고 지적을 교차 확인해, 개발부터 법률까지 8개 분야의 고칠 순서와 수정 지시문을 드립니다.
함께 보면 좋은 글
참고
이 글은 일반적인 정보이며 법률·보안 자문이 아닙니다. 서비스마다 상황이 다르니 고치기 전에 확인하세요.