Vercel·Supabase로 만든 웹앱, 보안 점검은 어디까지 확인해야 할까?

카페인코더·2026년 6월 23일

AI개발 Vercel supabase 보안점검 웹개발 웹보안

AI 웹앱 보안 점검

목록 보기

9/11

Vercel이나 Supabase로 웹앱을 만들고 보안 체크리스트를 확인하다 보면 마지막에 한 가지 질문이 남습니다.

그래서 내 웹앱은 실제로 괜찮은 걸까?

이 질문에 도메인 주소만 보고 바로 답하기는 어렵습니다.

보안 점검은 확인할 수 있는 자료와 접근 범위에 따라 결과가 달라지기 때문입니다.

이번 글에서는 웹앱 보안 점검을 다음 세 단계로 나누어 살펴보겠습니다.

도메인으로 확인하는 외부 점검
관리자 설정을 확인하는 설정 점검
소스코드를 확인하는 코드 점검

보안 점검은 모두 같은 점검이 아니다

세 점검의 차이를 먼저 정리하면 다음과 같습니다.

구분	필요한 자료	확인 가능한 내용	주요 한계
외부 점검	도메인 주소	외부에 노출된 설정과 정보	내부 권한과 코드는 확인 불가
설정 점검	관리자 설정 자료	Vercel·Supabase 등의 구성	실제 코드 흐름은 확인 불가
코드 점검	소스코드와 테스트 환경	인증, 권한, 입력값 처리	운영 환경과 다를 수 있음

어느 한 단계가 다른 단계를 완전히 대체하지는 않습니다.

외부 점검에서 문제가 발견되지 않았다고 내부 설정과 코드까지 안전하다는 뜻은 아닙니다.

반대로 보안 헤더 하나가 없다고 해서 서비스 전체가 즉시 위험하다고 단정할 수도 없습니다.

점검 결과를 해석하려면 무엇을 확인했고, 무엇은 확인하지 못했는지 함께 설명해야 합니다.

1단계: 도메인으로 확인하는 외부 점검

외부 점검은 소스코드나 관리자 권한 없이 웹앱 주소에서 확인되는 정보를 살펴보는 방식입니다.

실제 외부 방문자와 비슷한 위치에서 서비스가 무엇을 노출하고 있는지 확인합니다.

HTTPS와 인증서

다음 항목을 확인할 수 있습니다.

HTTP 접속이 HTTPS로 전환되는가
인증서가 유효한가
인증서의 도메인이 일치하는가
브라우저에서 인증서 오류가 발생하지 않는가
HTTPS 페이지에서 HTTP 리소스를 불러오지 않는가

HTTPS가 적용되어 있어도 리디렉션이나 혼합 콘텐츠 설정은 별도로 확인할 필요가 있습니다.

보안 응답 헤더

서버 응답에서 다음과 같은 헤더를 확인할 수 있습니다.

Strict-Transport-Security
Content-Security-Policy
X-Content-Type-Options
X-Frame-Options
Referrer-Policy
Permissions-Policy

보안 헤더는 브라우저에 적용할 보안 정책을 전달합니다.

다만 특정 헤더가 없다는 사실만으로 취약점이 확정되는 것은 아닙니다. 서비스의 기능과 응답 종류를 함께 살펴봐야 합니다.

예를 들어 Content-Security-Policy는 서비스에서 사용하는 스크립트와 외부 리소스에 맞게 구성해야 합니다.

외부에 공개된 파일과 경로

서비스 소유자의 동의를 받은 범위에서 낮은 강도의 요청으로 다음 항목을 확인할 수 있습니다.

환경설정 파일
백업 파일
로그 파일
테스트 페이지
API 문서
관리 기능으로 연결되는 공개 경로
불필요하게 공개된 디렉터리

경로가 존재한다는 사실 자체가 취약점은 아닙니다.

관리자 페이지가 공개된 경로에 있더라도 적절한 인증과 권한 검사가 적용되어 있다면 접근은 제한될 수 있습니다.

브라우저에 전달된 JavaScript

웹앱은 실행에 필요한 JavaScript를 브라우저로 전송합니다.

이 파일에서 다음과 같은 값을 확인할 수 있습니다.

외부 서비스 API 주소
Supabase 프로젝트 주소
공개용 API Key
비밀 값으로 의심되는 문자열
내부 경로와 기능 이름
빌드 환경 정보

여기서 주의할 점은 브라우저에 보이는 API Key가 모두 비밀 Key는 아니라는 것입니다.

