Next.js 보안 패치는 단순히 버전 숫자만 올린다고 끝나지 않습니다
makedream14 de mayo de 2026
0
컴퓨터/소프트웨어
Comments (0)
Log in to leave a comment
No posts yet
makedreammakedreamLog in to leave a comment
No posts yet
보안 전문 인력이 없는 팀에서 Next.js 취약점 소식을 들으면 막막합니다. 당장 서비스를 멈출 수도 없고, 그렇다고 패치를 미루자니 찜찜하죠. 단순히 npm update를 친다고 모든 문제가 해결되지는 않습니다. 내 코드 어딘가에 숨은 구멍을 직접 찾아내고 막아야 합니다. 배포 후 서비스가 터지지 않으면서도 보안을 챙기는 실무적인 대응 방법을 정리했습니다.
내가 설치한 라이브러리가 사용하는 '자식 패키지'에 취약점이 생기면 답답해집니다. 상위 라이브러리가 업데이트될 때까지 기다리는 건 너무 위험합니다. 이럴 때는 의존성 트리 중간에 개입해서 버전을 강제로 꽂아넣어야 합니다.
먼저 터미널에서 npm list <취약패키지명>을 실행하세요. 어떤 경로로 그 패키지가 들어왔는지 눈으로 확인해야 합니다. 원인을 찾았다면 package.json에 overrides(npm)나 resolutions(yarn) 필드를 추가합니다. 여기에 보안이 해결된 버전을 명시하면 패키지 매니저가 하위 의존성까지 훑어서 해당 버전으로 교체합니다. package-lock.json을 열어 실제로 버전이 바뀌었는지 확인하는 과정까지 마쳐야 안심할 수 있습니다.
Next.js 서버 액션이나 API 라우트에서 외부 데이터를 가져올 때 SSRF 공격에 노출되기 쉽습니다. 공격자가 URL 파라미터에 169.254.169.254 같은 클라우드 메타데이터 주소를 넣으면, 서버는 순진하게 내부 자격 증명을 읽어다 넘겨줍니다. 인프라 설정을 바꾸는 건 번거로우니 코드 레벨에서 입구를 좁혀야 합니다.
표준 fetch를 그대로 쓰지 말고 IP 대역을 검사하는 로직을 입히세요. dns.lookup으로 호스트네임을 IP로 바꾼 뒤, 이 주소가 사설망 대역(10.0.0.0/8, 192.168.0.0/16 등)에 속하는지 체크합니다. 사내망 주소라면 요청을 즉시 차단하는 커스텀 함수를 만들어 모든 서버 사이드 호출에 적용하세요. 인프라 팀에 의존하지 않고도 데이터 유출 사고를 막는 가장 확실한 방법입니다.
CVE-2025-29927 취약점은 미들웨어의 경로 처리 로직을 흔들어 인증을 통과해버리는 수법을 씁니다. 특히 다국어 설정을 쓸 때 URL에 이상한 특수문자를 섞으면 매칭 로직이 꼬이기도 합니다.
middleware.ts에서 들어오는 모든 경로는 정규화를 거쳐야 합니다. 중복 슬래시를 지우고 허용된 언어 코드(ko, en 등) 리스트와 대조하는 화이트리스트 방식을 도입하세요. 리스트에 없는 요청은 바로 400 에러를 뱉게 만듭니다. 또한 외부에서 유입되는 x-middleware-subrequest 같은 내부용 헤더는 프록시 서버 단계에서 삭제하도록 설정하세요. 비즈니스 로직은 건드리지 않으면서 권한 우회 공격을 쳐낼 수 있습니다.
React 19에서 사용하는 데이터 전송 방식은 복잡합니다. CVE-2026-23869처럼 순환 참조가 담긴 데이터를 보내 서버 CPU를 100%로 치솟게 만드는 공격이 가능합니다. 코드를 고치기 전에 먼저 서버 입구에서 물리적인 제한을 걸어야 합니다.
Nginx 같은 리버스 프록시에서 client_max_body_size를 128k 정도로 확 줄이세요. 일반적인 API 요청에 이 정도면 충분합니다. 특히 Content-Type: text/x-component 헤더가 붙은 요청은 더 엄격하게 속도를 제한해야 합니다. 서버가 이상한 데이터를 읽느라 시간을 끄는 걸 막으려면 타임아웃을 30초 이내로 짧게 가져가는 게 좋습니다.
보안 패치를 배포했는데 정작 결제 페이지가 안 열리면 곤란합니다. 패치 후에는 실제 공격자가 할 법한 행동을 테스트 코드로 돌려야 합니다. Playwright를 쓰면 편합니다.
인증 없이 관리자 페이지에 접근하거나, API 파라미터에 localhost 주소를 넣어보는 시나리오를 짜세요. 이때 시스템이 200 OK가 아니라 403이나 400 응답을 내놓는지 확인하는 어서션을 추가합니다. 이 테스트를 CI/CD 파이프라인에 넣으면, 다음 업데이트 때 실수로 보안 로직을 지워버리는 불상사를 막을 수 있습니다. 완벽한 보안은 없지만, 내가 짠 코드의 입구를 하나씩 닫아가는 습관은 전문 보안팀보다 강력한 방어선이 됩니다.