Lovable 앱 보안 모범 사례

프론트엔드 보안, Edge Functions, Row Level Security(RLS), 인증, 워크스페이스 보호를 포함한 Lovable 앱의 안전한 코딩 모범 사례입니다.

이 페이지는 Lovable 앱에서 안전한 코드를 작성하는 방법과 개발 중 흔한 보안 실수를 피하는 방법에 초점을 맞춥니다.

Lovable의 보안 모델, 보안 스캔, 발견 사항에 대한 자세한 내용은 보안 개요, 프로젝트 보안 뷰, 워크스페이스 보안 센터를 참조하세요.

Lovable 앱의 구조

Lovable 앱은 명확한 책임 분리로 구축됩니다:

• Frontend는 사용자의 브라우저에서 실행되며 항상 공개되어 있고 절대 신뢰해서는 안 됩니다
• Edge Functions는 서버 측에서 실행되며 유효성 검사, 인증, 비즈니스 로직을 처리합니다
• Database는 Row Level Security(RLS)가 있는 PostgreSQL을 사용하여 데이터 접근을 제어합니다

이러한 분리는 Lovable 보안 모델의 기반입니다. 아래 섹션에서는 이 구조를 따라 각 계층에서의 일반적인 보안 실수와 이를 피하는 방법을 설명합니다.

프론트엔드 보안 기초

모든 프론트엔드 코드는 사용자의 브라우저에서 실행되며 검사, 수정, 우회할 수 있습니다. 프론트엔드 코드는 절대 보안 결정을 내려서는 안 됩니다.

프론트엔드 코드에 secrets을 저장하지 마세요

프론트엔드 코드에 저장된 secrets은 사용자에게 보이며 노출된 것으로 간주해야 합니다.

// ❌ 잘못된 방법: secrets이 모든 사람에게 노출됨
const API_KEY = "sk-1234567890abcdef";
const STRIPE_SECRET = "sk_live_...";

대신: Lovable에 secrets을 안전하게 추가하도록 요청하세요. Secrets은 백엔드 인프라에 저장되며 Edge Functions에서만 접근 가능합니다.

프롬프트 예시

Add an API key for Stripe payments securely without exposing it in the frontend code

Review frontend code for exposed secrets, API keys, or sensitive information

보안을 위해 프론트엔드 유효성 검사에 의존하지 마세요

프론트엔드 유효성 검사는 사용자 경험을 개선하지만 보안을 보장하지 않습니다.

// ❌ 잘못된 방법: 클라이언트 측 유효성 검사는 우회할 수 있음
const validateUser = (userData) => userData.email.includes("@");

대신: 검사를 우회할 수 없는 Edge Functions에서 모든 데이터를 유효성 검사하고 살균하세요.

항상 클라이언트 입력을 신뢰할 수 없는 것으로 취급하세요. 형식 유효성 검사, 비즈니스 규칙 적용, 입력 살균을 데이터를 처리하거나 저장하기 전에 Edge Functions에서 수행하세요.

프롬프트 예시

Move validation logic from React components to Edge Functions for better security

Identify client-side validation that should be moved to backend Edge Functions

Edge Functions를 사용한 백엔드 보안

Edge Functions는 공개된 프론트엔드와 비공개 시스템 사이의 보안 경계를 형성합니다. 사용자가 접근하거나 수정할 수 없는 격리된 서버 측 환경에서 실행됩니다.

보안, 데이터 무결성, 외부 서비스에 영향을 미치는 모든 로직은 프론트엔드 컴포넌트가 아닌 Edge Functions에서 실행해야 합니다. 여기서 유효성 검사와 인가를 중앙 집중화하면 모든 요청이 일관되게 평가되고 중요한 로직이 브라우저에 도달하지 않습니다.

Edge Functions이 처리해야 할 항목:

• 인증 및 인가
  누가 요청을 보내는지, 해당 작업을 수행할 권한이 있는지 확인합니다.
• 데이터 유효성 검사 및 살균
  모든 입력을 신뢰할 수 없는 것으로 취급하고 비즈니스 규칙을 일관되게 적용합니다.
• 비즈니스 로직 및 워크플로우
  등록, 결제, 승인, 상태 전환 등 다단계 프로세스를 처리합니다.
• 외부 서비스 통합
  타사 API를 안전하게 호출하고 자격 증명을 브라우저 밖에 유지합니다.
• 민감한 데이터 처리
  개인 또는 금융 데이터를 안전하게 처리하고, 의도치 않은 노출을 방지하며, 중요한 보안 이벤트를 로깅합니다.