Supabase의 Publishable Key와 기존 anon key처럼 공개를 전제로 만들어진 값도 있습니다. 키가 보인다는 이유만으로 유출이라고 판단해서는 안 됩니다.

값의 종류와 해당 키로 가능한 작업을 함께 확인해야 합니다.

Source Map

Source Map이 외부에 공개되어 있으면 압축된 JavaScript와 원본 소스의 관계를 파악하는 데 도움이 될 수 있습니다.

Source Map 공개가 항상 보안 취약점인 것은 아닙니다.

하지만 다음 정보가 불필요하게 포함되어 있다면 검토가 필요합니다.

원본 파일명과 디렉터리 구조
내부 API 경로
개발 중 남긴 주석
사용하지 않는 관리자 기능
오류 처리 과정의 내부 정보

DNS와 메일 보안 설정

도메인의 공개 DNS 레코드에서는 다음 항목도 확인할 수 있습니다.

사용 중인 네임서버
불필요하게 남은 서브도메인
SPF
DKIM
DMARC
CAA
DNSSEC 적용 여부

메일을 사용하지 않는 서비스라면 모든 메일 보안 항목이 동일하게 필요한 것은 아닙니다. 실제 도메인 사용 목적을 기준으로 판단해야 합니다.

외부 점검만으로 확인할 수 없는 것

도메인 기반 외부 점검에는 명확한 한계가 있습니다.

다음 항목은 일반적으로 도메인만으로 정확히 판단하기 어렵습니다.

Supabase 테이블별 RLS 정책
사용자 간 데이터 접근 권한
Vercel 환경변수의 적용 범위
Preview Deployment 보호 설정
service_role 또는 Secret Key의 서버 사용 방식
API 내부의 인증과 권한 검사
서버 입력값 검증
로그에 저장되는 개인정보
관리자 기능의 내부 접근 제어
백업과 복구 설정

따라서 외부 점검 결과는 다음과 같이 표현해야 합니다.

외부에서 확인한 범위에서는 해당 문제가 발견되지 않았습니다.

다음과 같이 단정해서는 안 됩니다.

이 웹앱은 안전합니다.

무료 외부 점검은 전체 보안을 보증하는 검사가 아니라, 다음 점검이 필요한 위치를 찾는 1차 진단에 가깝습니다.

2단계: 관리자 설정을 확인하는 설정 점검

Vercel과 Supabase의 내부 설정은 프로젝트 소유자만 확인할 수 있습니다.

이 단계에서는 관리자 계정의 비밀번호나 Secret Key를 전달할 필요가 없습니다.

다음과 같은 방법을 사용할 수 있습니다.

민감정보를 제거한 설정 화면
설정값 내보내기 자료
Migration 파일
화면 공유
점검자가 제공한 체크리스트를 소유자가 직접 실행

Vercel에서 확인할 수 있는 항목

Production과 Preview 환경변수 구분
Preview Deployment 보호 설정
환경변수 변경 후 재배포 여부
프로젝트와 팀의 접근 권한
도메인과 Redirect 설정
사용량과 비용 관리
Runtime Logs 접근 범위

Vercel 공식 문서도 애플리케이션 코드, 환경변수 노출, 인증과 사용자 접근 관리는 고객의 책임으로 구분합니다.

Vercel 공동 책임 모델

Supabase에서 확인할 수 있는 항목

API에 노출된 테이블의 RLS 활성화
SELECT, INSERT, UPDATE, DELETE 정책
anon과 authenticated 역할의 접근 범위
Storage 버킷의 공개·비공개 설정
storage.objects 접근 정책
인증 Redirect URL
백업과 복구 설정
Security Advisor 결과

Supabase RLS는 테이블 행에 대한 접근을 제한하는 기능입니다. 실제 정책을 확인하지 않고 외부 응답만으로 전체 권한 구조를 판단하기는 어렵습니다.

Supabase RLS 공식 문서

Supabase API 보안 공식 문서

3단계: 소스코드를 확인하는 코드 점검

설정이 올바르더라도 애플리케이션 코드에서 권한을 잘못 처리하면 문제가 발생할 수 있습니다.

코드 점검에서는 기능이 동작하는지만 보는 것이 아니라 데이터가 이동하고 처리되는 흐름을 확인합니다.

인증과 권한 검사

다음 항목을 살펴볼 수 있습니다.

API가 로그인 여부를 확인하는가
사용자가 자신의 데이터에만 접근하는가
관리자 기능이 역할을 다시 확인하는가
URL의 ID만 변경해서 다른 사용자 데이터에 접근할 수 있는가
조회·등록·수정·삭제마다 권한을 검사하는가

