Why it matters

Users and app stores rely on the app's declarations. A privacy manifest or store disclosure that does not match what the app and its SDKs actually do is a compliance problem and a breach of user trust.

How to meet it

  • Keep store disclosures and the iOS privacy manifest in step with what the app and every SDK actually collect.
  • Explain unexpected collection, such as background location, at the point of use.

MASTG tests in the local projects

Neither local project runs a MASTG test for MASVS-PRIVACY-3. 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

Also covers this · Guide

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.

Practice

Gaps on this site

The iOS guide covers the privacy manifest. No guide here covers Google Play's data safety declarations.

References

  1. MASVS-PRIVACY-3 (OWASP MASVS v2.1.0)
  2. MASVS-PRIVACY: Privacy (OWASP MASVS v2.1.0)

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.