Every permission and data type the app collects is something that can leak, be misused or need disclosure. SDKs inherit the app's permissions, so data minimization has to cover them too.
- Request permissions only when a feature needs them, and prefer narrower options such as approximate location or a photo picker.
- Inventory what each third-party SDK collects, and start SDKs only after consent.
- Declare data use accurately, for example in the iOS privacy manifest.
MASTG tests in the local projects
Neither local project runs a MASTG test for MASVS-PRIVACY-1. The guides below explain the platform mechanisms, and the control’s page on mas.owasp.org links the MASTG tests and weaknesses OWASP maps to it.
Guides on this site
Harden an iOS app's storage, network and entry points
Store secrets in the Keychain with the narrowest accessibility class, set file protection explicitly, keep App Transport Security on, prefer universal links, constrain WKWebView bridges, keep step-up keys in the Secure Enclave, verify App Attest on the server and ship an accurate privacy manifest, mapped to OWASP MASVS 2.1.
GDPR privacy by design for engineers: Articles 25, 32 and 35 in code
Turn GDPR data protection by design and by default, security of processing and DPIA triggers into engineering work: a personal-data inventory checked in CI, defaults that collect and share less, a DPIA screen at design time, and access and erasure requests that reach every store.
Practice
- Keep an iOS app's storage, links and web bridge in bounds · Local project
References
List data from the publisher. A guide is listed as the main subject when the weakness or risk is what the guide is about, and as covering it when a dedicated section or worked example addresses it.
Control statements are quoted from OWASP MASVS v2.1.0, licensed CC BY-SA 4.0; the rest is this site's summary. MASTG tests are those the iOS and Android projects here run, with their titles from mas.owasp.org. License.