화면에서 버튼을 숨기는 것은 접근 통제가 아닙니다.

사용자는 화면을 거치지 않고 API에 직접 요청할 수 있으므로 서버와 데이터베이스에서 권한을 확인해야 합니다.

서버 입력값 검증

프론트엔드의 입력값 검사는 사용자 경험에는 도움이 되지만 우회할 수 있습니다.

서버에서도 다음 항목을 검증해야 합니다.

필수 값
문자열 길이
숫자와 날짜의 범위
허용된 선택지
파일 형식과 크기
요청한 사용자의 변경 권한

로그와 오류 처리

코드에서는 어떤 정보를 로그로 남기는지도 확인해야 합니다.

비밀번호
Access Token
Session ID
Cookie
Authorization 헤더
API Secret
개인정보
문의와 상담 내용

오류 객체나 요청 객체 전체를 출력하면 예상보다 많은 정보가 로그에 포함될 수 있습니다.

Secret 관리

다음 위치에 비밀 값이 하드코딩되어 있지 않은지 확인할 수 있습니다.

프론트엔드 코드
설정 파일
테스트 코드
Git 커밋 기록
배포 스크립트
로그 출력 코드

코드에서 Secret을 제거했더라도 Git 기록이나 이전 배포에 남아 있다면 해당 키를 교체해야 할 수 있습니다.

세 단계가 모두 필요한 이유

Vercel과 Supabase 같은 플랫폼은 개발 속도를 크게 높여줍니다.

하지만 플랫폼이 제공하는 보안과 개발자가 구현해야 하는 보안은 구분해야 합니다.

예를 들어 다음 상황이 동시에 존재할 수 있습니다.

HTTPS와 보안 헤더는 정상적으로 설정됨
Supabase RLS 정책은 지나치게 넓게 설정됨
API에서는 다른 사용자의 데이터를 수정할 수 있음

외부 점검만 했다면 첫 번째 상태만 확인할 수 있습니다.

설정 점검을 추가하면 두 번째 상태를 확인할 수 있고, 코드와 실제 사용자 테스트까지 진행해야 세 번째 상태를 확인할 수 있습니다.

OWASP ASVS도 웹 애플리케이션의 기술적 보안 통제를 검증하기 위한 요구사항과 기준을 제공합니다.

OWASP ASVS 공식 페이지

무료 외부 보안 점검을 준비하고 있습니다

2026년 6월 24일, Vercel 또는 Supabase로 만든 웹앱을 대상으로 소수의 무료 외부 보안 점검을 모집할 예정입니다.

이번 무료 점검은 첫 번째 단계인 도메인 기반 외부 점검만 진행합니다.

무료 점검에서 확인하는 범위

HTTPS와 인증서
보안 응답 헤더
외부에 공개된 파일과 정보
브라우저에 전달된 코드의 노출 정보
Source Map 공개 여부
기본적인 DNS와 메일 보안 설정

무료 점검에서 확인하지 않는 범위

소스코드
Vercel과 Supabase 관리자 설정
RLS 정책
API 내부 권한
공격적인 침투 테스트
서비스 장애를 유발할 수 있는 요청

비밀번호, 관리자 권한, Secret Key와 service_role Key는 받지 않습니다.

서비스 소유자이거나 점검 권한을 가진 사람만 신청할 수 있으며, 발견된 내용은 신청자의 동의 없이 공개하지 않습니다.

무료 점검은 서비스가 안전하다는 인증이 아니라, 외부에서 확인되는 상태와 다음 점검이 필요한 항목을 정리하는 1차 진단입니다.

마무리

보안 점검을 받을 때는 결과뿐 아니라 점검 범위를 함께 확인해야 합니다.

도메인만 확인한 점검으로 소스코드와 데이터 권한까지 안전하다고 판단할 수는 없습니다.

반대로 간단한 외부 점검도 현재 외부에 무엇이 노출되어 있는지 파악하고 다음 조치를 결정하는 출발점이 될 수 있습니다.

보안 점검을 다음 세 질문으로 나누어 생각해보세요.

외부에서는 무엇이 보이는가?
관리자 설정은 어떻게 되어 있는가?
소스코드는 권한과 데이터를 어떻게 처리하는가?

이번 무료 점검에서는 첫 번째 질문부터 확인해보려고 합니다.

참고한 공식 문서

카페인코더

꾸준히 기록 중 입니다.

이전 포스트

Vercel 자주 하는 실수 10가지

다음 포스트