Bubble.io 보안 가이드: Client-side 데이터 노출 위험성 진단 및 대응 전략

2026년 9월 30일 읽는 시간 약 14분

Bubble.io로 만든 앱은 코드를 직접 작성하지 않아도 빠르게 서비스를 구현할 수 있다. 하지만 개발 속도가 빠르다고 해서 보안 설정까지 자동으로 완성되는 것은 아니다. 특히 페이지에서 민감한 요소를 숨겼다는 이유만으로 데이터도 보호된다고 생각하면 예상하지 못한 정보 노출이 발생할 수 있다.

Bubble 앱의 화면은 사용자의 브라우저에서 실행된다. 브라우저로 전달된 HTML, JavaScript, JSON, 네트워크 응답은 개발자 도구 등을 통해 확인될 가능성이 있다. 따라서 보안의 기준은 “화면에 보이지 않는가”가 아니라 “권한이 없는 사용자에게 해당 데이터가 서버에서 전달되지 않는가”가 되어야 한다.

이 글에서는 Bubble 앱에서 발생하기 쉬운 Client-side 데이터 노출 위험을 진단하고, Privacy Rules와 서버 측 워크플로를 이용해 대응하는 방법을 단계별로 살펴본다.

Client-side 데이터 노출이란 무엇인가

Client-side는 사용자의 웹브라우저에서 처리되는 영역을 뜻한다. 페이지 요소 표시, 입력값 처리, 일부 조건 판단과 화면 전환 등이 여기에 포함된다. 사용자는 브라우저 개발자 도구의 Elements, Network, Sources, Application 탭을 통해 브라우저로 내려온 자원을 살펴볼 수 있다.

예를 들어 관리자만 볼 수 있는 텍스트를 페이지에 배치한 뒤 This element is visible on page load 옵션만 해제했다고 가정해 보자. 화면에서는 보이지 않더라도 관련 값이나 로직이 이미 브라우저에 전달됐다면 이것을 접근 제어로 볼 수 없다. 조건부 표시와 보안 규칙은 역할이 다르다.

Bubble 공식 문서도 앱이 HTML, CSS, JSON, JavaScript 형태로 사용자의 기기에 전달되므로, Client-side 영역에 둔 API 키 같은 민감한 정보는 추출될 수 있다고 설명한다. 즉, 브라우저에 도착한 정보는 언젠가 확인될 수 있다는 전제로 설계해야 한다.

가장 자주 발생하는 노출 위험 5가지

1. 요소를 숨기는 것만으로 권한을 제어하는 경우

관리자 버튼이나 회원 전용 그룹을 조건부로 숨기는 것은 사용자 경험을 정리하는 방법이다. 그러나 이것만으로 데이터 읽기나 변경 권한이 차단되지는 않는다. 권한이 없는 사용자가 검색 결과나 워크플로를 다른 경로로 호출할 수 있다면 실제 보안은 유지되지 않는다.

UI 조건은 “무엇을 보여줄지”를 결정하고, Privacy Rules와 서버 검증은 “무엇에 접근할 수 있는지”를 결정한다. 두 기능을 함께 사용해야 한다.

2. 검색 결과에 필요 이상의 필드가 포함되는 경우

페이지에서 고객 이름만 표시하더라도 검색된 Thing에 이메일, 전화번호, 내부 메모, 결제 관련 식별값 등이 함께 저장돼 있으면 브라우저로 더 많은 데이터가 전달될 수 있다. Bubble 공식 최적화 문서에서는 Thing이 조회될 때 화면에 표시한 필드만이 아니라 저장된 데이터가 전달될 수 있으며, 현재 사용자가 충족하지 못하는 Privacy Rules로 보호된 필드는 서버를 떠나지 않는다고 설명한다.

따라서 민감 필드는 Privacy Rules의 View all fields에 의존하지 말고, 필요한 역할별로 볼 수 있는 필드를 구체적으로 제한해야 한다. 공개 프로필과 내부 운영 정보를 별도 데이터 타입으로 나누는 것도 효과적이다.

3. API 키를 페이지나 플러그인 설정에 노출하는 경우

결제, 문자 발송, 지도, AI API를 연결할 때 비밀 키를 페이지의 Custom State, JavaScript 코드, URL 파라미터 또는 공개 입력값에 넣으면 안 된다. API Connector에서도 인증 정보는 가능한 한 Private로 설정하고, 비밀 값이 브라우저에서 실행되는 액션이나 공개 응답에 포함되지 않는지 확인해야 한다.

