보안 함정 피하기

frontend 코드에서 secrets을 제외하고, Edge Functions에서 데이터를 검증하고, Row Level Security를 구성하고, 게시 전에 보안 검사를 실행하세요.

Security Checker 발견 사항을 수정하는 것을 잊지 마세요

앱을 온라인에 게시하기 전에 Lovable의 내장 security checker의 발견 사항을 처리해야 합니다. security checker는 자동으로 애플리케이션을 스캔하고 보안 개선을 위한 귀중한 권장 사항을 제공합니다.

Lovable AI와 security checker 같은 도구가 광범위한 보안 문제를 찾고 방지하지만, 앱이 인터넷에 라이브된 후 나타날 수 있는 모든 문제를 자동으로 발견하거나 처리하는 것이 항상 가능하거나 현실적이지는 않습니다. 이 가이드는 Lovable 앱이 내부적으로 어떻게 작동하는지, 빌더가 고객 데이터를 보호하는 데 도움이 되는 중요한 보안 관행, 일반적인 실수를 피하는 방법에 대해 더 깊이 살펴봅니다.

Lovable의 아키텍처 이해하기

별도의 지시가 없는 한 Lovable은 다음 아키텍처로 애플리케이션을 생성합니다:

Frontend: TypeScript/React 애플리케이션
Backend: Supabase Edge Functions (서버리스 함수)
Database: Supabase (실시간 기능이 있는 PostgreSQL)

이러한 관심사 분리는 보안 유지에 기본적입니다. 각 계층에는 특정 책임과 보안 고려 사항이 있습니다.

Frontend 보안: 클라이언트 측 코드를 절대 신뢰하지 마세요

황금 규칙: Frontend 코드는 공개됩니다

모든 React 코드는 사용자의 브라우저에서 실행되며 본질적으로 공개됩니다. 사용자는 모든 frontend 코드를 검사, 수정 또는 우회할 수 있습니다. 따라서:

frontend 코드에 secrets을 저장하지 마세요 - API 키, 비밀번호 또는 민감한 구성
frontend 코드에서 유효성 검사를 수행하지 마세요 - 클라이언트 측 유효성 검사는 우회할 수 있습니다
frontend 데이터를 신뢰하지 마세요 - 항상 edge functions 측에서 유효성 검사

일반적인 frontend 보안 실수

// ❌ WRONG - 절대 하지 마세요
const API_KEY = "sk-1234567890abcdef"; // 사용자에게 노출됨
const validateUser = (userData) => {
  // 클라이언트 측 유효성 검사는 우회할 수 있음
  return userData.email.includes('@');
};

올바른 방법은 Lovable에 secret 키를 추가하도록 요청하는 것입니다 - 양식이 열리고 secret을 자체 backend에 안전하게 저장합니다.

frontend 보안 유효성 검사 및 강화를 위한 프롬프트 예시

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

Move validation logic from React components to edge functions for better security

Review frontend code for exposed secrets, API keys, or sensitive information. I have a settings page that displays user preferences and I want to make sure no sensitive data is visible

Identify client-side validation that should be moved to backend edge functions

더 많은 프롬프트는 Lovable 프롬프트 라이브러리를 참조하세요.

Backend 보안: 비즈니스 로직을 Edge Functions으로 이동

Edge Functions을 API 계층으로 취급하기

Supabase Edge Functions은 모든 비즈니스 로직, 유효성 검사, 민감한 작업을 포함해야 합니다:

인증 및 권한 부여
데이터 유효성 검사 및 살균
비즈니스 로직 및 워크플로우
외부 서비스와의 통합
민감한 데이터 처리

Edge Functions 모범 사례

edge functions을 애플리케이션의 보안 경비원이자 비즈니스 관리자로 생각하세요. 앱의 공개 부분에서 멀리 떨어진 안전한 곳에서 수행해야 할 모든 중요한 작업을 처리합니다.

Edge Functions이 처리해야 할 것

사용자 인증 및 권한 부여

작업을 수행하기 전에 항상 사용자가 주장하는 사람인지 확인
특정 작업에 대한 올바른 권한이 있는지 확인
누군가가 로그인했다고 주장한다고 해서 신뢰하지 않음

데이터 유효성 검사 및 살균

들어오는 모든 데이터가 올바른 형식인지 확인
사용자 입력에서 잠재적으로 유해한 콘텐츠 제거
데이터가 처리되기 전에 비즈니스 규칙을 충족하는지 확인

비즈니스 로직 및 워크플로우

주문 처리, 결제 계산 또는 사용자 등록 같은 복잡한 비즈니스 프로세스 처리
다른 데이터 조각 간의 관계 관리
단일 작업에서 여러 단계 조정

외부 서비스 통합

결제 처리업체, 이메일 제공업체 또는 API 같은 타사 서비스에 안전하게 연결
민감한 API 키와 자격 증명을 안전하게 유지
오류와 타임아웃을 우아하게 처리

민감한 데이터 처리

개인 정보, 금융 데이터 또는 기타 민감한 콘텐츠 처리
필요할 때 암호화 또는 기타 보안 조치 적용
보안 감사를 위한 중요한 이벤트 로깅

Edge Functions의 보안 이점

격리: Edge functions은 frontend와 분리된 보안 환경에서 실행되므로 공격자가 민감한 코드나 데이터에 접근하기가 훨씬 어렵습니다.

중앙 집중식 보안: 모든 보안 검사가 한 곳에서 발생하므로 보안 정책을 유지하고 업데이트하기 쉽습니다.

