Tauri Capabilities and CSP

1. The problem: looking locked down is not the same as least privilege

A desktop app can have a very strict CSP while a webview still receives native permissions far beyond its use case through capability membership. The opposite can also happen: native permissions are narrow while CSP permits unnecessarily broad scripts or network origins. This lesson keeps those two axes independent so neither can hide weakness in the other.

2. The owned LOC-003 boundary

LOC-003 owns only the exposure contract among windows/webviews, capabilities, permissions/scopes, and CSP. Command implementation and domain authorization belong to LOC-002; tray and degraded runtime UX belong to LOC-004. The artifact here is a Tauri Capability/CSP Least-Privilege Matrix v1, not a complete application authorization system.

3. What a Tauri capability controls

In Tauri v2, capabilities determine which permissions are granted or denied for particular windows or webviews. The useful question is therefore not simply “does the app have this permission?” but “through exactly which capabilities and scopes does this window/webview receive this access?”

4. Multiple memberships require effective exposure to be merged

A window or webview can be referenced by more than one capability. Tauri documentation warns that such memberships effectively merge the involved security boundaries and permissions. Reviewing each capability file in isolation is therefore insufficient; calculate the effective capability set for the actual webview.

5. Record permission and scope separately from the capability ID

A friendly capability name is not evidence. The matrix must show effective permissions, allow_scope, and deny_scope. If a webview only needs to read a bounded status record, a wildcard filesystem scope is still overexposure even when the capability is named default or safe.

6. A capability is not a human role

Do not use a Tauri capability as a substitute for human identity or application role. Capability membership describes a technical frontend-to-native exposure boundary; it does not prove who is using the window or whether domain authorization for an operation has passed.

7. CSP is a different axis: what may the webview load or contact?

Tauri documents CSP as a restriction on HTML/webview resource loading. Directives such as script-src, connect-src, and img-src constrain allowed sources. This layer should be kept as restrictive as practical and should open only the origins and resources actually required by the owned use case.

8. Remote content should be treated as an explicit exception

Official Tauri guidance warns that remote or untrusted content can introduce attack vectors. Broad CDN allowances, generic https: script sources, or wildcard network connections should not flow from debugging convenience into release without a bounded justification. Every external origin should map to a concrete use case.

9. CSP and native permissions do not cancel each other out

A strict CSP does not make a broad native permission safe. A narrow capability does not make a permissive CSP harmless. Keep two independent review columns: Native Exposure and Web Content/Origin Exposure. Release passes only when both are least-privilege for the window/webview.

10. Calculate merge risk explicitly

If a diagnostics webview matches both diagnostics-read and admin-control, its effective exposure is the union of both memberships even if each capability looks reasonable by itself. merge_risk should record whether overlap silently introduces a sensitive permission outside the owned use case.

11. A release blocker needs a typed reason

A useful gate does not emit only BLOCK. It records a reason such as CAPABILITY_OVERLAP, NATIVE_SCOPE_TOO_BROAD, CSP_ORIGIN_TOO_BROAD, UNKNOWN_CAPABILITY, or PLATFORM_MISMATCH. Typed reasons let repair target the failing axis rather than weakening another control.

12. Failure example: strict CSP plus native wildcard still fails

Assume default-src 'self' and connect-src 'self' are narrow, but the same webview holds a wildcard write scope. The configuration must not pass. Web exposure is bounded, but native exposure remains broader than the owned need.

13. Second failure example: narrow native access plus broad CSP still fails

Now native access is a single read-only status command, but script-src https: and connect-src * remain. Native exposure is acceptable while the web axis is excessive. The result is still BLOCK, but the reason must differ so repair happens on the right boundary.

14. Lab: Tauri Capability/CSP Least-Privilege Matrix v1

Eight synthetic fixtures are provided. For each, derive effective_capability_set, effective_permissions, native_exposure, csp_exposure, merge_risk, release_blocker, decision, and reason. Expected mappings are not included in the learner package. The lab launches no real Tauri process, performs no network request, uses no credential, and changes no OS permission.

15. Transfer: a diagnostics webview without admin inheritance

Add a diagnostics webview that needs exactly one read-only native command and one API origin. Keep it in a distinct capability, remove overlap with restart/credential/admin permissions, and constrain connect-src to the one required origin. Reusing a broader capability or widening CSP for convenience fails the transfer even if the previous baseline passed.