M6: Inadequate Privacy Controls (2024)

Excessive data collection, missing consent mechanisms, and PII leakage. Apps expose personal data through logs, analytics, or insecure storage.

Risk Assessment

Am I Vulnerable?

• Insecure Data Storage and Communication: Personal data may be exposed through insecure storage mechanisms or unprotected communication channels (cf. M5, M9).
• Insecure Authentication and Authorization: Data access with insecure authentication and authorization can expose PII to unauthorized parties (cf. M3, M1).
• Insider Attacks on App Sandbox: Malicious insiders or compromised components can attack the app's sandbox to access personal data (cf. M2, M4, M8).
• Unnecessary PII Processing: The app collects and processes more PII than necessary, including names, addresses, payment data, locations, and other sensitive information that increases attack surface.
• PII Leakage Through Logs and Errors: Sensitive data may be inadvertently exposed through application logs, crash reports, error messages, or analytics metadata.
• PII Exposure via URLs and Clipboard: Personally identifiable information may leak through URL query parameters, clipboard content, or other unprotected channels.

How Do I Prevent It?

• Minimize PII Collection: Assess whether all PII processed is really necessary, e.g., name and address, gender, age. Something that does not exist cannot be attacked.
• Substitute Less Critical Data: Replace sensitive PII with less critical information where possible, e.g., fine-grained location by coarse-grained location.
• Reduce Data Collection Frequency: Reduce the frequency of sensitive data collection, e.g., location updates every hour instead of every minute.
• Anonymize or Blur Data: Anonymize PII through hashing, bucketing, or adding noise to reduce risk if data is exposed.
• Delete Expired PII: Delete PII after an expiration period, e.g., only keep health data of the last week.
• Obtain User Consent: Allow users to consent to optional PII usage, e.g., to receive a better service but also be aware of the additional risk.
• Protect Remaining PII: PII that must be stored or transferred should be protected with proper authentication and authorization. Access must be controlled.
• Defense in Depth: Apply defense-in-depth for particularly critical data. For example, health data may be encrypted with a key sealed in the device's TPM in addition to storage in the app's sandbox.
• Threat Modeling: Use threat modeling to determine the most likely ways that privacy violations may occur and focus security efforts accordingly.
• Automated Security Tools: Deploy static and dynamic security checking tools to reveal common pitfalls like logging of sensitive data or leakage to clipboard or URL query parameters.

Example Attack Scenarios

• Inadequate Sanitization of Logs and Error Messages: Reporting of logs and exceptions is essential for quality assurance of a productive app. Crash reports and other usage data helps developers to fix bugs and learn about how their app is used. However, logs and error messages might contain PII if the developers chose to include this data in log or error messages.
• Using PII in URL Query Parameters: URL query parameters are often used to transmit request arguments to a server. However, URL query parameters are visible at least in the server logs, but often also in website analytics and possibly in the local browser history. So sensitive information should never be transmitted as query parameters.
• Exclusion of Personal Data in Backups: Most PII processed by an app is stored in its sandbox. The app should explicitly configure what data to include in device backups. An attacker might obtain a device and create a backup or get a backup from another source, from which the sandbox content could be extracted.