크롬 140+ 버전 업데이트 이슈

 

내 로컬 개발 환경은 안녕하신가요?

요즘 웹 개발자들 사이에서 크롬 브라우저의 새로운 보안 정책 때문에 난리가 났어요. 특히 로컬 환경에서 개발하는 사람들은 갑자기 에러를 만나 당황했을 거예요. 크롬 140 버전 이후부터는 사설망 접근 방식이 완전히 바뀌고 있거든요 . 예전에는 개발자가 서버 설정을 조금만 바꾸면 됐는데, 이제는 사용자에게 직접 허가를 받아야 해요.

 

이 변화는 웹사이트 보안을 더 튼튼하게 만들려고 시작된 거예요. 공용 웹사이트가 사용자 몰래 집이나 회사 내부 네트워크(사설망) 자원에 접근하는 것을 막는 거죠 . 크롬은 이런 보안을 위해 오랫동안 '사설 네트워크 접근 제한(PNA)' 정책을 준비해왔어요 . 하지만 최근에는 '로컬 네트워크 접근(LNA)'이라는 새로운 방식이 등장했어요 . 이 새로운 방식이 우리가 알아야 할 핵심이랍니다.

 

 

 

예전에는 'PNA'라는 게 있었죠? PNA의 핵심은 무엇이었나요?

PNA는 'Private Network Access'의 줄임말이에요 . 이 정책은 외부 사이트가 사설망 자원에 요청하는 것을 통제했어요 . 예를 들어, 인터넷에 있는 웹사이트가 내 집의 http://192.168.0.10 같은 로컬 주소로 데이터를 요청하는 상황이죠 .

 

PNA는 요청을 보내기 전에 '프리플라이트(Preflight)'라는 사전 검증 요청을 먼저 보냈어요 . 브라우저는 서버에 "나 사설망 접근해도 돼?" 하고 물어보는 거예요 . 이때 서버가 "응, 허락할게"라는 의미로 Access-Control-Allow-Private-Network: true라는 특별한 헤더를 응답에 포함해야 했죠 . 만약 서버가 이 헤더를 주지 않으면, 크롬은 실제 요청을 아예 막아버리고 cors 에러를 띄웠어요 . 이 과정은 보안 컨텍스트, 즉 https 환경에서만 작동하도록 조치가 이미 도입되었어요 .

 

PNA 정책은 서버 설정에 의존하는 방식이었어요 . 그래서 서버 개발자들이 특정 헤더를 추가하는 설정만 하면 됐죠 . 하지만 이 방식은 여러 번 연기되거나 롤백되기도 했어요 . 결국, 크롬 개발팀은 서버 설정보다 더 강력한 사용자 권한 기반의 방식으로 방향을 틀게 되었답니다 .

 

 

크롬 142+부터 'LNA'가 등장했어요! LNA는 뭐가 달라졌나요?

크롬 142 버전부터는 PNA 대신 'Local Network Access(LNA)'라는 새로운 보안 모델이 도입됐어요 . LNA의 가장 큰 특징은 사용자 권한 승인이 필수라는 점이에요 . 스마트폰에서 앱이 로컬 네트워크 장치를 검색할 때 권한을 물어보는 것과 비슷해요 .

 

 

웹사이트가 사설망 자원에 접근하려고 하면, 크롬이 사용자에게 허용할지 물어보는 창을 띄워요 . 사용자가 '허용(Allow)'을 선택해야만 해당 사이트가 사설망 리소스에 접근할 수 있게 되는 거죠 . 만약 사용자가 이 요청을 무시하거나 '차단(Block)'을 누르면, 콘솔에 Permission was denied 에러가 표시되면서 요청이 취소됩니다 .

 

LNA는 보안을 훨씬 더 강화해줘요 . 사용자가 직접 허락해야만 접근이 가능하므로, 악성 사이트가 내 로컬 네트워크를 몰래 스캔하거나 정보를 훔쳐가는 csrf 공격 등을 막을 수 있어요 . 다만, LNA에서도 웹사이트 자체는 https와 같은 보안 컨텍스트여야 한다는 조건은 유지된답니다 .

 

 

Chrome의 LNA 정책이 보호하는 주요 사설 IP 대역

 

 

새로운 정책 때문에 발생하는 대표적인 에러 3가지는 무엇인가요?

크롬의 사설망 정책이 바뀌면서 로컬 개발 환경에서 자주 보이는 에러 메시지가 세 가지 있어요 . 이 에러들은 대부분 크롬이 보안 정책 때문에 요청을 막았다는 것을 알려줘요 .

 

1. 보안 컨텍스트 부족 에러:

... not a secure context and the resource is in more-private address local space . 이 에러는 주로 HTTP 페이지에서 http://localhost 같은 로컬 자원을 호출할 때 발생해요 . 크롬 94 버전 이후부터 비보안 웹사이트가 사설망에 접근하는 것을 막는 정책 때문이죠 .

 

2. PNA 프리플라이트 실패 에러:

