You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Globally scriptable — render-native-app-info-plist.sh sets NSAppleScriptEnabled = true and ships APW.sdef exposing request login / request fill commands (APWAppleScriptCommands.swift), plus AppIntents/Shortcuts (APWAutomationIntents.swift).
Unsandboxed — native-app/APW.entitlements declares only com.apple.developer.associated-domains. There is no com.apple.security.app-sandbox entitlement and no keychain-access-groups scoping. (The build does codesign with --options runtime, so hardened runtime is present, but the App Sandbox is not.)
This means any local process can drive tell application "APW" to request login "https://<associated-domain>" (or invoke the Shortcut), and the broker process itself runs with the full ambient authority of the user.
Why it matters
Credential return is user-mediated — the production path routes through the AuthenticationServices OS picker, and the APW_DEMO path shows an approval prompt — so this is not a silent-exfiltration bug today. But for a password broker the combination of (a) an unauthenticated, globally-scriptable request surface (see also the broker-socket peer-auth gap) and (b) no sandbox to contain the process is a notably broad attack surface. It also means a UI-redress / prompt-fatigue attack (repeatedly scripting requests until the user approves) is reachable by any local app.
Recommendation
Evaluate enabling the App Sandbox for APW.app with narrowly scoped entitlements (associated-domains + keychain access group only), or document explicitly why it cannot be sandboxed.
Consider gating the AppleScript/Shortcuts surface behind peer authentication (tie into the broker peer-cred check) and/or rate-limiting/coalescing repeated approval prompts to resist prompt-fatigue.
Summary
APW.appis built as a credential broker that is:render-native-app-info-plist.shsetsNSAppleScriptEnabled = trueand shipsAPW.sdefexposingrequest login/request fillcommands (APWAppleScriptCommands.swift), plus AppIntents/Shortcuts (APWAutomationIntents.swift).native-app/APW.entitlementsdeclares onlycom.apple.developer.associated-domains. There is nocom.apple.security.app-sandboxentitlement and nokeychain-access-groupsscoping. (The build does codesign with--options runtime, so hardened runtime is present, but the App Sandbox is not.)This means any local process can drive
tell application "APW" to request login "https://<associated-domain>"(or invoke the Shortcut), and the broker process itself runs with the full ambient authority of the user.Why it matters
Credential return is user-mediated — the production path routes through the AuthenticationServices OS picker, and the
APW_DEMOpath shows an approval prompt — so this is not a silent-exfiltration bug today. But for a password broker the combination of (a) an unauthenticated, globally-scriptable request surface (see also the broker-socket peer-auth gap) and (b) no sandbox to contain the process is a notably broad attack surface. It also means a UI-redress / prompt-fatigue attack (repeatedly scripting requests until the user approves) is reachable by any local app.Recommendation
APW.appwith narrowly scoped entitlements (associated-domains + keychain access group only), or document explicitly why it cannot be sandboxed.docs/THREAT_MODEL.mdas a current surface (it expands the boundary documented for Roadmap: AppleScript / Shortcuts automation surface #50/Security: document associated-domain scope in threat model #4).References
scripts/render-native-app-info-plist.sh(NSAppleScriptEnabled,OSAScriptingDefinition)native-app/APW.entitlementsnative-app/Resources/APW.sdef,APWAppleScriptCommands.swift,APWAutomationIntents.swiftSeverity: Low/Medium
Filed by an automated deep security review.