Electron 데스크톱 앱 보안: 브라우저처럼 보인다고 브라우저처럼 믿으면 안 되는 이유

Electron 데스크톱 앱을 검토할 때 나는 먼저 UI가 아니라 권한이 어느 프로세스에 있고, 웹 화면이 어떤 이름의 API를 통해 그 권한에 닿는지를 본다. Electron은 Chromium의 멀티프로세스 구조를 가져온다. 하지만 일반 웹페이지와 달리 main 프로세스는 Node.js API를 쓸 수 있고, 잘못 연결한 renderer는 파일·셸·운영체제 권한의 입구가 된다. 7월 18일 Hacker News 새 글에 올라온 「Electron apps: web browsers in a trenchcoat」은 이 긴장을 사용자 경험과 업데이트 비용의 언어로 다시 드러냈다. 결론은 Electron을 피하자는 말이 아니다. 웹 UI를 재사용하는 선택과 데스크톱 권한을 주는 선택을 한 번에 묶지 말고, renderer는 요청만 하고 main은 최소 권한의 명령만 수행하게 설계하자는 것이다. 달빛 아래에서 보면 이 경계는 프레임워크 옵션이 아니라 제품의 공격 표면이다.

웹 UI와 데스크톱 권한은 서로 다른 문제다

Electron 공식 보안 문서는 이를 꽤 직설적으로 설명한다. Electron은 브라우저가 아니며 JavaScript가 파일 시스템과 사용자 셸 등에 접근할 수 있다. 또한 임의의 신뢰하지 않는 콘텐츠를 보여 주는 것은 심각한 위험이며, 온라인 소스의 코드를 실행한다면 악성 여부를 개발자가 보장해야 한다고 명시한다.

이 차이를 놓치기 쉬운 이유는 renderer가 HTML·CSS·JavaScript라는 익숙한 모습이기 때문이다. 화면이 로컬 index.html을 렌더링하더라도, 다음 중 하나가 추가되는 순간 신뢰 경계가 넓어진다.

• 원격 도움말·로그인·공지·마크다운 미리보기처럼 외부 콘텐츠를 로드한다.
• XSS나 취약한 의존성으로 renderer의 스크립트 실행권이 탈취된다.
• preload가 ipcRenderer 또는 Node API 전체를 window에 노출한다.
• main 프로세스가 renderer가 전달한 경로·명령·URL을 검증 없이 실행한다.

Electron의 프로세스 모델에서 앱에는 하나의 main 프로세스가 있고, 각 BrowserWindow는 별도 renderer 프로세스로 웹페이지를 연다. 이 구조는 단순한 성능 분리가 아니다. 앱 권한을 가진 운영자(main)와 신뢰도가 낮은 화면(renderer)를 분리할 수 있는 설계 재료다. renderer가 손상될 수 있다는 가정을 먼저 놓아야 IPC의 형태가 바뀐다.

context isolation은 켜는 것으로 끝나지 않는다

Electron은 context isolation을 Electron 12부터 기본 활성화했고 모든 앱에 권장한다. 이 옵션이 켜지면 preload 스크립트와 로드된 웹사이트는 서로 다른 window 객체를 쓴다. 웹페이지가 preload에 접근 가능한 강한 API를 덮어쓰거나 직접 읽는 일을 막는 출발점이다.

그러나 isolation 자체가 API 설계를 대신하지는 않는다. 예를 들어 renderer에 ipcRenderer.send를 통째로 넘기면, 분리된 문맥 안에서도 화면은 임의 채널과 임의 인자를 main에 보낼 수 있다. 안전한 bridge는 “무엇을 할 수 있는가”보다 “어떤 의도로, 어떤 값만 보낼 수 있는가”를 좁게 표현한다. Electron 공식 문서도 preload의 격리 문맥에서 contextBridge로 API를 안전하게 노출하는 방식을 권한다.

아래는 파일 선택이라는 한 가지 작업만 renderer에 주는 최소 형태다. 실제 제품에서는 반환한 경로의 보관·전송도 개인정보 정책과 데이터 흐름에 맞춰 추가로 제한해야 한다.

const { contextBridge, ipcRenderer } = require('electron')

contextBridge.exposeInMainWorld('desktop', {
  chooseExportFolder: () => ipcRenderer.invoke('export:choose-folder')
})

// main.js
import { BrowserWindow, dialog, ipcMain } from 'electron'

ipcMain.handle('export:choose-folder', async () => {
  const { canceled, filePaths } = await dialog.showOpenDialog({
    properties: ['openDirectory', 'createDirectory']
  })
  return canceled ? null : filePaths[0]
})

new BrowserWindow({
  webPreferences: {
    contextIsolation: true,
    nodeIntegration: false,
    sandbox: true,
    preload: new URL('./preload.js', import.meta.url).pathname
  }
})

중요한 점은 renderer가 dialog, 파일 시스템, 일반적인 IPC 전송 객체를 받지 않는다는 것이다. 대신 이름과 인자가 고정된 chooseExportFolder()만 받는다. main의 handler도 renderer가 준 경로로 셸 명령을 실행하지 않고, 운영체제의 폴더 선택 UI 결과만 반환한다. 권한 경계는 “차단” 버튼 하나보다 이런 작은 API 모양에서 오래 유지된다.

IPC는 내부 통신이 아니라 공개 API로 취급하라

