OWASP Mobile M6 Inadequate Privacy Controls Guide

Most mobile apps collect more personal data than they need and then leak it through logs, URLs, backups, clipboards and third-party SDKs that nobody on the team fully understands. OWASP lists this as M6 Inadequate Privacy Controls in the Mobile Top 10 2024, and rates its business impact as severe even though the technical impact is usually low. This guide explains what M6 covers, how it maps to the four MASVS-PRIVACY controls and MASVS-STORAGE-2, and how to implement and evidence the fixes on Android and iOS using platform features such as data extraction rules, privacy manifests and App Tracking Transparency. It is written for mobile developers, application security engineers and privacy engineers who need to turn a privacy policy into controls an assessor can test. For the full list see the OWASP Mobile Top 10 Guide.

Key takeaways

Almost every app is in scope. OWASP notes that nearly all apps process personally identifiable information (PII), even if only IP addresses, usage logs and crash or analytics metadata, so M6 is a question of how much, not whether.
Minimisation is the strongest control. Data you never collect cannot leak; OWASP puts minimising PII first in its prevention list, and GDPR Article 25(2) requires that by default only the data needed for each purpose is processed.
The leaks are mostly side channels. OWASP's example scenarios are logs and error messages, URL query parameters, and backups: places developers do not think of as data stores.
SDKs are your responsibility. Google Play and Apple both hold the app developer responsible for data collected by bundled SDKs, and MASVS-PRIVACY-1 requires that SDKs respect consent rather than collecting before it is given.
Declarations must match behaviour. Play's Data safety form and Apple's privacy manifest and App Store privacy details are public claims; testing whether the binary's traffic matches them is a core M6 assessment step.

What it is and who it applies to

OWASP describes M6 as the failure to protect PII that an app collects, stores or transmits, such as names, addresses, payment details, email and IP addresses, and special category data about health, religion, sexuality or political opinions. The risk page frames harm across all three security properties: PII can be leaked (confidentiality), manipulated (integrity) or destroyed and blocked (availability). Attackers use it for impersonation, fraud and blackmail.

The OWASP risk ratings explain why this entry is easy to underestimate:

Factor	OWASP rating	What it means in practice
Exploitability	Average	Well-protected stores (the sandbox, TLS traffic, backups) usually need another weakness first, such as malware or a network interception. Weak stores such as URL query strings and the clipboard are easier.
Prevalence	Common	Nearly every app handles PII and many over-collect, which makes them more attractive targets.
Detectability	Easy	Static and dynamic analysis finds PII in logs, URLs and clipboard writes quickly.
Technical impact	Low	Usually limited to the affected users, unless the data includes authentication material.
Business impact	Severe	Regulatory action under laws such as GDPR, CCPA and LGPD, lawsuits, reputational harm and reuse of the data for social engineering.

Who it applies to: any organisation publishing a mobile app to consumers or staff. Consumer apps carry the heaviest exposure because of store disclosure rules and privacy law; enterprise apps still process staff PII and device identifiers. Privacy obligations come from law (the UK and EU GDPR, US state laws), from store policy, and from contracts; M6 is the engineering layer that makes those obligations true in the shipped binary. See the GDPR Compliance Guide for Security Teams.

Where M6 overlaps: OWASP itself notes that privacy exposure usually comes through other entries: insecure storage and communication (M9, M5), weak authentication and authorisation (M3, M1), and insider or sandbox attacks (M2, M4, M8). Treat M6 as the data-centric lens across those weaknesses, and fix the underlying weakness in its own entry.

Structure and key requirements

The Top 10 is an awareness list. The testable requirements live in MASVS, which added a dedicated MASVS-PRIVACY control group. MASVS is explicit that this group is a baseline for the app itself and does not replace a Data Protection Impact Assessment or legal review; it also scopes out what happens to data on remote servers, treating any data that leaves the app (to a server or to another app) as data leaving the user's control.

Control	Statement (MASVS)	What an assessor looks for	Platform features that help
MASVS-PRIVACY-1	The app minimizes access to sensitive data and resources.	Only necessary permissions and data; informed consent; SDKs that do not collect before consent; no unnecessary data passed down the SDK chain.	Runtime permissions, scoped storage and the photo picker on Android; purpose strings and limited photo access on iOS.
MASVS-PRIVACY-2	The app prevents identification of the user.	Pseudonymisation and anonymisation; fingerprint-like signals (device IDs, IP addresses, behaviour) kept to their purpose, for example fraud signals not reused for analytics.	Apple's ATT framework and IDFV; resettable advertising IDs rather than hardware identifiers.
MASVS-PRIVACY-3	The app is transparent about data collection and usage.	Clear disclosure of collection, storage and sharing, including unexpected behaviour such as background collection; store declarations that match behaviour.	Google Play Data safety section; Apple privacy manifest (PrivacyInfo.xcprivacy) and App Store privacy details.
MASVS-PRIVACY-4	The app offers user control over their data.	Ways to view, modify and delete data and change privacy settings, including revoking consent; re-prompting when more data is needed than first disclosed.	In-app settings and deletion flows; a deletion route declared in Play Data safety.
MASVS-STORAGE-2	The app prevents leakage of sensitive data.	No PII in logs, backups, clipboard, screenshots or other unintended locations reachable through platform APIs.	Android data extraction rules and no-backup directories; iOS file protection and backup exclusion.