외부 API 호출에 비밀 키가 필요하다면 서버 측 액션이나 Backend Workflow에서 처리하고, 브라우저에는 작업 결과 중 필요한 값만 반환하는 구조가 안전하다.

4. 워크플로의 실행 조건만 신뢰하는 경우

버튼이 특정 사용자에게만 보인다고 해도 데이터 변경 액션 자체에 권한 검사가 없다면 문제가 생길 수 있다. 중요한 생성, 수정, 삭제 작업에는 Only when 조건을 추가해 현재 사용자의 역할과 대상 데이터의 소유 관계를 다시 확인해야 한다.

예를 들어 주문 주소를 수정할 때는 단순히 사용자가 로그인했는지만 검사하지 말고, Current User is This Order's Owner와 같은 소유권 조건까지 확인해야 한다. 관리자 작업은 사용자 데이터에 저장한 검증된 역할 값을 기준으로 판단하되, 그 역할 필드 자체도 일반 사용자가 수정하지 못하도록 보호해야 한다.

5. 공개 API Workflow와 Privacy Rules 예외 설정을 과도하게 사용하는 경우

API Workflow의 인증 방식을 None required로 설정하면 로그인하지 않은 요청도 엔드포인트를 호출할 수 있다. 회원가입이나 로그인처럼 공개 호출이 필요한 일부 기능에는 쓸 수 있지만, 데이터 변경이나 외부 유료 API 호출에 사용하면 남용 위험이 커진다.

또한 Ignore privacy rules when running the workflow 옵션은 워크플로가 강한 권한으로 데이터를 다룰 수 있게 한다. 꼭 필요한 작업에만 제한적으로 사용하고, 엔드포인트 내부에서 인증 토큰, 요청 주체, 대상 데이터, 허용 작업을 별도로 검증해야 한다.

단계별 보안 진단 방법

1단계 공개 사용자 기준으로 데이터 확인하기

로그아웃 상태 또는 시크릿 창에서 앱을 연다. 관리자 페이지 URL, 회원 전용 상세 페이지, 검색 페이지에 직접 접근해 본다. 화면이 숨겨지는지만 보지 말고 브라우저의 Network 탭에서 예상하지 않은 개인정보나 내부 데이터가 응답에 포함되는지 확인한다.

2단계 데이터 타입별 Privacy Rules 점검하기

Bubble 편집기에서 Data → Privacy로 이동한 뒤 User, Order, Payment, Message 등 개인정보가 포함된 모든 데이터 타입을 확인한다. 규칙이 없는 데이터 타입은 우선 점검 대상이다.

각 규칙에서는 다음 항목을 살펴본다.

누가 이 규칙에 해당하는가
검색 결과에서 해당 데이터를 찾을 수 있는가
모든 필드를 볼 수 있는가
특정 필드만 볼 수 있는가
수정, 생성, 삭제 또는 API 접근이 필요한가
여러 규칙이 동시에 적용될 때 권한이 의도보다 넓어지지 않는가

가장 안전한 출발점은 기본 접근을 닫고, 필요한 사용자와 필드만 허용하는 방식이다.

3단계 검색 범위와 데이터 구조 줄이기

반복 그룹에서 전체 User 목록을 검색한 뒤 화면 조건으로 걸러내는 방식은 피한다. 처음 검색할 때부터 소유자, 조직, 상태 등 필요한 제약 조건을 적용한다. 다만 검색 제약은 성능과 노출 범위를 줄이는 보조 수단이며, Privacy Rules를 대신하지 않는다.

공개 정보와 민감 정보를 하나의 데이터 타입에 모두 저장하지 않는 것도 중요하다. 예를 들어 공개 닉네임과 프로필 이미지는 Public Profile에, 이메일·전화번호·관리자 메모는 User 또는 별도 Private Profile에 두면 권한 설계가 명확해진다.

4단계 비밀 값의 저장 위치 확인하기

API 키, Webhook Secret, 관리자용 토큰, 서비스 계정 정보가 다음 위치에 들어가 있는지 검색한다.

페이지 텍스트와 입력 요소
Custom State
URL 파라미터
공개 Option Set
브라우저에서 실행되는 JavaScript
공개 데이터 타입의 필드
플러그인의 Client-side 입력값

발견한 비밀 값은 서버 측 설정으로 옮기고 기존 키를 폐기한 뒤 새 키로 교체한다. 이미 공개된 키는 화면에서 삭제하는 것만으로 안전해지지 않는다.