클라이언트 측 노출 없음: 민감한 비즈니스 로직이 사용자 브라우저에 도달하지 않아 볼 수 있거나 수정할 수 없습니다.

일관된 유효성 검사: 모든 요청이 동일한 유효성 검사 프로세스를 거쳐 애플리케이션 전체에서 일관된 보안을 보장합니다.

보안 Edge Functions을 위한 프롬프트 예시

Create an edge function for user registration with proper validation and security checks. Users should provide email, password, and optional profile picture during sign-up

Move payment processing logic from frontend to secure edge function. I have a checkout component that currently processes Stripe payments directly in the browser

Build edge function for file uploads with type and size validation. Users can upload profile pictures (max 5MB) and documents (PDF only, max 10MB)

Set up edge function to send welcome emails securely when users sign up. Use provider API to send personalized welcome emails with user's name and account details

Implement edge function for processing webhook events from external services. Handle Stripe payment confirmations and update order status in database

더 많은 프롬프트는 Lovable 프롬프트 라이브러리를 참조하세요.

데이터베이스 보안: RLS를 간단하게 유지하고 일찍 시작하기

Lovable에서의 Row Level Security (RLS)

Lovable은 테이블에 대한 기본 RLS 정책을 자동으로 설정하지만, 앱의 보안 필요에 따라 검토하고 커스터마이즈해야 합니다. RLS를 데이터베이스에서 누가 어떤 데이터를 보고 수정할 수 있는지 결정하는 규칙으로 생각하세요.

초기 검토가 중요합니다: 사용자가 이미 데이터를 만든 후보다 앱이 새로울 때 RLS 정책을 조정하는 것이 훨씬 쉽습니다.

간단함이 안전함: RLS 정책을 간단하게 유지하고 복잡한 비즈니스 로직이 아닌 데이터 접근에 집중하세요. Lovable의 기본 정책은 보통 좋은 시작점입니다.

Lovable 앱의 일반적인 RLS 패턴

개인 데이터 보호

사용자는 자신의 프로필, 설정, 개인 데이터만 볼 수 있어야 함
기본 패턴: "사용자는 자신의 데이터에만 접근할 수 있음"

팀 기반 접근

팀 멤버는 팀 내 공유 프로젝트 데이터를 볼 수 있음
패턴: "사용자는 자신이 속한 팀의 데이터에 접근할 수 있음"

소유권이 있는 공개 콘텐츠

누구나 읽을 수 있지만 소유자만 편집할 수 있는 공개 게시물
패턴: "누구나 읽을 수 있고, 소유자만 수정할 수 있음"

조직 기반 접근

회사 직원이 회사 데이터에 접근할 수 있음
패턴: "사용자는 자신의 조직 데이터에 접근할 수 있음"

Lovable 앱에서 RLS 검토하기

테이블 확인

RLS가 활성화된 테이블 검토
민감한 데이터 테이블이 보호되는지 확인
공개 데이터 테이블에 적절한 읽기 정책이 있는지 확인

접근 패턴 테스트

사용자가 자신의 데이터만 볼 수 있는지 확인
공유 데이터가 올바른 사람들에게 접근 가능한지 테스트
공개 데이터가 모든 사람에게 표시되는지 확인

찾아야 할 일반적인 문제

민감한 데이터에 RLS가 활성화되지 않은 테이블
너무 많은 데이터를 노출하는 과도하게 허용적인 정책
새 테이블이나 기능에 대한 누락된 정책

RLS 검토를 위한 프롬프트 예시

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

Check RLS policies for users and posts tables - users should only see their own profile but can read all public posts

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

Fix overly permissive access - users currently see all posts from all users, restrict to own posts and public posts only

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

Ensure users can only access data from their own organization in my multi-tenant app

Audit RLS policies for security holes where users might access unauthorized data

Simplify complex RLS policies while maintaining security - current policies are too complicated

빠른 RLS 체크리스트

모든 민감한 테이블에 RLS 활성화
사용자가 자신의 개인 데이터에만 접근 가능
공유 데이터에 적절한 접근 제어
새 테이블이 자동으로 RLS 정책을 받음
정책이 간단하고 이해하기 쉬움

인증 보안: 로직을 서버 측에 유지하기

인증 로직은 서버에서 실행되어야 합니다

모든 인증 결정, 토큰 유효성 검사, 사용자 확인은 브라우저가 아닌 서버 측에서 이루어져야 합니다. 클라이언트 측 인증은 쉽게 우회하거나 조작할 수 있습니다.

핵심 원칙:

클라이언트 측 인증 검사를 신뢰하지 마세요 - 사용자가 브라우저 코드를 수정할 수 있음
서버에서 토큰 유효성 검사 - 항상 edge functions에서 인증 확인
세션 관리를 서버 측에 유지 - Supabase가 안전한 세션 저장소를 처리하도록
인증 secrets을 절대 노출하지 마세요 - API 키와 토큰이 frontend에 도달하면 안 됨

안전한 인증 흐름

// ❌ WRONG - 클라이언트 측 인증 로직
const isAuthenticated = localStorage.getItem('authToken') !== null;
if (isAuthenticated) {
  // 사용자가 우회할 수 있음
  showAdminPanel();
}

// ✅ CORRECT - 서버 측 인증 유효성 검사
// edge function에서:
const { user } = await supabase.auth.getUser();
if (!user) {
  return new Response('Unauthorized', { status: 401 });
}
// 인증된 로직으로 진행