0–5 min: map trust boundaries
List content origins, windows/webviews, bridges, native commands, files, credentials, ports, updater and signer.
Success checkEvery privileged hop has an owner and a documented boundary.
Desktop runtime security checklist · Updated 2026-07-05
Desktop Runtime Security Checklist: Tauri, Electron, Pake, Webviews, IPC, Permissions, Updates, Signing, and Local Services
A practical review checklist for teams shipping desktop software with Tauri, Electron, Pake-style wrappers, local webviews, privileged IPC, auto-update channels, code signing, and container-backed local services.
Desktop applications built with web technology cross several trust boundaries at once: remote or local web content, a renderer or webview, privileged native commands, filesystem access, deep links, update channels, signing identities, and sometimes local container services. A secure design must review the complete chain rather than treating the desktop shell as a packaging detail.
This checklist connects RepoDaily coverage of Tauri, Electron, Pake, Apple container, Podman, Colima, and Docker Desktop. The goal is not to declare one runtime universally safer. It is to make teams prove that navigation, IPC, permissions, local services, update delivery, signing, secrets, storage, and rollback have explicit boundaries and evidence.
RepoDaily verdict
Choose the runtime that lets your team define and verify the narrowest practical privilege boundary. For Tauri, review capabilities, permissions, command scopes, CSP, plugins, updater, and signing. For Electron, review remote-content rules, context isolation, sandboxing, preload bridges, IPC validation, navigation, new-window handling, dependencies, updates, and signing. For wrappers and local-service apps, also prove what URL is loaded, which origins can reach local services, what mounts and sockets are exposed, and how the app is reset after compromise.
Quick matrix
| Surface | Baseline rule | Failure signal | Evidence to keep |
|---|---|---|---|
| Loaded content | Prefer packaged or tightly allowlisted content | Arbitrary remote origin can reach privileged APIs | Origin inventory and navigation policy |
| Renderer/webview | Assume rendered content can become hostile | Privileged APIs are globally exposed | Isolation and sandbox configuration |
| IPC/native bridge | Expose narrow typed operations, not generic execution | Renderer can invoke shell, filesystem, or arbitrary command paths | Bridge/API inventory and handler validation tests |
| Permissions | Grant per window, feature, command, path, and origin where supported | Default-wide capability grants | Capability files, permission diff, owner approval |
| Filesystem | Scope reads and writes to required user-selected or app-owned paths | Home directory or workspace-wide access | Path scopes and denial tests |
| Network/local services | Bind narrowly and authenticate sensitive local APIs | 0.0.0.0 service, permissive CORS, exposed daemon socket | Bind address, ports, auth, origin policy |
| Updates | Use authenticated update metadata and a rollback plan | Unsigned artifacts or mutable download URLs | Release manifest, signature verification, rollback record |
| Code signing | Protect signing identities and verify release provenance | Shared unmanaged certificate or CI secret sprawl | Signer owner, CI boundary, verification output |
| Secrets and storage | Keep credentials out of renderer state and logs | Tokens in localStorage, debug logs, crash reports, or bundled config | Storage map, redaction test, rotation owner |
| Containers and sockets | Treat runtime sockets and host mounts as host-level privilege | App can reach Docker/Podman socket or broad host mounts | Mount/socket inventory and least-privilege review |
Desktop runtime readiness scorecard
Score the application before beta distribution or enabling sensitive local integrations.
| Control | 0 points | 1 point | 2 points | Owner question |
|---|---|---|---|---|
| Content boundary | Any origin can load | Partial allowlist | Packaged content or strict origin/navigation policy | Which content can ever reach the app shell? |
| Privilege bridge | Generic bridge | Some wrappers | Narrow typed commands with validation | What is the smallest privileged API? |
| Isolation | Renderer shares privilege | Some isolation | Isolation/sandbox model verified with negative tests | What happens after renderer XSS? |
| Filesystem scope | Broad home access | Feature-level path rules | User-selected/app-owned paths only | Can a compromised view read unrelated files? |
| Update chain | Manual mutable downloads | Signed builds only | Signed updates, staged rollout, rollback evidence | How is a bad update stopped and reversed? |
| Local services | Open unauthenticated ports | Loopback only | Loopback + auth/origin controls + port inventory | Can another local process or LAN host call it? |
| Release signing | Unmanaged identity | Documented manual process | Protected signer with auditable CI/release path | Who can produce a trusted release? |
| Recovery | Reinstall is the plan | Manual cleanup notes | Documented reset, credential rotation, rollback, and incident owner | How do users recover after compromise? |
30-minute desktop runtime security test
Use this as a fast pre-beta gate; a production review should go deeper.
5–10 min: attack the navigation boundary
Try redirects, external links, new windows and an unapproved origin. Verify they cannot inherit privileged APIs.
Success checkUnapproved content is blocked or opened outside the privileged shell.
10–15 min: fuzz bridge inputs
Send malformed paths, oversized data, unexpected URLs, traversal strings and unauthorized command names.
Success checkPrivileged handlers reject invalid inputs without side effects.
15–20 min: test local-service exposure
Inspect bind scope and attempt calls without auth and with an unapproved origin.
Success checkSensitive endpoints are not reachable from unauthorized local or LAN contexts.
20–25 min: verify release chain
Check signer ownership, artifact verification, update metadata, staged rollout and emergency halt path.
Success checkA forged artifact or metadata change cannot become a trusted update.
25–30 min: prove rollback and cleanup
Exercise downgrade/rollback policy, revoke a test credential, clear app data and stop local services/containers.
Success checkThe team can return the app and host to a known safe state.
Desktop runtime security review flow
- Classify the app: packaged local UI, remote-content wrapper, hybrid app, privileged desktop client, or desktop shell around local container services.
- Draw the trust-boundary map from loaded content through renderer/webview, preload or invoke layer, native commands, filesystem, keychain/credential store, network, updater, signing, and local services.
- Enumerate every privileged operation. Replace generic shell, filesystem, URL-open, and command execution bridges with narrow task-specific operations and validate all arguments in the privileged process.
- Review the runtime-specific controls: Tauri capabilities, permissions, command scopes, CSP and plugin permissions; or Electron context isolation, sandbox, preload exposure, IPC validation, navigation and new-window handling.
- Review distribution: dependency provenance, build reproducibility, code signing, update metadata, artifact hosting, staged rollout, emergency halt, and rollback.
- For local containers or daemons, list bind addresses, ports, auth, CORS/origin policy, mounts, runtime sockets, credentials, caches, logs, and cleanup paths.
- Run negative tests that simulate compromised renderer content, malformed IPC input, blocked navigation, denied filesystem paths, forged update metadata, and unauthorized local-service calls.
Scenario table
| Scenario | Required controls | Stop condition |
|---|---|---|
| Packaged offline desktop utility | Packaged assets, narrow native bridge, scoped filesystem picker, signed release | Generic shell or home-directory access is exposed |
| Remote website wrapper | Strict URL allowlist, navigation/new-window policy, no privileged bridge to remote content | Authentication page or arbitrary link can inherit native privilege |
| Tauri productivity app | Capabilities per window, scoped permissions, CSP, plugin review, updater/signing review | Broad default capability grants cannot be justified |
| Electron desktop client | Context isolation, sandbox where practical, narrow contextBridge API, validated IPC sender/input, navigation controls | Renderer can directly reach Node or generic IPC execution |
| Pake-style internal wrapper | Owned target origin, redirect audit, dedicated profile/storage, minimal native features | Wrapper is pointed at third-party or changeable content without isolation review |
| Desktop app with local API | Loopback bind, authentication token or equivalent control, strict origin policy, lifecycle cleanup | Service is LAN-accessible or accepts unauthenticated privileged requests |
| Desktop shell controlling containers | No unnecessary daemon socket, explicit mounts, non-privileged containers, network policy, disposable state | Container socket or broad host filesystem is exposed to compromised UI |
| Auto-updating commercial app | Signed artifacts, authenticated metadata, staged rollout, release owner, rollback | Team cannot halt or reverse a bad release quickly |
Desktop runtime risk checklist
Remote content with local privilege
A wrapper becomes dangerous when remote content, redirects, injected scripts, or compromised dependencies can reach a privileged native bridge.
Overpowered IPC
Generic command execution, shell access, unrestricted filesystem methods, and unvalidated IPC arguments turn renderer compromise into host compromise.
Permission drift
Capabilities and plugin permissions tend to widen over time. Review permission diffs like API-surface changes, not incidental config edits.
Update-channel compromise
A secure runtime can still distribute malicious code when update metadata, artifact hosting, signing identities, or release automation are weak.
Local service exposure
Loopback services, permissive CORS, predictable tokens, LAN binds, and unauthenticated WebSockets can create a browser-to-localhost attack path.
Container socket escalation
Docker or Podman sockets and broad host mounts can erase the isolation expected from a container-backed desktop architecture.
Persistent sensitive state
Webview storage, cookies, caches, logs, crash reports, screenshots, and update artifacts can retain secrets and private data.
Unsigned recovery path
Emergency manual downloads or downgrade instructions can bypass the secure release path exactly when users are most vulnerable.
Security implementation patterns
Narrow native command API
Expose operations such as selectProjectFolder or exportReport rather than generic readFile, exec, or shell methods.
Per-window privilege
Keep settings, login, content preview, and privileged administration windows on different capability profiles where the runtime supports it.
Hostile-renderer assumption
Design the native side so a compromised renderer still cannot cross path scopes, call arbitrary commands, or forge trusted update state.
Release provenance record
Keep artifact hashes, signing evidence, source revision, build job identity, update manifest, rollout cohort, and rollback target for each release.
Loopback service contract
Document bind address, port allocation, authentication, allowed origins, request limits, logs, lifecycle, and cleanup for every local service.
Socket-free container control
Prefer a narrow broker or task API over exposing a general container daemon socket to desktop UI code.
Security regression fixtures
Automate denied-navigation, denied-path, malformed-IPC, forged-update, and unauthorized-local-service tests so controls do not silently regress.
FAQ
Short answers for teams reviewing desktop web runtimes.
Is Tauri automatically safer than Electron?
No. Tauri and Electron have different architectures and controls, but either can be insecure when teams expose broad native APIs, load untrusted content, misconfigure permissions, or weaken the update and signing chain.
What is the most important desktop security rule?
Assume rendered web content can become hostile and keep the privileged bridge narrow, validated, and least-privileged.
Can a website wrapper safely load any URL?
Not when the page can reach native privilege. Use a strict allowlist, control navigation and new windows, and keep remote content away from privileged bridges.
Why are containers included in a desktop runtime checklist?
Desktop tools increasingly start local databases, browsers, models, workers, and APIs in containers. Host mounts, daemon sockets, ports, credentials, and persistent volumes become part of the desktop threat model.
Is loopback binding enough for a local API?
Not always. Other local processes and browser-origin attacks may still reach localhost services, so sensitive APIs also need appropriate authentication, origin controls, narrow methods, and lifecycle cleanup.
What should be reviewed on every release?
Runtime and dependency updates, permission/capability changes, IPC surface changes, new origins, local ports, signing provenance, update metadata, rollout controls, and rollback readiness.
Related radar
Related RepoDaily briefs
Tauri Explained: Rust-Backed Webview Apps for Smaller, More Controlled Desktop and Mobile Softwaretauri-apps/tauri · Infrastructure / RuntimeElectron Explained: Chromium + Node.js Desktop Apps, Ecosystem Depth, and Security Tradeoffselectron/electron · Infrastructure / RuntimePake: Turn Any Webpage Into a Lightweight Desktop App With One Commandtw93/Pake · Developer tool / CLIApple's `container` Brings Native, Swift-Built Linux Containers to Apple Silicon Macsapple/container · Infrastructure / RuntimePodman Explained: Daemonless, Rootless Containers for Linux-Native Workflowscontainers/podman · Infrastructure / RuntimeColima Explained: Lightweight Container Runtimes on macOS and Linuxabiosoft/colima · Infrastructure / RuntimeDocker Desktop Explained: The Polished Container Runtime Baseline for Developer Teamsdocker/for-win · Infrastructure / Runtime
Sources
Feedback
Did this page help you make a decision?
Anonymous feedback helps RepoDaily improve what is actually useful.