5단계 서버 측 워크플로 검증하기

중요한 Backend Workflow와 API Workflow마다 인증 방식, 파라미터, Only when 조건, Privacy Rules 무시 여부를 기록한다. 사용자가 전달한 이메일이나 데이터 ID만 믿지 말고, 인증된 Current User와 데이터의 소유 관계를 서버에서 다시 확인한다.

외부에서 전달받은 가격, 권한, 할인율, 결제 완료 여부도 그대로 저장해서는 안 된다. 신뢰할 수 있는 데이터베이스 값이나 결제사의 검증된 Webhook 결과를 기준으로 처리해야 한다.

6단계 Bubble 보안 도구로 반복 검사하기

Bubble의 Security Dashboard와 Privacy Rules Checker를 이용하면 공개적으로 접근 가능한 데이터 타입과 필드를 찾는 데 도움이 된다. 검사 결과가 의미 있으려면 테스트할 데이터 타입에 샘플 데이터가 있어야 한다. 배포 전뿐 아니라 데이터 구조와 권한 정책이 변경될 때마다 다시 검사하는 습관이 필요하다.

역할별 Privacy Rules 설계 예시

주문 데이터 타입을 예로 들면 다음과 같이 권한을 나눌 수 있다.

사용자 구분	검색 허용	조회 필드	수정 권한
로그아웃 사용자	허용하지 않음	없음	없음
주문 소유자	본인 주문만	상품명, 주문 상태, 배송 정보	제한된 배송 정보만
상담 담당자	담당 주문만	상담에 필요한 필드	상담 상태와 메모
관리자	업무상 필요한 전체 주문	관리 필드 포함	관리 기능 범위 내 허용

여기서 중요한 점은 관리자 화면을 따로 만드는 것보다 데이터 계층에서 권한을 먼저 정하는 것이다. 화면 주소가 알려지거나 UI 조건이 잘못 설정돼도 서버가 데이터를 보내지 않는 구조라면 피해 가능성을 크게 낮출 수 있다.

배포 전 보안 체크리스트

모든 민감 데이터 타입에 Privacy Rules가 설정돼 있는가
로그아웃 사용자에게 검색 가능한 개인정보가 없는가
View all fields가 꼭 필요한 규칙에서만 사용되는가
일반 사용자가 role, is_admin 같은 권한 필드를 수정할 수 없는가
중요한 데이터 변경 액션에 Only when 권한 검사가 있는가
API 키와 비밀 토큰이 Client-side에 포함되지 않는가
공개 API Workflow가 최소 범위로 제한돼 있는가
Ignore privacy rules를 사용한 이유와 추가 검증 조건이 명확한가
Development 데이터에 실제 개인정보를 불필요하게 복사하지 않았는가
관리자·일반 회원·로그아웃 사용자 계정으로 각각 테스트했는가
Privacy Rules Checker 결과를 검토했는가

보안 사고가 의심될 때의 대응 순서

데이터나 API 키가 노출됐다고 의심되면 먼저 관련 페이지를 숨기는 데 그치지 말고 노출 경로를 차단해야 한다. Privacy Rules와 워크플로 조건을 수정하고, 공개된 API 키와 토큰은 즉시 폐기·재발급한다. 이후 서버 로그와 외부 서비스 사용 기록을 확인해 비정상 호출이나 데이터 변경이 있었는지 조사한다.

영향을 받은 데이터의 범위, 노출 가능 시간, 접근 주체를 정리하고 법적 신고나 이용자 통지가 필요한지도 검토해야 한다. 마지막으로 같은 유형의 문제가 다른 데이터 타입이나 워크플로에 반복되고 있지 않은지 전체 앱을 다시 점검한다.

마무리

Bubble.io 앱의 보안은 요소를 숨기거나 페이지 접근을 막는 것만으로 완성되지 않는다. Client-side 조건은 화면을 구성하는 기능이며, 실제 데이터 보호는 Privacy Rules와 서버 측 권한 검증에서 시작된다.

가장 중요한 원칙은 단순하다. 권한이 없는 사용자에게는 민감한 데이터가 브라우저까지 전달되지 않아야 한다. 데이터 타입별 최소 권한, 서버 측 재검증, 비밀 키의 안전한 저장, 역할별 반복 테스트를 함께 적용하면 Bubble 앱의 Client-side 노출 위험을 체계적으로 줄일 수 있다.