개발 중에는 IPC가 같은 앱 안의 내부 통신처럼 느껴진다. 하지만 renderer가 교체되거나 XSS로 제어될 가능성을 고려하면 IPC 채널은 사실상 앱이 공개한 로컬 API다. 그러므로 HTTP API에 적용하던 규칙을 그대로 가져오는 편이 안전하다.

1. 채널을 allowlist로 고정한다. ipcMain.on(channel, ...)에서 동적 채널명이나 범용 execute·run·readFile 인터페이스를 만들지 않는다.
2. main에서 입력을 재검증한다. preload의 타입 검사는 편의일 뿐이다. 파일 확장자, 작업공간 루트, URL scheme, 최대 길이를 main handler에서 다시 검사한다.
3. 권한을 동사 단위로 나눈다. filesystem 대신 exportReport, pickProjectDirectory처럼 업무 목적이 드러나는 채널을 만든다.
4. 실패를 관측한다. 거절된 IPC 요청에는 channel, 검증 사유, renderer 출처를 개인정보를 빼고 남긴다. 조용한 fallback은 취약점과 운영 오류를 함께 숨긴다.

SSG의 글은 Electron 앱이 내장 Chromium 업데이트를 Electron과 앱 공급자가 함께 배포할 때만 받는다는 점, 그리고 sandbox는 개발자가 선택적으로 끌 수 있어 사용자가 화면만 보고 보안 상태를 알기 어렵다는 점을 지적한다. 이 주장은 특정 앱의 메모리 사용량을 일반화하는 근거로 읽을 필요는 없다. 다만 데스크톱 앱의 품질은 UI와 별개로 런타임 업데이트 정책과 권한 설정의 검증 가능성에 달려 있다는 경고로는 유효하다.

출시 전에는 기능 테스트와 권한 테스트를 따로 돌려야 한다

보안 설정은 BrowserWindow 생성부 한 곳에 있어 보여도 회귀는 쉽게 생긴다. 새 창 하나를 만들며 webPreferences를 복사하지 않거나, 외부 OAuth 창과 내부 화면에 같은 preload를 붙이거나, 편의를 위해 nodeIntegration: true를 넣는 순간 경계가 달라진다. 그래서 일반 UI E2E 테스트와 별도로 다음 검사를 CI 또는 출시 체크리스트에 둔다.

• 모든 BrowserWindow와 WebContentsView에서 nodeIntegration이 꺼져 있는가.
• 신뢰하지 않는 URL을 열 수 있는 창에 privileged preload가 붙지 않는가.
• contextIsolation과 sandbox가 의도한 창에서 켜져 있는가.
• renderer가 노출된 bridge 밖의 IPC 채널을 호출해도 main이 거절하는가.
• Electron 버전, 잠긴 의존성, 릴리스 노트 검토가 배포 절차에 있는가.

여기서 가벼운 반론은 있다. 모든 IPC를 업무 단위로 쪼개면 개발이 느려지고 prototype의 속도가 떨어진다는 주장이다. 맞다. 하지만 범용 bridge가 빨리 만든 것은 기능이지 안전한 제품이 아니다. 특히 AI 도구처럼 파일을 읽고, 셸을 실행하고, 계정을 연결하는 데스크톱 앱은 renderer의 편의 API 하나가 곧 권한 위임 규칙이 된다. 초기에는 네다섯 개의 동사만 명시해도 충분하다. 그 목록을 늘릴 때마다 “이 API를 탈취한 웹 화면이 무엇을 할 수 있는가”를 검토하면 된다.

내 의견: Electron의 진짜 비용은 RAM이 아니라 설명되지 않은 권한이다

내 의견은 분명하다. Electron의 메모리 비용이나 웹과 비슷한 UI만으로 프레임워크를 판단하면 중요한 문제를 놓친다. 더 큰 비용은 renderer와 main 사이의 권한 위임이 코드 곳곳에 흩어져, 사용자는 물론 운영자도 무엇이 가능한지 설명하지 못하는 상태다. 반대로 context isolation, sandbox, 좁은 contextBridge, 검증된 IPC를 기본으로 두면 Electron은 웹 기술의 생산성을 유지하면서도 관리 가능한 데스크톱 권한 모델이 될 수 있다. 이 방식이 완벽한 격리를 보장하지는 않는다는 반론도 타당하다. 브라우저 엔진·의존성·업데이트 체인까지 함께 관리하지 않으면 안 된다. 그래서 경계 설계와 최신 Electron 유지 정책은 분리할 수 없는 한 쌍이다.

김덕환 운영자 관점

김덕환 운영자 관점에서는 새 데스크톱 기능을 추가할 때마다 “이 화면이 가진 권한”을 기능 명세의 한 줄로 남기는 습관이 중요하다. 파일 선택, 브라우저 자동화, 터미널 실행, 토큰 저장은 모두 renderer에 직접 주지 말고 검증 가능한 main 작업으로 바꿔야 한다. 그러면 AI 에이전트가 기능을 넓혀도 사람이 승인하고 감사할 수 있는 경계는 유지된다.

참고 자료

• Electron Security — 공식 문서
• Electron Process Model — 공식 문서
• Electron Context Isolation — 공식 문서
• Electron apps: web browsers in a trenchcoat — Sedat Kapanoglu, 2026-07-18
• Hacker News discussion: Electron apps: web browsers in a trenchcoat — 2026-07-18