보안사례
남이 겪은 사고에서 배워요. 무엇이 잘못됐고, 어떻게 막는지.
Critical
service_role 키가 깃에 올라가 DB 전체가 뚫릴 뻔
취약점.env.local이 그대로 커밋돼 Supabase service_role 키가 깃허브에 노출. 이 키는 RLS를 전부 우회해서 DB 전체 읽기·쓰기가 가능합니다.
방어키 즉시 재발급(rotate) → .gitignore에 .env 추가 → 깃 히스토리에서 제거. 클라이언트엔 anon 키만.
M @minu· 2일 전 1.2k원문 보기
Critical
anon 키로 admin 테이블이 통째로 조회됨
취약점RLS를 안 켜서 공개 anon 키만으로 관리자 전용 테이블의 모든 행이 조회됐습니다.
방어모든 테이블 RLS ON + 본인 행만 보는 정책. 공개돼야 하는 테이블만 명시적으로 public read 허용.
S @sora· 3일 전 940원문 보기
High
RLS를 안 켜서 남의 가계부가 다 보였어요
취약점테이블에 RLS를 켜지 않아 로그인한 누구나 다른 사람의 가계부 데이터를 볼 수 있었습니다.
방어RLS 켜고 auth.uid() = user_id 정책 추가. insert엔 with check도 필수.
D @dana· 4일 전 880원문 보기
Critical
Stripe 라이브 키를 프론트에 그대로 노출
취약점결제 붙이면서 Stripe 시크릿(라이브) 키를 클라이언트 코드에 넣어 누구나 결제 API를 호출할 수 있었습니다.
방어시크릿 키는 서버 전용 환경변수로. 클라이언트엔 publishable 키만. 노출된 키는 대시보드에서 폐기.
M @minu· 5일 전 720원문 보기
High
CORS '*' + 쿠키로 세션이 탈취될 수 있었던 사례
취약점Access-Control-Allow-Origin: * 와 credentials: true를 같이 켜서, 어떤 사이트든 로그인된 사용자 대신 API를 호출할 수 있었습니다.
방어허용 도메인을 명시로 고정. credentials를 쓰면 와일드카드(*) 절대 금지.
K @kev· 6일 전 620원문 보기
High
Firebase 규칙 미설정으로 전체 쓰기가 열림
취약점Firestore 규칙을 기본값으로 두어 인증 없이도 모든 컬렉션에 쓰기가 가능했습니다.
방어request.auth != null 기본 가드 + 컬렉션별 본인 문서만 쓰기 허용 규칙 작성.
R @ramen· 1주 전 540원문 보기