The leak paths OWASP highlights

Logs and error messages: sensitive values, including query details, end up in device logs, crash reports sent to third-party platforms, or error dialogs. Sanitise messages before they are logged, displayed or reported.
URL query parameters: values in query strings are recorded by server logs, analytics and browser history. Send sensitive data in headers or the request body instead.
Backups and reinstallation: decide explicitly what goes into device backups. On Android, OWASP also points to the android:hasFragileUserData manifest flag, which lets users keep app data on uninstall; set it deliberately, because retained data may be readable by a later app installed with the same package name.
Clipboard and third-party transfer: the OWASP page lists clipboard content as a weakly protected source, and MASVS treats sending data to another app as equivalent to sending it to a server.

Android backup controls in detail

Android Auto Backup is on by default (android:allowBackup defaults to true) and includes shared preferences, getFilesDir(), databases and getExternalFilesDir(). Apps targeting Android 12 (API 31) and higher define rules with android:dataExtractionRules, which separates <cloud-backup> from <device-transfer>; a section that is missing leaves that transfer mode fully enabled. They should still supply android:fullBackupContent for devices on Android 11 and lower. The disableIfNoEncryptionCapabilities="true" attribute on <cloud-backup> skips cloud backup on devices that cannot encrypt it, for example without a lock screen. Files in getNoBackupFilesDir() and the cache directories are always excluded, which makes them the natural place for tokens and re-creatable PII. Android's documentation also notes that on some manufacturers' devices allowBackup="false" disables cloud backup but not device-to-device transfer, so explicit exclude rules are safer than relying on that flag alone.

Identity and NHI requirements

Privacy and identity meet in three places in a mobile app, and each one is a common M6 finding.

Identifiers are personal data: device identifiers, advertising IDs, IP addresses and account IDs link activity to a person. Under Apple's rules, from iOS 14.5 an app must request permission through ATTrackingManager.requestTrackingAuthorization (with an NSUserTrackingUsageDescription purpose string) before tracking or reading the IDFA, and without permission the IDFA is all zeros. Apple also prohibits deriving data to uniquely identify a device (fingerprinting) and using hashed emails or phone numbers to track users who declined. Keep a register of every identifier the app sends and why.
Tokens and credentials in privacy side channels: OWASP notes that M6 impact rises when leaked data includes authentication material. Access tokens in URLs, session IDs in crash reports and OTPs on the clipboard turn a privacy leak into account takeover. Strip them at the logging layer, not call by call. See the OWASP Mobile Top 10 M1 Improper Credential Usage Guide.
SDK keys and the data they unlock: analytics, crash-reporting and advertising SDKs authenticate to their backends with keys embedded in the app, and those backends hold the PII the app sends. Treat each SDK as a third-party machine identity: inventory it, know which data types it receives, scope its key, and confirm it is listed in your store declarations. The API Key Management Guide covers scoping and rotation.
Fraud signals versus analytics: MASVS-PRIVACY-2 asks for technical barriers so a device fingerprint collected for fraud detection is not reused for audience measurement. Apple likewise treats data shared with a broker solely for fraud prevention or security as not tracking. Keep fraud and analytics pipelines, keys and retention separate.

Implementation steps

The order below starts with knowing your data, because every later control depends on it, and keeps enforcement changes behind feature flags so they can be rolled back.

Build a data inventory per build. List every data type the app reads (permissions, sensors, contacts, location, files), every identifier it creates, and every destination (your API, each SDK, other apps). Capture SDK versions from the dependency manifest. This becomes the source for store declarations and the DPIA. See the DPIA Guide.
Threat model the privacy paths. OWASP recommends threat modelling to find the most likely failure paths. For each data type, ask where it could leak: logs, URLs, backups, clipboard, screenshots, notifications, crash reports, WebView storage.
Cut collection. Remove permissions and fields that do not serve a stated purpose; replace precise location with coarse where possible; truncate, hash or aggregate on device; set retention periods and delete on schedule. Map each remaining item to a purpose (NIST SP 800-53 PT-3) and to the minimum elements needed (SI-12(1)).
Gate optional processing on consent. Initialise analytics and advertising SDKs only after consent, not at application start. Verify with a network capture that nothing is sent before the consent decision, which is the specific behaviour MASVS-PRIVACY-1 calls out.
Close the side channels. Add a central log redaction filter and strip verbose logging from release builds; move sensitive parameters from query strings to request bodies; configure dataExtractionRules and fullBackupContent with explicit excludes; keep secrets in getNoBackupFilesDir() or the platform key store; avoid placing PII on the clipboard and use the platform's sensitive-content flags where available.
Protect what remains. Require authentication and authorisation for PII access, encrypt sensitive local data with hardware-backed keys (OWASP mentions keys stored in hardware), and keep TLS everywhere. See the OWASP Mobile Top 10 M9 Insecure Data Storage Guide.
Publish accurate declarations. Complete the Play Data safety form (required for every published app, even one that collects nothing) and the Apple privacy manifest and App Store privacy details from the inventory, including SDK collection. Apple requires a PrivacyInfo.xcprivacy file with NSPrivacyTracking, NSPrivacyTrackingDomains, NSPrivacyCollectedDataTypes and NSPrivacyAccessedAPITypes, and network requests to declared tracking domains fail if the user has not granted ATT permission.
Give users control. Add in-app settings to revoke consent, export and delete data, and a deletion route that works without reinstalling. Re-prompt when a new version needs more data.
Roll out safely. Ship consent and SDK-initialisation changes behind remote flags to a pilot cohort, compare traffic captures and analytics volumes, then widen. Rollback is turning the flag off, never re-enabling pre-consent collection.

