프론트엔드 뉴스레터
#39
이번 이슈 한눈에
- Vite 개발 서버를
--host로 노출했다면 인증 없는 요청으로 코드가 실행될 수 있었어요. 4.0.0부터 영향을 받는데, 4.x·5.x에는 별도 패치가 없어 6.4.6 이상으로 올려야 합니다. - Vercel UI SDK는 키보드 이동·포커스·팝업·드래그앤드롭 같은 컴포넌트 동작을 여러 프레임워크에서 가져다 쓰는 베타 라이브러리예요.
- e18e가 Next.js·Nuxt·Astro 등의 개발 비용과 실행 성능을 릴리스마다 비교하는 벤치마크를 공개했고, 측정 과정에서 React의 RSC 페이로드 파싱이 빨라졌어요.
- GraphQL over HTTP 스펙이 첫 릴리스되면서 오류에도 200을 돌려주던 관행에 기준이 생겼어요.
- 01
github.com
Vite 개발 서버를 네트워크에 열어 두면 원격 코드 실행이 가능했던 취약점 패치
원문 읽기 ↗휴대폰으로 화면을 확인하거나 같은 네트워크의 다른 기기에서 접속하려고 Vite 개발 서버를
--host로 띄우는 경우가 많죠. 이렇게 네트워크에 노출된 개발 서버에서는 인증 없는 HTTP 요청 하나로 개발 서버가 돌아가는 머신에서 임의 코드를 실행할 수 있었어요. 심각도는 Critical(CVSS v4 9.1)입니다.원인은 Vite가 요청 URL에서 만든 값을 자신이 생성하는 모듈 코드에 이스케이프 없이 넣은 데 있었어요. 공격자가 URL에 코드를 끼워 넣으면, 개발 서버가 브라우저에 내려줘도 되는 파일 범위(
server.fs허용 목록)를 우회해 그 밖의 파일을 읽거나 서버에서 코드를 실행할 수 있었습니다. Vite 4.0.0부터 영향을 받지만 패치는 8.x·7.x·6.x 계열에만 나왔어요. 4.x·5.x를 쓰고 있다면 별도 패치가 없으니 6.4.6 이상으로 올려야 합니다.--host나server.host로 개발 서버를 네트워크에 노출한 경우만 영향을 받아요. 패치 버전은vite8.3.7, 8.2.5, 8.1.7, 7.3.8, 6.4.6이고vite-plus는 1.5.1입니다.- Vite 8에서는 취약한 코드가 Rolldown 바이너리 안에 있어요. 패치된 Vite 8.x는 고쳐진 Rolldown 버전(1.2.17, 1.1.7)에 의존합니다.
- 02
ui-sdk.dev
Vercel, 컴포넌트 동작만 떼어 낸 UI SDK를 베타로 공개
원문 읽기 ↗드롭다운이나 메뉴를 직접 만들면 모양보다 동작에 더 많은 시간이 들어요. 화살표 키로 항목을 이동하고, 포커스를 옮기고, 맞는 ARIA 속성을 붙여야 하니까요. Vercel이 공개한 UI SDK는 이런 컴포넌트 동작을 스타일 없이 떼어 낸 TypeScript 라이브러리입니다. 예를 들어 화살표 키 이동은
createRovingFocus로 가져와 자기 컴포넌트에 조합해요. 글자를 입력해 항목을 찾는 동작, 팝업, 선택, 드래그앤드롭도 같은 방식으로 가져다 씁니다.같은 동작을 React, Vue, Svelte, Solid, Web Components에서 쓸 수 있어요. 만든 팀은 이 라이브러리를 "에이전트를 위해 만들었다"고 소개합니다. 코딩 에이전트가 검증된 동작 위에서 컴포넌트를 만들게 하려는 거예요.
createAgent를 쓰면 개발자가 허용한 컴포넌트·동작 범위 안에서 에이전트가 페이지를 읽고 조작할 수도 있습니다.- 베타라서 일부 API가 바뀔 수 있어요.
- 03
e18e.dev
e18e, 메타 프레임워크의 개발 비용과 실행 성능을 릴리스마다 추적하는 벤치마크 공개
원문 읽기 ↗e18e가 시작한 Framework Performance 프로젝트는 Next.js, Nuxt, Astro, SvelteKit 등 여러 메타 프레임워크를 두 가지 방식으로 측정합니다. 의존성 수와
node_modules크기, 빌드·dev 서버 시작 시간처럼 개발 단계에서 드는 비용은 각 프레임워크의 CLI나 문서가 권장하는 기본 starter 프로젝트로 재요. SSR 처리량·지연과 Lighthouse 지표 같은 실행 성능은 모든 프레임워크에 같은 앱을 구현해 비교합니다. HTTP Archive에서 가져온 실제 사이트의 Core Web Vitals도 함께 보여 주고, 결과는 릴리스마다 추적해요.측정하는 과정에서 프레임워크 쪽 수정도 이미 나왔어요. React는 RSC 페이로드 파싱이 약 75% 빨라졌고, 이를 쓰는 프레임워크도 함께 혜택을 받습니다. Nuxt는 내부 링크의 서버 렌더링 시간이 약 58% 줄었어요.
- HTTP Archive 데이터는 사이트의 호스팅과 사용 방식에 영향을 받고, 표본이 작으면 결과가 치우칠 수 있다고 프로젝트가 직접 밝히고 있어요.
- 04
graphql.org
GraphQL over HTTP 스펙 첫 릴리스로 오류에도 200을 보내던 관행에 기준이 생겼다
원문 읽기 ↗지금까지 많은 GraphQL 서버는
application/json으로 응답했어요. 그러면 클라이언트는 원 서버가 보낸 GraphQL 응답과 프록시·캐시 같은 중간 서버가 보낸 오류 응답을 구분하기 어렵습니다. 그래서 대부분의 구현은 오류가 나도200을 돌려주고, 클라이언트는200이면 GraphQL 응답으로 읽는 방식으로 이 문제를 피해 왔어요. GraphQL Foundation이 첫 릴리스를 발표한 GraphQL over HTTP 스펙이 이 응답 방식에 기준을 정했습니다.응답은
application/graphql-response+json미디어 타입을 써요. 클라이언트는 이 미디어 타입을 받으면 상태 코드와 관계없이 본문을 GraphQL 응답으로 읽을 수 있습니다. 상태 코드는 데이터가 있으면 2xx, 오류만 있으면 4xx나 5xx를 쓰고, 데이터와 오류가 함께 있을 때를 위해 새294 Partial Success도 소개했어요.- 발표에 따르면 대부분의 GraphQL 프레임워크와 라이브러리가 이미 이 스펙을 지원해요. URL 구조, GET·POST 요청, JSON 인코딩 같은 기존 관행은 대부분 그대로 문서화했습니다.
- 05
ccheever.expo.app
Expo 공동창업자의 새 프레임워크 Exact, 에이전트가 작성하기 쉬운 UI 언어를 택하다
원문 읽기 ↗Expo 공동창업자 Charlie Cheever가 Rust로 만든 앱 프레임워크 Exact를 pre-alpha로 공개했어요. UI는 JSX가 아니라 Contract라는 전용 언어로 씁니다. 들여쓰기 기반에 타입이 엄격하고
useEffect나 임의의 JavaScript를 넣을 수 없도록 일부러 기능을 제한했어요. 그만큼 컴파일러가 코드 전체를 분석할 수 있고, 컴파일 오류 메시지가 에이전트에게 올바른 문법을 알려 주는 구조입니다.컴파일 시점에 데이터 관계를 알기 때문에 가상 DOM이나 재렌더링, 별도의 하이드레이션 단계 없이 화면을 갱신해요. 에이전트가 시계를 제어해 애니메이션 도중 스크린샷이 어긋나지 않게 하는 등 에이전트가 앱을 검사하는 기능도 갖췄습니다. iOS 지원이 가장 성숙하고, 웹과 macOS는 쓸 만한 수준이라고 해요.
- pre-alpha라서 일부 기능은 아직 미완성이거나 동작하지 않아요. Expo는 기존 프레임워크 지원을 계속합니다.