chrome.debugger, 허용 사이트에서도 연결이 막히는 이유

사이트 하나를 허용해도 debugger 연결은 열리지 않는다

Host access is restricted by policy.라는 오류가 난다면, 대상 사이트가 허용 목록에 있는지만 확인해서는 해결되지 않는다. Chrome의 debugger 명세에 따르면 기업의 ExtensionSettings가 해당 확장에 비어 있지 않은 runtime_blocked_hosts를 적용할 때 attach()는 모든 대상에서 거부된다. 사이트가 runtime_allowed_hosts에 있어도 같다.

여기서 막히는 것은 특정 페이지에서의 스크립트 실행이 아니라 디버거 연결 자체다. Chromium의 보안 설명은 debugger 권한이 Chrome DevTools Protocol(CDP)에 접근하며, 일부 기능은 일반적인 호스트 권한 제한을 벗어날 수 있다고 설명한다. 사이트별 허용·차단을 그대로 적용하기 어려운 권한인 셈이다.

Google은 Chrome 155부터 연결 시점에 기업 정책을 검사하는 방식을 적용했다. 정식 배포 시작일은 10월 6일이다. 이번 변경의 대상은 관련 제한이 설정된 관리형 브라우저다. 개인 브라우저나 해당 제한이 없는 기업 환경까지 모두 막힌 것은 아니다.

캡처하지 않는 확장도 캡처 정책 오류를 받을 수 있다

정책 오류는 메시지에 따라 확인할 항목이 달라진다. 두 경우 모두 실제 작업 명령을 보내기 전의 연결 단계에서 발생한다.

debugger가 제공하는 권한 범위 때문에 화면 캡처 제한도 연결 검사에 포함된다. 따라서 확장 개발자가 “우리 기능은 스크린샷을 찍지 않는다”고 생각하더라도, debugger를 사용하는 구조라면 이 오류를 처리해야 한다.

attach가 실패했다면 후속 명령을 보내지 않는다

Manifest V3의 Promise 방식에서는 attach()의 거부를 잡아 사용자에게 원인을 전달할 수 있다. 다음은 연결 성공 여부를 반환하는 예시다. reportError는 확장 화면에 오류를 보여 주는 함수로 구현해야 한다.

async function attachForTask(tabId, reportError) {
  try {
    await chrome.debugger.attach({ tabId }, "1.3");
    return true;
  } catch (error) {
    reportError(String(error.message ?? error));
    return false;
  }
}

호출하는 쪽은 반환값이 true일 때만 다음 CDP 명령을 보내도록 해야 한다. 콜백 방식이라면 콜백 안의 chrome.runtime.lastError를 확인한다. 오류를 놓친 채 재시도만 반복하면 사용자는 작업이 실패한 이유를 알 수 없다.

정책과 무관한 연결 오류도 있으므로 모든 실패를 같은 안내로 바꾸면 안 된다. 받은 오류 문구를 보존하고, 두 정책 메시지에 해당할 때 관리 설정을 확인하도록 안내하는 편이 적절하다.

필요한 일이 페이지 조작이라면 더 좁은 API를 검토한다

직접 CDP 접근이 꼭 필요하지 않다면 기능에 맞는 확장 API로 옮길 수 있다. chrome.scripting은 자바스크립트와 CSS를 페이지에 넣는다. 사용하려면 scripting 권한에 더해 대상 호스트 권한이나 사용자의 동작으로 얻는 activeTab 권한이 필요하다.

요청을 규칙에 따라 차단·변경하는 작업에는 chrome.declarativeNetRequest가 후보가 된다. 선언한 규칙을 적용하는 API이므로 CDP의 모든 네트워크 기능을 그대로 대체한다고 볼 수는 없다.

관리자에게는 브라우저 버전, 확장 ID, 실제 오류 메시지를 함께 전달해야 확인 범위를 좁힐 수 있다. 관리자는 확장별 기업 설정과 필요한 접근 범위를 검토하고, 개발자는 제한을 유지하면서 구현 가능한 기능을 구분해야 한다. 허용 사이트를 계속 추가하는 것만으로 이 debugger 제한이 풀리지는 않는다.