Tauri v2: no built-in integrity check for app data restored from user backups

Question

I'm designing the restore flow for a Tauri v2 desktop app. Users can export their data (SQLite file plus some JSON state from the store plugin) to a backup folder, and later point the app at that folder to restore. The open question is how the app should decide whether the restored data is trustworthy and uncorrupted before replacing the current state.

The framework's existing verification mechanisms don't seem to cover this case. The updater plugin verifies update artifacts against an embedded Ed25519 public key, but as I understand it that protection applies only to update packages, not to arbitrary files the app reads at runtime. The fs plugin's scope system restricts which paths the frontend may read, but says nothing about whether the contents are valid. Persisted data surviving an update is a matter of OS path conventions, and schema validation is left to the app.

So the unresolved decision is what the canonical pattern is for verifying restored data in Tauri v2: checksums, signing the backup with an app-held key, or schema validation alone, and whether any of this belongs in Rust commands rather than the frontend, given that fs scopes do not constrain the backend.

Is there a documented or community-accepted approach for integrity verification of restored backups in Tauri v2? Should verification live in a Rust command to avoid trusting frontend-read bytes? And is there any updater-style signing primitive exposed for reuse on arbitrary data files?

Zoha · Answer

Short answerNo. Tauri v2 does not ship a backup/restore integrity subsystem, and there is no single documented or community-accepted canonical pattern that replaces one. The updater's signature verification applies to update artifacts, not arbitrary files your app restores. Persistence plugins such as fs, store, and sql handle storage and access, not authenticity. You must implement verification in your app.What is confirmed vs likelyConfirmed by design boundaries: Tauri core handles windowing, IPC, permissions, and signed updater artifacts. It does not automatically authenticate or validate restored backups. The fs plugin's scope system restricts which paths the frontend may read; it says nothing about whether file contents are valid.Likely explanation: "no built-in integrity check" means the app owns the restore trust decision. That usually means a manifest with format version and digests, plus optional keyed authentication if tampering is in scope.Version note: plugin names, permissions, and APIs can change across Tauri v2 minor releases and plugin versions. Confirm against the exact versions in your project.Should verification live in a Rust command?Yes, for any threat model where the frontend or restored bytes are not fully trusted. fs scopes constrain the frontend plugin; they do not constrain Rust backend file access. If the frontend reads bytes and computes a hash, a compromised webview can lie about both. A Rust command should resolve and canonicalize the backup path, enforce its own allowlist, read the files, verify the manifest, and only then import. Do not accept a frontend-supplied "verified: true" or digest as proof.Choose verification by threat modelAccidental corruption only: a SHA-256 digest manifest is usually enough. It detects truncation, bit rot, and partial copies. It does not stop deliberate modification.Tampering possible: use HMAC-SHA-256 or a signature such as Ed25519 over a canonical manifest. The key must not be stored in the backup. Use an OS keychain, Stronghold, or a server-side key. Otherwise an attacker can rewrite the data and the MAC.Schema validation alone: not integrity. It catches malformed JSON or missing columns, not valid-but-wrong values.Practical restore flowWrite a manifest at backup time: format version, app data schema version, file list, sizes, digests, and optional signature or MAC.On restore, have a Rust command canonicalize the backup root and reject paths outside it.Verify the manifest signature or MAC first, then per-file digests.For SQLite, run PRAGMA integrity_check; after digest verification. It checks structural consistency, not authenticity.Validate schema and version, run migrations in a transaction or import into a staging database, then atomically replace current state. Keep a rollback copy.Reject or quarantine mismatches; do not partially overwrite current data.Updater-style signing primitive?The updater plugin's Ed25519 verification is tied to update packages. I am not aware of a documented public API that exposes it as a general "verify arbitrary file" primitive. For backup signing, use a Rust crypto crate directly, such as an Ed25519 or HMAC implementation, and manage keys yourself. Confirm against your exact Tauri and plugin versions.One diagnostic detail that changes the recommendationCan an attacker modify the backup folder, or is the only realistic risk accidental corruption? If accidental only, checksums plus schema validation are proportionate. If tampering is in scope, you need a keyed MAC or signature with a key outside the backup, and verification must happen in Rust.Verification checklistInspect Cargo.toml, package.json, cargo tree, and npm ls for Tauri v2 and plugin versions.Run a controlled test: back up, flip one byte, restore, and confirm the app rejects it.Search app code for hash, HMAC, signature, schema-version, or migration checks executed on restore.Review Tauri v2 documentation for updater, fs, store, sql, and stronghold responsibilities.

Tauri v2: no built-in integrity check for app data restored from user backups

1 answer

0 question comments

Short answer

What is confirmed vs likely

Should verification live in a Rust command?

Choose verification by threat model

Practical restore flow

Updater-style signing primitive?

One diagnostic detail that changes the recommendation

Verification checklist

Your perspective belongs here.