React Server Components 보안 취약점

지금 안 고치면 실제로 생기는 문제들

React Server Components(RSC)는 성능과 DX를 크게 끌어올렸지만, 보안 관점에서는 아직 ‘안전 기본값’이 아닙니다. 지금 조치하지 않으면 단순한 버그를 넘어 실제 서비스 장애와 정보 노출로 이어질 수 있습니다.

왜 React Server Components가 위험해졌을까?

RSC의 핵심은 “서버에서 실행되는 컴포넌트”입니다.

문제는 이 구조가 다음과 같은 오해를 낳는다는 점입니다.

• 서버에서 실행되니 안전하다
• 클라이언트에 코드가 안 내려가니 노출이 없다
• API 레이어를 줄였으니 공격 면적이 줄었다

👉 이 전제들이 모두 틀릴 수 있다는 것이 최근 보안 이슈의 핵심입니다.

문제 1️⃣ 서버 내부 코드와 데이터가 노출될 수 있습니다

어떤 문제가 발생하나요?

RSC는 서버에서 실행되지만, 렌더링 결과를 만들기 위해 내부 데이터에 접근합니다.

이 과정에서 검증 없이 외부 입력이 섞이면 다음 문제가 발생할 수 있습니다.

• 서버 환경 정보 노출
• 내부 API 응답 구조 노출
• 민감한 데이터가 HTML 스트림에 포함

실제로 생기는 결과

• .env 기반 값이 의도치 않게 노출
• 내부 DB 구조 추정 가능
• 관리자 전용 정보가 클라이언트에서 확인됨

❗ “코드는 안 보이지만, 결과는 보인다”는 점이 가장 위험합니다.

문제 2️⃣ DoS(서비스 거부) 공격에 취약해집니다

왜 RSC가 DoS에 취약한가?

RSC는 요청마다 서버에서 컴포넌트 렌더링 로직을 실행합니다.

즉, 다음과 같은 코드가 있을 경우:

// 위험한 패턴
const data = await fetchExternalAPI(searchParams.q);

공격자는:

• 무거운 쿼리 반복 요청
• 의도적인 대량 요청

을 통해 서버 리소스를 빠르게 소모시킬 수 있습니다.

결과적으로 생기는 문제

• 서버 응답 지연
• 트래픽 급증 시 서비스 다운
• 서버 비용 폭증 (특히 서버리스 환경)

문제 3️⃣ 인증·권한 우회 가능성이 생깁니다

흔히 발생하는 실수

// ❌ RSC에서 권한 체크를 UI 기준으로만 처리
{isAdmin && <AdminPanel />}

RSC는 서버에서 실행되기 때문에

권한 체크를 잘못하면 렌더 단계에서 이미 데이터가 생성됩니다.

실제 위험

• 로그인하지 않아도 데이터 일부 노출
• 권한 없는 사용자가 관리자 데이터 접근
• 로그에는 남지 않아 추적도 어려움

지금 안 고치면 어떤 일이 벌어질까?

👉 문제는 “언제 터지느냐”이지 “터지느냐”가 아닙니다.

지금 바로 해야 할 대응 방법

✅ 1. RSC에서 외부 입력은 무조건 검증

• searchParams, cookies, headers 모두 검증 대상
• Zod / Yup 스키마 필수

✅ 2. 데이터 접근은 서버 액션/API로 분리

• RSC = 조합
• 데이터 로직 = 서버 전용 레이어

✅ 3. 인증·권한 체크는 렌더 이전에

if (!session || !session.isAdmin) {
   redirect('/login');
}

✅ 4. 무거운 연산은 캐싱 + rate limit

• fetch cache 전략 명시
• 요청 제한 설정 필수

마무리 요약

• React Server Components는 기능이 아니라 구조 변화
• 구조 변화는 보안 전제도 함께 바꿔야 안전
• 지금 고치지 않으면 노출·장애·비용·신뢰가 동시에 무너질 수 있음

다음으로 읽으면 좋은 인사이트

• 👉 AI 코딩 도구가 놓치는 React 보안 취약점