← Back to NOTES 🌰 ← 프론트가 서버까지 확장될 때 생기는 비용 (RSC 이슈를 보며)
내가 보수적으로 반응하는 지점은 대체로 여기다.
attack surface가 늘어나는가?
attack surface: 외부에서 호출/공격 가능한 진입점(엔드포인트/액션/웹훅/업로드 등)의 총합
trust boundary를 넘는 입력을 서버가 어떻게 처리하는가?
trust boundary: 신뢰할 수 없는 입력(외부 요청)이 시스템 내부로 들어오는 경계
입력을 해석(디코딩/역직렬화)하는 단계가 추가되는가?
그 입력이 execution path(실제 서버 로직 실행)으로 이어지는가?
execution path: 그 입력이 실제 실행(서버 로직/런타임 동작)까지 이어지는 흐름
이 지점은 보통 서버 개발 쪽에서 더 익숙하게 다루는 영역이다. 외부 입력을 받는 순간, 인증/인가·입력 검증·레이트 리밋·로그 같은 것들을 “기능의 일부”로 취급하는 습관이 있기 때문이다. 프론트 쪽 런타임이 백엔드의 일부 역할을 보조하기 시작하면서, 입력 검증이나 관측(로그/모니터링) 같은 운영 관점도 자연스럽게 같이 따라오게 됐다.
프론트에서도 이 관점을 의식해야 하는 상황이 늘었다. 프론트 레이어에서 서버 기능을 함께 다루는 프레임워크가 많아졌기 때문이다.
그리고 여기서 중요한 건 이거다. “서버 입력 → 실행” 경로가 추가되면, 취약점/악용의 가능성이 더 많이 열린다.
공격은 대개 ‘입력 해석(디코딩/역직렬화)’ 구간을 찌른다. 그 결과가 실행 흐름에 연결되는 구조라면, 데이터 오류가 아니라 실행(RCE: 임의 코드 실행)로 튈 수 있다.
이번 RSC 이슈도 내 코드에서 JSON을 잘못 파싱해서 생긴 문제라기보다는, RSC/Server Actions 요청을 위해 프레임워크가 해석해야 하는 “전용 요청 포맷”이 존재하고, 그걸 디코딩/역직렬화하는 내부 구간에서 결함이 생겼을 때 파급이 커진 사례에 가깝다.
엑셀로 비유하면 더 빠르다. 엑셀 파일은 원래 데이터를 담는 그릇이다. 그런데 매크로가 붙는 순간부터는, 파일을 “읽는 행위”가 곧바로 “실행”으로 이어질 수 있다. 입력을 해석해서 실행 흐름에 붙이는 구조도 비슷하다. 디코딩/역직렬화 같은 해석 단계에서 결함이 생기면, 데이터 처리 문제가 아니라 실행 문제로 튈 수 있다.