Next.js 15.2.3, Middleware 우회 취약점 패치 출시

 (nextjs.org)
1P by GN⁺ | ★ favorite | 댓글 1개
  • Next.js 팀은 CVE-2025-29927로 공개된 Middleware 우회 취약점을 패치하고, 신고부터 공개까지의 사고 타임라인과 개선책을 공개함
  • 문제의 핵심은 내부 헤더 x-middleware-subrequest 가 Middleware 재귀 방지와 실행 우회에 함께 쓰인 구조였고, 패치는 해당 헤더를 검증한 뒤 실패 시 제거하는 방식임
  • 영향은 next start와 output: 'standalone'을 쓰는 self-hosted Next.js 애플리케이션에 집중됐으며, static export, Vercel, Netlify, Cloudflare Workers는 영향이 없는 것으로 확인됨
  • Next.js 14.2.25와 15.2.3 패치가 2025년 3월 17~18일 공개됐고, 커뮤니티 피드백 이후 13.5.9와 12.3.5 백포트도 추가됨
  • 후속 조치로 파트너 메일링 리스트, GitHub private vulnerability reporting 중심의 신고 절차, LTS 정책, 공식 배포 어댑터 API, Middleware 보안 평가가 진행됨

CVE-2025-29927 처리 타임라인

  • 2025년 2월 27일 06:03 GMT, 취약점이 GitHub private reporting을 통해 Next.js 팀에 전달됐고 연구자들은 security@vercel.com에도 이메일을 보냄
    • 최초 보고는 Next.js 12.x 같은 오래된 버전 범위를 중심으로 다뤄져 triage 큐에서 낮은 우선순위를 받음
  • 2025년 3월 1일 02:00 GMT, 새 이메일 스레드로 추가 보고가 들어오며 영향 범위가 더 최근 버전까지 확장됨
    • 여러 보고와 내부 논의가 겹치면서 triage가 지연됨
  • 2025년 3월 5일, Next.js 팀은 보고의 유효성과 잠재 영향을 파악하기 위한 조사를 시작함
    • 보안팀은 10:38 GMT에 Next.js 11.x와 12.x를 보안 패치 지원 대상에서 제외하는 LTS 정책 계획을 답변함
  • 2025년 3월 14일 17:18 GMT, 보안팀이 보고를 Next.js 팀에 전달해 영향과 수정 방안 검토가 시작됐고, Next.js 엔지니어링 팀은 취약점이 유효하다고 확인함

어떤 배포가 영향을 받았나

  • Next.js는 여러 방식으로 호스팅될 수 있어 배포 경로별 확인이 필요했음
  • Static export는 서버 런타임 없이는 Middleware를 사용할 수 없어 즉시 영향 대상에서 제외됨
  • next start와 output: 'standalone'을 사용하는 self-hosted Next.js 애플리케이션은 영향을 받는 것으로 확인됨
  • Vercel은 Next.js 라우팅 로직이 분리돼 별도 시스템에서 전 세계적으로 실행되기 때문에 해당 취약점의 영향을 받지 않음
  • 오픈소스 Next.js 배포 어댑터도 검토됐으며, Netlify와 Cloudflare Workers는 애플리케이션 라우팅 분리라는 같은 이유로 영향을 받은 적이 없는 것으로 확인됨

패치 방식과 공개 과정

  • 2025년 3월 14일 금요일, forward fix는 x-middleware-subrequest 검증을 추가하고 검증 실패 시 필터링하는 방식으로 정해짐
    • 업그레이드할 수 없는 애플리케이션에는 해당 헤더가 Next.js 서버에 도달하기 전에 필터링하는 우회책이 제시됨
    • 팀은 Next.js 15.x와 14.x 패치 준비를 시작함
  • 2025년 3월 17일 17:54 GMT, 패치를 포함한 pull request가 Next.js GitHub 저장소에 열림
    • 20:56 GMT에 merge됨
    • Next.js 14.2.25 패치는 22:44 GMT에 릴리스됨
    • Next.js 15.2.3 패치는 2025년 3월 18일 00:23 GMT에 릴리스됨
  • CVE-2025-29927는 2025년 3월 18일 18:03 GMT에 GitHub에서 발급됨
  • CVE는 2025년 3월 21일 10:17 GMT에 공개됨
    • 당시 공개 정보는 CVE에 담긴 내용뿐이라 이슈의 영향을 이해하기에 충분한 세부 사항이 부족했음
    • Netlify와 Cloudflare Workers가 영향을 받지 않는다는 점은 검증됐지만, 해당 팀과의 커뮤니케이션이 필요했음
    • 다른 인프라 제공자와 인증 파트너에 대한 선제적 커뮤니케이션도 미흡했음

