React란?
웹 모의해킹을 하다 보면 대상 서비스가 React 기반으로 만들어진 경우를 자주 볼 수 있습니다.
이때 처음 보는 사람은 "React 서버인가?", "왜 버튼을 눌렀는데 패킷이 안 잡히지?", "JavaScript 파일 안에 API 경로가 보이는데
이게 취약점인가?" 같은 의문이 생길 수 있습니다.
React는 서버 기술이 아니라 웹 화면을 만드는 프론트엔드 기술입니다.
사용자가 보는 메뉴, 버튼, 게시글 목록, 팝업, 검색 화면 같은 부분을 브라우저에서 동적으로 만들어주는 역할을 합니다.
React는 어떻게 동작할까?
일반적인 웹 서비스는 사용자가 페이지에 접속하면 서버가 완성된 HTML 화면을 만들어서 브라우저에 내려줍니다.
사용자 요청 → 서버가 DB 조회 → 서버가 HTML 생성 → 브라우저에 완성된 화면 전달
반면 React 기반 웹 서비스는 처음에 기본 HTML과 JavaScript 파일을 내려주고, 브라우저가 그 JavaScript를 실행해서 화면을 구성합니다.
사용자 접속 → 서버가 index.html, JavaScript 파일 전달 → 브라우저에서 React 실행 → React가 화면 구성
→ 필요한 데이터는 API 서버에 요청 → API 응답 데이터를 화면에 표시
즉, React는 화면을 담당하고, 실제 로그인 확인, 권한 검증, 데이터 조회·저장·수정·삭제는 API 서버에서 처리합니다.
쉽게 말하면 React는 화면을 조립하는 역할이고, API 서버는 실제 데이터를 처리하는 역할입니다.
일반 서버 방식과 React 방식의 차이
일반 서버 방식에서는 서버가 화면을 완성해서 내려줍니다.
예를 들어 게시글 목록 페이지에 접속하면 서버가 게시글 데이터를 조회한 뒤, 게시글 목록이 포함된 HTML을 바로 응답할 수 있습니다.
반면 React 방식에서는 처음에는 화면의 틀만 로드되고, 이후 API를 호출해서 게시글 데이터를 받아옵니다.
예를 들면 아래와 같은 API 요청이 발생할 수 있습니다.
GET /api/board/list
서버는 게시글 데이터를 JSON 형태로 응답하고, React는 그 데이터를 받아서 화면에 게시글 목록처럼 보여줍니다.
[
{
"title": "공지사항",
"writer": "admin",
"createdAt": "2026-07-04"
}
]
그래서 React 기반 서비스에서는 페이지 URL보다 API 요청과 응답이 더 중요한 점검 대상이 되는 경우가 많습니다.
React Shell이란?
React Shell은 React 앱의 기본 화면 껍데기라고 보면 됩니다.
사이트에 처음 접속했을 때 로드되는 기본 레이아웃, 메뉴, 헤더, 사이드바, 라우팅 구조 등이 여기에 해당합니다.
- React Shell = 화면의 기본 틀
- API 데이터 = 게시글, 사용자 정보, 파일 목록 같은 실제 내용
예를 들어 관리자 페이지에 접속했을 때 상단 메뉴, 왼쪽 메뉴, 빈 목록 화면은 먼저 보이고, 실제 사용자 목록은 API 호출 후 표시될 수 있습니다.
(React Shell이나 JavaScript 파일 안에서 아래와 같은 단서를 찾을 수 있음.)
/admin
/dashboard
/api/v1/admin/users
/api/v1/file/download
ADMIN
USER
accessToken
refreshToken
이런 정보가 보인다고 해서 전부 취약점은 아닙니다.
다만 숨겨진 화면 경로, 관리자 API, 파일 다운로드 API, 권한명 등을 찾는 단서로 활용할 수 있습니다.
React 기반 서비스 점검 시 중요한 관점
React 기반 서비스라고 해서 완전히 새로운 취약점을 보는 것은 아닙니다.
인증, 권한 검증, 입력값 검증, 파일 다운로드, 데이터 노출 같은 기본 점검 기준은 일반 웹 서비스와 같습니다.
React 기반 서비스에서는 화면보다 API를 기준으로 보는 것이 중요합니다.
화면에서 관리자 메뉴가 보이지 않더라도, JavaScript 파일이나 Network 탭에서 관리자 API 경로가 확인될 수 있습니다.
이때 일반 사용자 권한으로 해당 API를 직접 호출했을 때 서버에서 차단되는지 확인해야 합니다.
[정상 로직]
[request]
GET /api/v1/admin/users
Authorization: Bearer 일반사용자토큰
[response]
HTTP/1.1 403 Forbidden
[결함 로직]
일반 사용자 권한으로 관리자 데이터가 응답되는 경우.
[
{
"userId": "admin",
"name": "관리자",
"role": "ADMIN"
}
]
React에서 관리자 메뉴를 숨기는 것은 보안 조치가 아닙니다. 실제 보안 검증은 API 서버에서 이루어져야 합니다.
React2Shell (CVE-2025-55182) 사례로 보는 API 검증의 중요성
React 기반 서비스에서 화면(Shell)보다 API 검증이 왜 중요한지 보여주는 실제 사례가 있습니다.
바로 2025년 12월에 공개된 React2Shell 취약점입니다.
이 취약점은 2025년 12월 3일 공개된, React Server Components(RSC)에 존재하는 인증 없이도 원격 코드 실행이 가능한 심각한 취약점으로, CVE-2025-55182로 등록되었습니다.
CVSS 10.0의 최고 위험도를 받았으며 서버가 완전히 장악될 수 있는 수준의 취약점입니다.
원인은 화면 자체의 결함이 아니라 RSC가 서버와 화면 사이에서 데이터를 주고받는 Flight 프로토콜에서, 공격자가 조작한 데이터를 서버가 제대로 검증하지 않고 처리하던 역직렬화 로직에 있었습니다.
공격자는 단 하나의 악성 HTTP 요청만으로 서버에서 임의의 코드를 실행시킬 수 있었습니다.
이 취약점은 App Router를 사용하는 React 19.x, Next.js 15.x·16.x 버전에 영향을 줬으며, 공개 직후 국가 배후 해킹 조직부터 일반 사이버 범죄자까지 다양한 공격 그룹이 실제로 이를 악용한 정황이 확인되었습니다.
앞서 설명했던 것처럼 React Shell이나 화면 구조가 아무리 안전해 보여도, 실제 문제는 서버가 데이터를 받아 처리하는 API·프로토콜 단에서 발생한다는 것입니다.
그래서 모의해킹 시에는 화면에 무엇이 보이는지가 아니라, React가 서버와 주고받는 요청·응답 자체를 점검 대상으로 삼아야 합니다.
마무리
React 기반 서비스는 브라우저에서 화면을 만들고, 필요한 데이터는 API 서버에 요청해서 받아오는 구조입니다.
점검 시 React가 호출하는 API에서 서버 권한 검증이 제대로 되는지 확인하는 것이 포인트! 입니다.
React란?
웹 모의해킹을 하다 보면 대상 서비스가 React 기반으로 만들어진 경우를 자주 볼 수 있습니다.
이때 처음 보는 사람은 "React 서버인가?", "왜 버튼을 눌렀는데 패킷이 안 잡히지?", "JavaScript 파일 안에 API 경로가 보이는데
이게 취약점인가?" 같은 의문이 생길 수 있습니다.
React는 서버 기술이 아니라 웹 화면을 만드는 프론트엔드 기술입니다.
사용자가 보는 메뉴, 버튼, 게시글 목록, 팝업, 검색 화면 같은 부분을 브라우저에서 동적으로 만들어주는 역할을 합니다.
React는 어떻게 동작할까?
일반적인 웹 서비스는 사용자가 페이지에 접속하면 서버가 완성된 HTML 화면을 만들어서 브라우저에 내려줍니다.
반면 React 기반 웹 서비스는 처음에 기본 HTML과 JavaScript 파일을 내려주고, 브라우저가 그 JavaScript를 실행해서 화면을 구성합니다.
즉, React는 화면을 담당하고, 실제 로그인 확인, 권한 검증, 데이터 조회·저장·수정·삭제는 API 서버에서 처리합니다.
쉽게 말하면 React는 화면을 조립하는 역할이고, API 서버는 실제 데이터를 처리하는 역할입니다.
일반 서버 방식과 React 방식의 차이
일반 서버 방식에서는 서버가 화면을 완성해서 내려줍니다.
예를 들어 게시글 목록 페이지에 접속하면 서버가 게시글 데이터를 조회한 뒤, 게시글 목록이 포함된 HTML을 바로 응답할 수 있습니다.
반면 React 방식에서는 처음에는 화면의 틀만 로드되고, 이후 API를 호출해서 게시글 데이터를 받아옵니다.
예를 들면 아래와 같은 API 요청이 발생할 수 있습니다.
서버는 게시글 데이터를 JSON 형태로 응답하고, React는 그 데이터를 받아서 화면에 게시글 목록처럼 보여줍니다.
그래서 React 기반 서비스에서는 페이지 URL보다 API 요청과 응답이 더 중요한 점검 대상이 되는 경우가 많습니다.
React Shell이란?
React Shell은 React 앱의 기본 화면 껍데기라고 보면 됩니다.
사이트에 처음 접속했을 때 로드되는 기본 레이아웃, 메뉴, 헤더, 사이드바, 라우팅 구조 등이 여기에 해당합니다.
예를 들어 관리자 페이지에 접속했을 때 상단 메뉴, 왼쪽 메뉴, 빈 목록 화면은 먼저 보이고, 실제 사용자 목록은 API 호출 후 표시될 수 있습니다.
(React Shell이나 JavaScript 파일 안에서 아래와 같은 단서를 찾을 수 있음.)
이런 정보가 보인다고 해서 전부 취약점은 아닙니다.
다만 숨겨진 화면 경로, 관리자 API, 파일 다운로드 API, 권한명 등을 찾는 단서로 활용할 수 있습니다.
React 기반 서비스 점검 시 중요한 관점
React 기반 서비스라고 해서 완전히 새로운 취약점을 보는 것은 아닙니다.
인증, 권한 검증, 입력값 검증, 파일 다운로드, 데이터 노출 같은 기본 점검 기준은 일반 웹 서비스와 같습니다.
React 기반 서비스에서는 화면보다 API를 기준으로 보는 것이 중요합니다.
화면에서 관리자 메뉴가 보이지 않더라도, JavaScript 파일이나 Network 탭에서 관리자 API 경로가 확인될 수 있습니다.
이때 일반 사용자 권한으로 해당 API를 직접 호출했을 때 서버에서 차단되는지 확인해야 합니다.
[정상 로직]
[결함 로직]
일반 사용자 권한으로 관리자 데이터가 응답되는 경우.
React에서 관리자 메뉴를 숨기는 것은 보안 조치가 아닙니다. 실제 보안 검증은 API 서버에서 이루어져야 합니다.
React2Shell (CVE-2025-55182) 사례로 보는 API 검증의 중요성
React 기반 서비스에서 화면(Shell)보다 API 검증이 왜 중요한지 보여주는 실제 사례가 있습니다.
바로 2025년 12월에 공개된 React2Shell 취약점입니다.
이 취약점은 2025년 12월 3일 공개된, React Server Components(RSC)에 존재하는 인증 없이도 원격 코드 실행이 가능한 심각한 취약점으로, CVE-2025-55182로 등록되었습니다.
CVSS 10.0의 최고 위험도를 받았으며 서버가 완전히 장악될 수 있는 수준의 취약점입니다.
원인은 화면 자체의 결함이 아니라 RSC가 서버와 화면 사이에서 데이터를 주고받는 Flight 프로토콜에서, 공격자가 조작한 데이터를 서버가 제대로 검증하지 않고 처리하던 역직렬화 로직에 있었습니다.
공격자는 단 하나의 악성 HTTP 요청만으로 서버에서 임의의 코드를 실행시킬 수 있었습니다.
이 취약점은 App Router를 사용하는 React 19.x, Next.js 15.x·16.x 버전에 영향을 줬으며, 공개 직후 국가 배후 해킹 조직부터 일반 사이버 범죄자까지 다양한 공격 그룹이 실제로 이를 악용한 정황이 확인되었습니다.
앞서 설명했던 것처럼 React Shell이나 화면 구조가 아무리 안전해 보여도, 실제 문제는 서버가 데이터를 받아 처리하는 API·프로토콜 단에서 발생한다는 것입니다.
그래서 모의해킹 시에는 화면에 무엇이 보이는지가 아니라, React가 서버와 주고받는 요청·응답 자체를 점검 대상으로 삼아야 합니다.
마무리