프론트엔드의 권한 키
service-role과 secret 키는 RLS를 우회하므로 브라우저에 전달되면 안 됩니다.
Supabase 보안 점검
사용자가 실제로 도달하는 Supabase 경계 확인
공개 클라이언트 키와 권한 시크릿을 구분하고 프로젝트가 확인되면 제한된 읽기 전용 프로브를 실행합니다.
정책, 스토리지, 인증, 환경 변경 후 그리고 실제 고객 데이터 공개 전에 사용하세요.
소유하거나 명시적으로 허가받은 시스템만 스캔하세요. 심층 엔진에는 확인된 권한이 필요하며 대상에 따라 사용할 수 없을 수 있습니다.
보고서 / 예시 발견예시
치명적
보고서 구조 예시
익명 요청으로 테이블 행 읽기 가능
- 근거
- 공개 컨텍스트의 제한된 읽기 요청이 데이터를 반환했으며 수집 근거는 최소화됩니다.
- 의미
- 관찰된 경로는 RLS가 없거나 지나치게 넓음을 뜻합니다.
- 수정 및 검증
- RLS를 활성화하고 최소 권한 정책을 적용한 후 노출을 검토하고 검증하세요.
이는 설명을 위한 예시이며 고객 애플리케이션의 결과가 아닙니다. 실제 보고서는 스캐너, 근거 상태, 대상별 커버리지 한계를 표시합니다.
일반적인 위험 경로
더 자세히 살펴볼 항목
이는 Supabase 프로젝트와 관련된 위험 패턴이며 모든 프로젝트에 문제가 있다는 뜻은 아닙니다. 스캐너 근거가 있을 때만 발견 항목이 생성됩니다.
익명 행 읽기
없거나 넓은 정책은 공개 API를 통해 데이터를 노출할 수 있습니다.
공개 또는 열거 가능한 스토리지
버킷과 객체 정책이 화면에 링크되지 않은 파일을 노출할 수 있습니다.
정직한 커버리지
각 스캔 표면이 입증할 수 있는 범위
공개 URL, 연결된 소스, 승인된 심층 엔진은 서로 다른 질문에 답합니다. BoringSec은 근거를 분리하고 부분적·차단됨·사용 불가 상태를 명시합니다.
공개 방법론 읽기 (영어)프로젝트 및 키 분류
지원 URL을 찾고 공개 키와 권한 형식을 구분합니다.
제한된 테이블 프로브
상한이 있는 읽기 요청으로 제한됨·취약함·미확인·건너뜀을 구분합니다.
스토리지 상태
객체 업로드, 변경, 삭제 없이 제한된 버킷 목록 동작을 확인합니다.
불확실성 명시
자산 실패, 응답 상한, 거부는 통과 대신 커버리지를 낮춥니다.
관찰에서 검증까지
다음 조치를 위한 보고서
- 01
관찰
공개 응답을 검사하고 적용 가능한 백그라운드 엔진을 시작합니다.
- 02
근거 확인
무엇을 어떤 스캐너가 어느 신뢰도로 관찰했는지 확인합니다.
- 03
맥락에 맞게 수정
Supabase RLS 관련 맥락과 구체적인 수정 경로를 사용합니다.
- 04
재테스트
새 평가를 실행하고 이후 회귀는 모니터링으로 감지합니다.
스캔 전 질문
Supabase anon 키는 유출된 시크릿인가요?
아니요. 공개 클라이언트 키는 정상이며 RLS와 스토리지 정책이 보안 경계입니다.
스캔이 데이터베이스를 변경하나요?
아니요. 프로브는 제한된 읽기 전용이며 행이나 객체를 추가, 변경, 삭제하지 않습니다.
모든 RLS 정책을 입증하나요?
아니요. 관찰된 경로만 입증하며 인증 역할은 승인된 컨텍스트가 필요합니다.
깨끗한 결과면 Supabase가 안전한가요?
아니요. 부분적, 차단됨, 사용 불가 커버리지가 계속 표시됩니다.
배포된 애플리케이션을 확인하고 모든 수정을 검증하세요
공개 URL부터 시작하고 필요한 경우에만 소스 또는 인증된 컨텍스트를 추가하세요.
보안 스캔 시작