커뮤니케이션 혼선과 백포트

  • CVE가 Vercel 애플리케이션의 영향 여부를 즉시 명시하지 않아, Vercel은 고객이 보호되고 있다는 changelog를 빠르게 공개함
    • 해당 changelog는 이전 해결 사례의 같은 템플릿을 사용했고 Firewall을 언급해 혼란을 줬으며, 취약점 자체에 필요한 세부 정보를 충분히 제공하지 못함
  • Next.js 사이트에는 전체 postmortem에 앞서 CVE를 설명하는 블로그 글이 공개됐고, 공식 소셜 채널에도 공유됨
  • 2025년 3월 22일 21:21 GMT, Next.js 13.5.9 백포트가 공개됨
    • 이 버전은 공개된 LTS 정책 밖에 있지만, 커뮤니티 피드백을 바탕으로 예외가 적용됨
  • 2025년 3월 23일 06:44 GMT, Next.js 12.3.5 추가 백포트가 공개됨

기술적 원인

  • Middleware는 응답을 생성하기 전에 들어오는 요청을 redirect, rewrite, 수정할 수 있게 하며, 캐싱과 라우팅보다 먼저 실행됨
  • 일부 Next.js 애플리케이션은 쿠키를 확인해 사용자의 인증 상태를 낙관적으로 검증하는 패턴을 Middleware에서 사용함
    • 인증 쿠키가 있으면 로그인된 애플리케이션으로 일찍 redirect하거나 특정 route를 차단할 수 있음
    • Next.js 팀은 Middleware를 애플리케이션 route 보호의 유일한 방법으로 쓰는 방식을 권장하지 않음
  • Next.js는 내부 헤더 x-middleware-subrequest 를 사용해 재귀를 감지하고 방지하며 Middleware 실행을 우회함
    • Middleware는 페이지 렌더링 프로세스와 별도로 실행됨
    • Middleware 내부에서 앱으로 fetch할 때, Middleware가 이미 실행됐다는 신호를 라우팅 프로세스에 전달하기 위해 내부 헤더가 활용됨
  • 취약점 세부 내용은 보고자의 글 Next.js and the corrupt middleware에서 더 읽을 수 있음

재발 방지를 위한 후속 조치

  • Partner mailing list를 열어 Next.js에 의존하는 파트너와 다른 인프라 제공자와 더 선제적으로 협력함
    • 포함을 원하는 파트너는 partners@nextjs.org로 연락할 수 있음
  • Next.js 보안 신고는 security@vercel.com과 responsible.disclosure@vercel.com을 통합해 GitHub private vulnerability reporting만 사용하도록 정리됨
    • 들어오는 보고를 더 효과적으로 triage하기 위한 변경임
  • 공개 취약점 대응 방식과 Next.js 취약점 runbook이 개선됨
    • 오픈소스에서 Next.js 같은 프레임워크로 넘어오는 보고 triage
    • 보안 엔지니어와 Next.js 팀의 협업 방식
  • 어떤 버전이 패치를 적극 지원받는지 설명하는 LTS 정책이 공개됨
  • 이번 취약점은 문서화되지 않은 내부 헤더에 의존했기 때문에, Netlify와 Cloudflare 같은 파트너와 공식 deployment adapters API를 구현하면서 내부 헤더를 문서화하거나 적절한 API로 대체할 예정임
  • Middleware 보안을 개선할 추가 지점이 있는지 더 조사 중이며, 이후 발견되는 이슈는 새 CVE 프로세스를 따름

