Tauri가 보안 우선인 이유

"네 프론트엔드는 언젠가 뚫린다고 치고 시작해. 뚫렸을 때 피해가 경계 안에 갇히게 설계하는 거야."

웹뷰가 못 믿을 반쪽이야

네 프론트엔드는 웹뷰에서 돌고, 웹뷰는 웹 콘텐츠를 그려 — 공격자가 제일 먼저 노리는 자리지. XSS 버그, innerHTML에 흘러드는 악성 문자열, 뚫린 npm 의존성 — 전부 네가 안 짠 JavaScript가 네 앱 안에서 실행되는 걸로 끝날 수 있어. 프론트엔드가 네이티브를 통째로 만질 수 있는(또는 개발자가 접근 제한을 걸어두는 걸 깜빡한) 프레임워크에선, 그 주입된 스크립트가 기계 전체의 열쇠를 물려받아. 아무 파일이나 읽고, 아무 명령이나 실행하고. Tauri가 막으려고 만들어진 악몽이 이거야.

기본이 거부면 피해가 갇혀

Tauri 2는 0에서 시작해. 웹뷰는 네가 열어준 특정 command만, 그것도 capability가 permission을 줬을 때만 부를 수 있어. 그러니까 공격자가 네 프론트엔드에서 아무 JS나 돌린다 해도, 네가 파일시스템이나 셸 접근을 — 기능에 필요한 딱 그만큼 좁혀서 — 대놓고 허락하지 않았으면 ~/.ssh도 못 읽고 셸도 못 띄워. 뚫려도 네가 일부러 연 권한 안에 갇히지, OS 전체로 번지지 않아.

최소 권한이 게임의 전부야

네가 주는 permission 하나하나가 네가 받아들인 공격면이야. 규율은 최소 권한 하나뿐이야. 기능이 돌아갈 제일 좁은 권한만 주고, 제일 작은 경로나 도메인으로 좁히고, 창마다 다른 capability를 줘(설정 창엔 파일시스템 접근이 거의 필요 없잖아). Tauri 보안은 한 번 쌓고 마는 벽이 아냐 — '아니오'라는 기본값 위에 하나씩 작정하고 올리는 '예'의 연속이야.

Code

관문이 왜 중요한가·text

위협 모델 한 그림:

  악성 입력 / XSS / 나쁜 npm 의존성
            │  네 웹뷰에 JS 주입
            ▼
  ┌───────────────────────┐
  │   뚫린 프론트엔드       │  ← 임의 JavaScript 실행 가능
  └───────────┬───────────┘
              │ 부여한 것만 호출 가능
              ▼
  ┌───────────────────────┐
  │   Rust 코어 (게이트됨)  │  ← 부여 없음 = 접근 없음. 폭발 반경 갇힘.
  └───────────────────────┘

기본 거부가 '전체 침해'를 '네가 연, 좁게 scope한 정확히 그
permission만의 침해'로 바꿔.

Exercise

앱의 위협 모델을 머릿속으로 훑어봐. 프론트엔드가 지금 닿을 수 있는 네이티브 권한을 전부 적어(command랑 허락해준 permission). 하나씩 물어봐. '공격자가 내 JS를 돌린다면 이걸로 뭘 할 수 있지?' 그다음 더 좁히거나 조일 수 있는 걸 하나 찾아. 메커니즘을 배우기 전에 최소 권한으로 생각하는 걸 연습하는 거야.

Hint

capability 파일(다음 레슨들)이랑 command 목록에서 출발해. 위험한 건 넓게 열린 파일시스템이랑 셸이랑 http야. 'XSS가 이걸 악용할 수 있나?'가 모든 조이기를 켜는 질문이야.