[SecureStore][iOS][docs] Standalone app build defaults to shared keychain access with other apps published under the same team ID; conflicts documentation.
See original GitHub issueSummary
The expo-secure-storage
documentation states:
“Each Expo project has a separate storage system and has no access to the storage of other Expo projects.”
Problem: Using all default Expo binary build and library settings, apps built under the same Apple developer Team ID have wildcard access to each other’s keychain values, which conflicts with the documentation. This can lead to unexpected consequences if a developer doesn’t realize this.
Example:
- Two app binaries on the same device, App 1 and App 2, built under the same Apple developer team ID.
- App 1 can access all of App 2’s keychain keys set by
expo-secure-storage
, and vice versa. - If the same key name is accessed/set by both apps, conflicts occur.
- If App 1 has keys set of
api_key
andusername
, while App 2 has keys set ofapi_key
andsecretcode
, App 1 can accesssecretcode
. App 2 can accessusername
. Both App 1 and App 2 can accessapi_key
and will override other’s value, when set.
Request: The build implementation should be updated to reflect the scenario described in the documentation. By default, apps should not have access to another app’s keychain items (through a wildcard keychain-access-group), even within the same team ID. Ideally, a build option should be added that opts-into shared groups.
Related Info:
- Expo SDK 41, managed workflow, iOS, expo-secure-store 10.1.0
- Sharing Access to Keychain Items Among a Collection of Apps
- Entitlements Troubleshooting
Managed or bare workflow? If you have ios/
or android/
directories in your project, the answer is bare!
managed
What platform(s) does this occur on?
iOS
SDK Version (managed workflow only)
41
Environment
Expo CLI 4.4.7 environment info:
System:
OS: macOS 11.3.1
Shell: 5.8 - /bin/zsh
Binaries:
Node: 15.13.0 - /usr/local/bin/node
Yarn: 1.22.10 - /usr/local/bin/yarn
npm: 7.13.0 - /usr/local/bin/npm
SDKs:
iOS SDK:
Platforms: iOS 14.5, DriverKit 20.4, macOS 11.3, tvOS 14.5, watchOS 7.4
IDEs:
Android Studio: 4.1 AI-201.8743.12.41.7199119
Xcode: 12.5/12E262 - /usr/bin/xcodebuild
npmPackages:
expo: ^41.0.0 => 41.0.1
react: 16.13.1 => 16.13.1
react-native: https://github.com/expo/react-native/archive/sdk-41.0.0.tar.gz => 0.63.2
npmGlobalPackages:
expo-cli: 4.4.7
Expo Workflow: managed
Reproducible demo or steps to reproduce from a blank project
Steps to verify default wildcard access:
- Build an iOS binary with default settings.
- Check the app entitlements of the .ipa, with
codesign -d --ent :- /path/to/the.app
- Note
keychain-access-groups
. The wildcard indicates shared access to any keychain values with that prefix, meaning all keys from all apps published under a single team ID.
<key>keychain-access-groups</key>
<array>
<string>[TEAM_ID].*</string>
<string>com.apple.token</string>
</array>
Issue Analytics
- State:
- Created 2 years ago
- Reactions:4
- Comments:10 (5 by maintainers)
Top GitHub Comments
Hello, I have the same issue. I tried to add
["com.apple.token" ,"[TEAM_ID].com.my_package.my_package"]
inios.entitlements.keychain-access-groups
and I can’t see any effect. When I inspect my ipa package it’s stillDid I miss something ?
Thanks.
Thanks for the reply and clarification there! I think it’d definitely be a worthwhile addition to consider updating the documentation to further clarify and potentially call out the apparent iOS default to share keychain access among apps published under the same team.
Going off what the current docs seemed to imply, we had been operating under the assumption that the app’s
expo-secure-storage
set keys were sandboxed from our other apps, by default. We had both apps setting a unique value using the same, generic key name. Only once we saw one app literally grabbing and using the value set by the other app is where where we got a little concerned and investigated further ultimately to find out they were being shared.