No 'Access-Control-Allow-Private-Network' header was present... . 이 에러는 공용 웹사이트(https)가 사설망 API에 요청했지만, 서버가 PNA 요구 헤더인 Access-Control-Allow-Private-Network: true를 응답에 포함하지 않아서 생겨요 . 서버 측 설정 변경이 필요하다는 뜻이죠 .

 

3. 사용자 권한 거부 에러 (LNA):

Permission was denied for this request to access the unknown address space . 크롬 142 버전부터 등장한 에러예요 . 공용 사이트가 사설망 자원에 접근할 때 사용자에게 권한 프롬프트를 띄웠는데, 사용자가 '차단'을 선택하거나 무시해서 요청이 거부된 경우에 나타납니다 .

 

개발 환경에서 이 오류들을 어떻게 해결해야 할까요?

개발자가 로컬 서버와 통신해야 할 때 발생하는 이런 문제를 해결하기 위한 몇 가지 방법이 있어요 . 근본적인 해결책과 임시적인 우회책이 있으니 상황에 맞게 사용해 보세요.

 

가장 근본적인 해결책은 로컬 개발 서버에도 https를 적용하는 거예요 . 웹 애플리케이션과 API 서버 모두 https로 구동하면 브라우저가 이를 '보안 컨텍스트(Secure Context)'로 간주해요 . ASP.NET이나 Node.js 같은 환경에서는 개발자용 SSL 인증서를 만들거나 mkcert 같은 도구를 사용해서 쉽게 적용할 수 있답니다 . https를 적용하면 첫 번째 에러를 해결할 수 있어요 .

 

두 번째 에러(PNA 프리플라이트 실패)를 해결하려면 서버의 cors 응답 헤더에 Access-Control-Allow-Private-Network: true를 추가해야 해요 . iis 환경에서는 Web.config 파일에 설정을 추가할 수 있고 , 다른 환경에서는 미들웨어를 사용해서 OPTIONS 요청을 처리할 때 이 헤더를 포함하도록 설정해야 합니다 .

(ASP.NET Web API의 경우 Web.config의 <customHeaders> 설정에 해당 헤더를 추가하거나, .NET Core 환경에서는 CORS 미들웨어를 확장하여 처리할 수 있음)

 

 

세 번째 에러(LNA 권한 거부)는 사용자 승인이 핵심이에요 . 배포된 서비스라면 사용자에게 로컬 기기 접근 허용 방법을 안내해야 하고 , 개발/테스트 중이라면 크롬의 '사이트 설정'에 들어가서 특정 사이트의 로컬 네트워크 접근 권한을 미리 허용해 둘 수 있어요 .

 

 

혹시 개발할 때 임시로 설정을 우회할 수 있나요?

네, 개발 편의를 위해 임시로 크롬 설정을 조정하여 보안 제한을 완화할 수는 있어요 . 하지만 이건 어디까지나 임시방편이고, 상용 환경에서는 절대 사용하면 안 되는 방법이에요 .

 

과거 크롬 버전에서는 특정 플래그를 비활성화하여 PNA 차단을 일시적으로 해제할 수 있었어요 . 최신 버전에서는 명령줄 옵션이나 기업용 정책 설정을 통해 PrivateNetworkAccessChecks 기능을 비활성화하는 방법이 알려져 있어요 . 크롬 개발팀도 이런 우회책은 브라우저가 막으려는 보안 취약점을 다시 열어두는 것이라고 경고했어요 .

 

따라서 개발이 끝나고 실제 서비스에 배포할 때는, 웹 애플리케이션과 서버 설정을 근본적으로 개선하는 것이 바람직합니다 . 임시 우회책보다는 https 적용과 cors 헤더 추가에 집중해야 해요 .

 

 

앞으로 로컬 네트워크 보안 정책은 어떻게 더 발전할까요?

크롬의 사설망 접근 제한 정책은 여기서 멈추지 않고 계속 발전할 예정이에요 . Google은 앞으로 모든 로컬 네트워크향 교차 출처 요청을 보호 대상으로 확대할 계획이랍니다 .

 

현재는 Fetch/XHR 요청만 권한 통제 대상이지만, 미래에는 websocket, webrtc 같은 다른 통신 방식도 권한 관리에 편입될 거예요 . 예를 들어, chromium 145 버전에서는 이미 websocket의 로컬망 연결 시도에 대한 차단 및 권한 요구가 실험 중이랍니다 .

 

게다가, 지금은 같은 사설망 출처의 웹 앱이 다른 로컬 서버에 요청하는 것(사설망 → 사설망)은 권한 프롬프트가 뜨지 않지만 , 장기적으로는 이런 요청까지 제한될 수 있다고 해요 . microsoft edge나 Firefox 같은 다른 주요 브라우저들도 비슷한 로컬 네트워크 접근 권한 개념을 도입하고 있으니, 이 흐름은 웹 표준으로 자리 잡을 가능성이 커요 . 개발자들은 이제 "로컬 통신은 기본적으로 잠겨있다"라는 전제를 받아들이고, 사용자가 권한을 쉽게 허용하도록 유도하는 UX를 준비해야 할 거예요 .