이 로직을 서버 측에 유지하면 중요한 동작이 브라우저에 절대 도달하지 않으며 모든 요청이 일관되게 평가됩니다.

프롬프트 예시

Create an Edge Function for user registration with proper validation and security checks

Move payment processing logic from frontend to a secure Edge Function

Build an Edge Function for file uploads with type and size validation

RLS를 사용한 데이터베이스 보안

Row Level Security(RLS)는 데이터베이스에서 누가 개별 행을 읽거나 수정할 수 있는지 제어합니다. 프론트엔드나 백엔드 로직이 실패하더라도 접근 규칙을 적용하는 최종 보호 계층 역할을 합니다.

Lovable은 기본 RLS 정책을 자동으로 설정하지만, 개발 초기에 검토하고 조정해야 합니다. RLS는 실제 데이터가 존재하기 전에 변경하기가 훨씬 쉬우며, 정책은 복잡한 비즈니스 로직보다 접근 제어에 집중할 때 가장 효과적입니다.

일반적인 RLS 패턴

대부분의 Lovable 앱은 소수의 접근 패턴에 해당합니다:

• 개인 데이터: 사용자가 자신의 데이터에만 접근 가능
• 팀 기반 접근: 팀 멤버가 팀 데이터를 공유
• 소유권이 있는 공개 콘텐츠: 누구나 읽을 수 있고 소유자만 수정 가능
• 조직 기반 접근: 사용자가 자신의 조직 내 데이터에 접근

가능하면 이러한 패턴을 중심으로 테이블과 정책을 설계하세요.

배포 전 RLS 점검

라이브 전에 다음을 확인하세요:

• 모든 민감한 테이블에 RLS가 활성화되어 있는지
• 사용자가 다른 사용자의 비공개 데이터에 접근할 수 없는지
• 공유 및 공개 데이터가 의도한 대로 동작하는지
• 새 테이블에 정책이 누락되지 않았는지

프로젝트 보안 뷰에서 RLS 관련 발견 사항을 검토하세요.

프롬프트 예시

Review RLS policies to ensure users can only access their own data and shared data is properly protected

Add RLS policies to the settings table so users can only access their own settings

Set up RLS for teams and projects so team members only see projects from their team

인증 보안 기초

모든 인증 결정은 브라우저가 아닌 서버 측에서 이루어져야 합니다. 클라이언트 측 인증 검사는 사용자가 검사, 수정, 우회할 수 있으므로 접근 제어에 절대 의존해서는 안 됩니다.

인증은 세션과 토큰을 안전하고 일관되게 검증할 수 있는 Edge Functions에서 적용해야 합니다.

// ❌ 잘못된 방법: 클라이언트 측 인증 검사
const isAuthenticated = localStorage.getItem("authToken") !== null;
if (isAuthenticated) showAdminPanel();

// ✅ 올바른 방법: Edge Function에서 서버 측 유효성 검사
const { user } = await supabase.auth.getUser();
if (!user) {
  return new Response("Unauthorized", { status: 401 });
}

인증 모범 사례

• Edge Functions에서 인증 및 세션 토큰 유효성 검사
• 서버 측에서 역할과 권한 확인
• 안전한 토큰 처리를 위해 내장 세션 관리 사용
• 세션이 만료되면 로그인으로 리다이렉트하되, 항상 서버에서 먼저 유효성 검사
• 프론트엔드 인증 상태는 UI 제어에만 사용하고 접근 제어에는 절대 사용하지 않음

워크스페이스 보안

공개적으로 접근할 수 없어야 하는 애플리케이션의 경우:

• 프로젝트 가시성을 workspace로 설정
• 앱이 공개적으로 배포되지 않았는지 확인
• 내부 도구에도 인증 필수
• 접근 권한을 정기적으로 감사

워크스페이스 전체 모니터링은 보안 센터를 사용하세요.

배포 전 보안 체크리스트

앱을 배포하기 전에 다음을 확인하세요:

• 프론트엔드 코드에 secrets이 없는지
• 모든 유효성 검사와 중요 로직이 Edge Functions에서 실행되는지
• Row Level Security(RLS) 정책이 구성되고 테스트되었는지
• 인증이 서버 측에서 적용되는지
• 내부 앱이 workspace 가시성으로 설정되었는지
• 보안 뷰의 모든 Critical 발견 사항이 해결되었는지
• 외부 API 호출이 서버 측에서 이루어지는지