Evidence and assessment

MASVS notes that some privacy tests can be automated while others need manual review, such as spotting data the app collects but did not declare. Combine both.

Check	Method	Evidence to keep
PII in logs	Run test journeys while capturing device logs; static search for logging calls on sensitive fields	Log capture with no PII; redaction filter code review
Pre-consent collection	Intercept traffic from first launch through the consent screen with consent declined	Traffic capture showing no SDK calls before consent
Declarations match behaviour	Compare observed destinations and data types with Play Data safety and the Xcode privacy report	Signed-off comparison per release
Backup exposure	Review manifest and rules files; inspect a backup of a test account	Rules file, backup content listing
Identifiers	Inventory identifiers sent; check ATT handling and IDFA absence when declined	Identifier register with purpose and retention
User control	Execute consent withdrawal and deletion; confirm server-side effect	Test record and deletion ticket

Metrics that show it is working

Data types per release: count of PII data types collected, trending down or flat with a documented purpose for each.
Undeclared destinations: hosts observed in testing that are not in the inventory or store declarations; target zero.
Pre-consent calls: network requests to analytics or advertising hosts before consent; target zero.
Log redaction findings: PII-in-log findings from static analysis per release.
Deletion turnaround: median time from user deletion request to completed deletion across app and backend.
SDK review coverage: share of bundled SDKs with a reviewed data map and current version.

Mapping to other frameworks

The mapping below is our own, based on the control texts. OWASP's M6 page cross-references the OWASP Top 10 Privacy Risks and the User Privacy Protection Cheat Sheet.

Framework	Reference	Relevance to M6
OWASP MASVS	MASVS-PRIVACY-1 to 4, MASVS-STORAGE-2	Testable app requirements
GDPR	Article 25 (data protection by design and by default)	Minimisation by default across amount, extent, storage period and accessibility
NIST SP 800-53 Rev 5	PT-2, PT-3, PT-4, PT-5, PT-7	Authority to process, purposes, consent, privacy notice, special categories
NIST SP 800-53 Rev 5	SI-12(1), SA-8(33), SC-28	Limit PII elements, minimisation as a design principle, protection at rest
NIST CSF 2.0	GV.OC-03, PR.DS-01, PR.DS-02	Legal and privacy obligations understood; data at rest and in transit protected
ISO/IEC 27001:2022 Annex A	A.5.34, A.8.11, A.8.12	Privacy and PII protection, data masking, data leakage prevention
Google Play / Apple	Data safety section; privacy manifest, ATT, App Store privacy details	Store-enforced disclosure and tracking consent

Common pitfalls

SDKs initialised at launch: analytics and crash SDKs start in Application.onCreate or the app delegate before the consent screen, so data flows regardless of the user's choice. Defer initialisation and test with consent declined.
Debug logging left in release: verbose network logging prints request bodies, tokens and responses to the device log and into crash reports. Strip it at build time and redact centrally.
Relying on allowBackup="false" alone: it may not stop device-to-device transfer on some devices, and a missing <device-transfer> section leaves that mode fully enabled. Write explicit rules.
Declarations written once: the store forms are filled in at launch and never updated as SDKs are added. Google states that developers alone are responsible for complete and accurate declarations; regenerate them from the inventory every release.
One identifier for everything: a single device fingerprint feeds fraud, analytics and advertising, which breaks MASVS-PRIVACY-2 and, on iOS, risks breaching Apple's tracking rules.
Collecting for later: fields gathered "in case they are useful" have no purpose, no retention rule and no protection plan. See the Data Retention and Secure Deletion Guide.

Practitioner checklist

Maintain a per-release inventory of data types, identifiers, permissions, SDKs and destinations.
Remove any permission or field without a documented purpose and retention period.
Initialise optional SDKs only after consent and prove it with a traffic capture.
Apply a central log redaction filter and strip verbose logging from release builds.
Keep PII and tokens out of URL query strings, the clipboard and notifications.
Configure dataExtractionRules and fullBackupContent with explicit excludes, and store secrets in no-backup locations.
Generate the Play Data safety answers and Apple privacy manifest from the inventory each release.
Provide in-app consent withdrawal and data deletion, and test the backend effect.
Separate fraud signals from analytics identifiers in code, keys and retention.

OWASP Mobile Top 10 M6 Inadequate Privacy Controls Guide: Minimising and Protecting User Data