책임 있는 공개

  • 보안 연구자 Rachid Allam과 Yassir Alam이 이 문제를 책임 있게 공개함
  • 두 연구자는 버그 바운티 프로그램의 일부로 보상금을 받음

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 솔직히 Next의 미들웨어 시스템 전체가 형편없고, 폐기한 뒤 처음부터 다시 구현하는 편이 모두에게 나을 듯함
    우선 여러 미들웨어를 체이닝하는 공식 방법이 없음. 여러 일을 하려면 한 함수에 다 욱여넣거나 체이닝 로직을 직접 구현해야 함. 더 나쁜 건 next, redirect, rewrite 같은 핵심 함수가 가져온 객체의 정적 멤버라서, 서드파티 미들웨어를 쓰면 자동으로 잘못 동작하며 체이닝을 깨뜨리기 쉬움
    미들웨어와 라우트 핸들러 사이에 정보를 전달할 좋은 방법도 없음. 실제로 동작하던 방식은 데이터를 헤더에 넣고 headers()로 다시 꺼내는 식이었는데, 내부 헤더 이름을 누군가 알면 매우 위험할 수 있음
    게다가 headers()를 쓰면 라우트 핸들러가 동적 처리로 바뀌어 자동 캐싱에서 빠짐. Next 14의 두 번째로 큰 기능을 미들웨어 데이터가 필요하다는 이유만으로 잃는 셈이었음
    마지막으로 정보도 숨김. request.hostname은 항상 localhost이고, 필요한 다른 속성들도 가려져 있음. 실제 호스트명을 얻으려면 "Host" 헤더에서 직접 꺼내야 했음. 헤더/미들웨어 시스템이 안전하지 않다는 게 놀랍지 않음

    • Next.js에서 가장 큰 불만이 이거임. 미들웨어 구현이 끔찍함
      미들웨어에서 요청으로 정보를 전달할 방법이 없으니 사람들이 JSON 객체를 문자열로 인코딩해서 헤더에 넣고, 요청 쪽에서 headers()로 읽음. 거기에 세션/인증 정보까지 넣음
      이것만으로도 이 프레임워크를 누구에게도 추천하지 않겠음
    • 실제로 여기서 말하는 Interceptors를 작업 중인 것으로 보임: https://github.com/vercel/next.js/pull/70961
    • 잠깐, Express에 몇 년 전부터 있던 메커니즘이 Next.js에서는 망가져 있다는 얘기임? 농담 같음
    • 미들웨어를 체이닝하거나 미들웨어끼리 통신하려는 순간 이미 잘못 잡고 있다고 봄. 거의 모든 다른 프레임워크에서도 객체에 데이터를 붙여놓고 잘 되길 바라는 것 말고는 안전하고 좋은 방법이 없음. 깨지기 쉽고, 타입 안전하지 않고, 전반적으로 나쁜 설계임
      그렇다 해도 Next.js 미들웨어가 형편없다는 데는 동의함. 주된 불만은 Next.js를 Vercel에서 안 쓰고 항상 Node에서 돌리는데도, 미들웨어가 엣지 안전성을 전제로 해서 사용할 수 있는 게 제한된다는 점임. 이건 고치고 있다지만, 이런 일이 Next에서는 전형적임
    • JavaScript는 이런 용도로 만들어진 게 아님. 브라우저에 머물렀어야 함

  • 더 자세한 글을 찾았음: https://zeropath.com/blog/nextjs-middleware-cve-2025-29927-a...
    이건 우회가 너무 쉬워 보임
    더 일반적으로, 신뢰할 수 없는 사용자 입력에도 쓰이는 같은 메커니즘으로 미들웨어가 통신한다는 발상 자체가 꽤 거칠어 보임. 사용자 요청 검증 코드를 작성해야 하는 위치, 즉 요청이 도착한 즉시 처리해야 하는 부분과 미들웨어 자체를 분리해 버림
    사용자 헤더를 허용 목록 일부만 빼고 전부 받는 것도 사고를 기다리는 설계 같음. 요청의 일부가 유효하면 알 수 없거나 잘못된 부분은 무시해도 된다는 사고방식도 한몫한 듯함
    프레임워크가 나쁜 서버 설계를 보조하는 것도 이런 사고방식의 결과임. 요청 처리 흐름이 유향 비순환 그래프가 아니어야 하는 구체적 사용 사례가 있나? 인증 경계를 넘어 재귀 요청을 허용하는 것도 문제를 부를 수밖에 없어 보임

    • 이건 예전 전화 프리킹이 작동하던 방식과 거의 같음. 시간은 평평한 원임
    • 서명된 헤더나 추가 인증 토큰 같은 메커니즘은 있지만, 여기서 그런 걸 써야 한다는 사실 자체가 프레임워크 내부 정보 전달에 헤더를 쓰는 일이 얼마나 터무니없는지 바로 보여줌
      비슷한 사례로 x-forwarded-for 헤더를 인증/인가에 잘못 신뢰하는 문제가 있음
      이건 Vercel이 Next.js에 “미들웨어는 엣지 함수에서 돈다”는 이상한 모델을 밀어붙인 결과처럼 보임. 샌드박스라 인메모리 요청 상태에 접근할 수 없으니, 프레임워크 나머지 부분과 통신하려면 헤더 같은 인밴드 메커니즘밖에 없었던 것 같음. 이런 이해가 맞나?
      수정은 사실상 임의 문자열을 다른 헤더로 추가하고 나중에 그대로 있는지 확인하는 방식, 즉 인증 토큰에 가까움: https://github.com/vercel/next.js/pull/77201/files
    • HTTP를 다루다 보면 인밴드 신호가 사실상 표준처럼 보임. HTTP 요청을 표준 형식으로 감싸고, 신뢰된 메타데이터를 함께 담아 다른 서비스로 HTTP를 통해 전달하는 표준 메커니즘이 딱히 없음
      혹시 그런 게 있고 내가 놓친 거라면 제발 알려줬으면 함
    • 그 “글”은 AI가 만든 저품질 글처럼 보임. 미들웨어에서 if (request.headers.has('x-middleware-subrequest'))를 검사하라고 수정안을 제시하는데, 취약점 자체가 그 헤더가 있으면 미들웨어가 실행되지 않는 것임
    • “허용 목록 일부를 제외한 모든 사용자 헤더를 받는 건 사고를 기다리는 일”이라는 데는 동의하지 않음
      브라우저와 ISP는 임의 헤더를 붙여온 역사가 길고, 웹사이트가 모르는 헤더마다 오류를 내면 동작할 수 없음. HTTP가 원래 그런 식임
      이건 명백히 Next 개발자들이 어리석게 처리한 사례임. 최소한 표준적인 x- 대신 -vercel- 같은 접두사를 써서 방화벽이 와일드카드로 쉽게 걸러낼 수 있게 했어야 함

  • Next.js에는 비슷한 취약점 이력이 있음
    최근 이 패치로 고쳐진 취약점을 알게 됨: https://github.com/vercel/next.js/pull/73482/files
    이 취약점에서는 'x-middleware-rewrite: [https://www.example.com](<https://www.example.com>;)' 헤더를 추가하면 서버가 example.com의 내용을 응답함. 말하자면 세상에서 가장 멍청한 SSRF였음
    이 취약점에는 CVE도 없고, 어떤 버전이 영향을 받는지 명확한 정보도 없음
    또한 공개된 Next.js 지원 정책에 따르면 “stable”(15.2.x)과 “canary”(15.3.x)만 패치를 받는다고 되어 있음. 그런데 이번 취약점은 14.x와 13.x에도 패치를 내는 듯함
    https://github.com/vercel/next.js/blob/canary/contributing/r...
    보안과 유지보수가 중요한 곳에서 Next.js를 쓰는 건 불장난이라고 봄. GitHub 별이 13만 개가 넘고 Vercel 같은 대기업이 지원하는 프로젝트라는 점을 생각하면 말이 안 됨

    • 링크한 커밋은 외부 사용을 막으려고 INTERNAL_HEADERS에 헤더를 잔뜩 추가했는데, 이번 취약점의 그 헤더는 빠뜨렸음. 이게 2024년 12월에 된 일임. 그 커밋 전에는 이런 헤더 관련 취약점이 수없이 있었을 가능성이 큼. CVE가 없었다는 게 놀라움
    • 여기서는 좀 자제와 품격이 필요함. Vercel은 겨우 5억 3,800만 달러밖에 투자받지 않았으니, 제품의 비즈니스 가치를 감안하면 보안 관행을 그렇게 비판하는 건 합리적이지 않음
    • Clerk의 Next.js SDK에도 같은 수준의 치명적 취약점이 있었고, 그게 경종이 됐어야 함
      https://clerk.com/changelog/2024-02-02#:~:text=Our%20solutio...
    • “Next.js는 2016년 이후 16개의 보안 권고를 공개했다”는 문구는 처음 읽으면 꽤 합리적으로 들림: https://nextjs.org/blog/cve-2025-29927
      그런데 모든 취약점에 보안 권고가 붙은 건 아니라는 걸 깨닫게 됨

  • 실행이 이렇게 사소한 취약점이라는 게 놀라움. 그런데 더 놀라운 건 버그가 보고된 뒤 분류를 시작하기까지 걸린 시간임. 어떻게 이런 일이 생겼나? 이름이 잘못 붙었나? 심각도가 제대로 전달되지 않았나? 2주 넘게 방치된 이유를 이해하고 싶음
    2025-02-27T06:03Z: GitHub 비공개 취약점 보고를 통해 Next.js 팀에 공개
    2025-03-14T17:13Z: Next.js 팀이 보고서 분류 시작

    • “명백한” 치명적 취약점이고 어느 Next.js 앱에도 쉽게 쓸 수 있는데, 수정에 2주를 보내고 금요일 저녁에 모든 Next.js 앱이 공격 가능하다고 발표한 셈임. 훌륭함. 다행히 내가 책임지는 사이트들은 영향받지 않는데, 이미 미들웨어와 Next.js의 “마법” 기능 대부분을 싫어했기 때문임
    • 특히 최근 들어 회사의 우선순위가 드러나는 듯함. 이건 Vercel에서 늘 문제였음. Vercel 쪽 물건은 멀리하길 강하게 권함
    • 실제 악용 증거가 없고 취약점이 공개적으로 알려졌다고 볼 이유도 없다면, 2주는 받아들일 만한 처리 시간으로 보임
      대기업들을 들여다보면 꽤 심각한 취약점도 수정까지 몇 달씩 방치되는 사례를 금방 찾을 수 있음
      다만 “분류 시작”이 실제로는 수정 작업을 시작했다는 뜻이라고 가정한 것임. 보고자에게 2주 동안 답도 안 했다면 꽤 나쁨

  • Next를 보면 프론트엔드 개발에서 뭔가 크게 잘못됐다는 생각이 듦. 대부분 앱에는 가치가 아주 작은 것들을 위해 복잡도를 너무 많이 추가함
    React는 프론트엔드에 복잡도를 많이 더했지만, 프론트엔드 상태가 많은 앱에는 큰 가치를 줬음
    Next는 파일 기반 라우팅을 가져왔는데 처음엔 멋져 보이다가도 조금만 복잡한 사용 사례로 들어가면 힘들어짐. 조심해서 망치지만 않는다면 서버 사이드 렌더링도 주는데, 전자상거래 제품을 만들 때나 괜찮고 그 외 몇몇 분야에서나 쓸 만한 정도 같음

    • “React가 프론트엔드에 복잡도를 많이 추가했다”는 말을 계속 듣지만 전혀 동의하지 않음. Angular.js, Backbone, Ember.js를 기억 못 하나? 내가 좋아했던 Knockout조차 복잡한 부분이 많았음
      서버 사이드 렌더링은 수년간 널리 오용됐고 이제 그 영향이 보이기 시작함. 그래도 서버 사이드 렌더링에는 훌륭한 사용 사례가 분명히 있음
      프론트엔드 개발은 지금이 역대 가장 쉬움. Vite Create를 실행하면 몇 분 안에 Render.com에 배포 가능한 React 단일 페이지 앱이 생김. 더 이상 Webpack, Bower, Broccoli, Gulp, Grunt 같은 혼란을 만질 필요가 없음. 프론트엔드 개발은 몇 년 만에 가장 좋은 상태임
    • Next.js의 나쁜 기술 결정 대부분은 비즈니스 모델에서 비롯됨. 특히 엣지 함수를 홍보하기 위한 미들웨어 시스템이 그렇음
      Next의 원래 전제에 더 가깝고 단순한 걸 찾는다면 Remix.js가 훌륭하고 훨씬 가벼움

  • 세상에:
    익스플로잇은 악성 헤더가 들어간 HTTP 요청을 만드는 것임
    GET /protected-route HTTP/1.1
    Host: vulnerable-app.com
    x-middleware-subrequest: true
    그러면 그냥 "x-middleware-subrequest: true" 헤더를 추가하는 것만으로 인증을 우회한다는 말임? 제대로 이해한 건가?

    • 맞음. 이 우회가 그만큼 심각해서 심각도 9.1임. 헤더 하나만 추가하면 될 정도로 사소하니 9.8이어야 한다고 봄
    • “인증을 우회한다”는 표현은 좀 이상하지만, 모두가 그렇게 설명하는 듯함. 실제로는 미들웨어를 우회하는 것이고, 그건 나쁘며 Vercel 입장에서는 창피한 일임. 하지만 미들웨어가 접근 제어를 책임져서는 안 됨. 미들웨어는 세션이 없으면 로그인 페이지로 리다이렉트하는 정도 이상을 해서는 안 됨
    • 지금 이 순간에도 취약한 웹사이트가 수만 개는 있을 것 같음

  • Next.js는 재귀 요청이 무한 루프를 일으키지 않도록 내부 헤더 x-middleware-subrequest를 사용함. 보안 보고서에 따르면 미들웨어 실행을 건너뛸 수 있었고, 이로 인해 요청이 라우트에 도달하기 전에 인가 쿠키 검증 같은 중요한 검사를 건너뛸 수 있었음

    • 웹 개발자가 아니라 이해가 좀 어려움
      내부에서 생성된 호출에 쓰려고 인증을 우회할 수 있는 특수 플래그를 뒀다는 뜻인가?
      그리고 누군가 첫 요청에 그걸 그냥 보내면 인증을 통째로 건너뛸 수 있다는 걸 알아낸 건가?

  • 분류에 13일이 걸린 건 심하네. Next.js 같은 걸 쓰지 않을 이유가 더 필요하진 않았지만, 목록에 이것도 추가하겠음

  • 우리가 만드는 웹 앱 아키텍처로 자체 호스팅 Next.js를 선택한 건 많은 과장 홍보를 믿었기 때문임
    HN에서 관련 댓글을 읽을수록 이 결정이 점점 불편하게 느껴짐

    • HN은 JS 프레임워크에 관해서는 꽤 이상한 사고방식을 가짐
      Next.js는 웹 앱의 99%에는 충분히 괜찮고, 웹 앱/플랫폼이 커질수록 더 잘 맞음. 일반적으로 들인 비용 대비 가장 많은 효용을 주는 프레임워크일 가능성이 큼
    • Next.js에 대해서는 마음이 둘로 갈림. 한편으로는 기본 제공되는 좋아할 만한 것들이 아주 많고, 특히 T3 같은 것과 묶으면 더 그럼. 다른 한편으로는 너무 거대한 골리앗이라 어떻게든 돌아간다는 사실이 놀라울 정도임
      기본 웹 앱에서는 보통 성능을 생각할 필요가 없을 정도인데, Next.js에서는 생각해야 할 만큼 느림. 어떤 도구든 절충이 있음
      다행히 Next.js의 장점 하나는 정말 맞지 않는다고 판단했을 때 다른 스택 전환보다 비교적 덜 아프게 빠져나올 수 있다는 점임. 프론트엔드는 그냥 React라 계속 동작함. 조금만 눈을 가늘게 뜨고 보면 백엔드도 그냥 JavaScript라 일반 Node 쪽으로 가져갈 수 있음
    • 과장 홍보는 절대 사지 말아야 함. 지루하고 검증된 걸 사야 함
    • 과장이 뭔지 알아보려고 일주일쯤 Next.js로 코딩해 봤고, 결국 Django/htmx로 갔음. 1년 뒤인 지금도 전혀 후회 없음
    • 버전 12 전후로 자체 호스팅과 Vercel 플랫폼을 겪으며 지옥을 본 뒤 떠났음
      다른 걸 찾는 걸 추천함. 우리 경우 그 코드를 현재의 React Router 7로 옮겼고, 결국 보유한 React 코드는 어떤 방식으로든 Vue로 교체할 예정임. 시간이 지나며 React 전반에서 거의 벗어났음

  • Next.js는 브라우저와 백엔드에서 모두 실행되는 코드를 작성할 수 있다는 근본적으로 결함 있는 전제 위에 있음
    브라우저에서 도는 코드와 신뢰된 백엔드에서 도는 코드의 보안 태세는 매우 다름
    관심사의 분리를 두면 프론트엔드 하나, 백엔드 하나로 두 코드베이스를 가질 수 있음. 프론트엔드는 신뢰할 수 없지만 접근 권한이 제한되고, 백엔드는 신뢰할 수 있지만 접근 권한이 많음

    • 이 취약점은 동형 코드와는 관련이 없지 않나? Next 미들웨어는 서버에서만 실행됨. “엣지”에서 돈다고 해도 브라우저 비슷한 환경일 뿐 여전히 서버임
    • 이 취약점은 그 전제와는 별 관련이 없음. 미들웨어는 항상 서버에서 실행됨
    • 동형 방식으로 코드를 실행하면 발목을 잡는 함정이 늘어나는 건 맞지만, 프레임워크를 그걸 염두에 두고 설계하면 어느 정도 완화할 수 있음. 예를 들어 Rust 쪽에서는 민감한 데이터 구조체에 Serialize 트레이트를 구현하지 않으면, 개발자가 일부러 절차를 밟지 않는 한 서버 영역 밖으로 나갈 수 없음
    • 원칙적으로는 이 말이 맞지 않다고 봄. 신뢰된 타입 같은 것과 TypeScript 타입 검사기를 이용하면 분리가 안전한지 정적으로 검증하기 꽤 쉬워야 함. Next.js에서는 불가능하지만, 그렇다고 전제가 틀린 건 아님
답변달기