The OWASP Mobile Top 10 is the reference list of the most significant mobile app security risks, and one of its entries is not about a classic vulnerability at all: M6, Inadequate Privacy Controls, is about how your app handles people's personal information. It covers the collection, storage, transmission, and processing of personally identifiable information, and the failures that let that information be exposed or misused. In an era of privacy labels, data-deletion requirements, and privacy law, this risk is as much about your app's relationship with user data as about any single bug. Here is what M6 is and how to address it.
Short answer
M6, Inadequate Privacy Controls, is the OWASP Mobile Top 10 risk concerning the protection of personally identifiable information (PII), such as names, email addresses, payment details, location, and similar data, throughout how an app collects, stores, transmits, and processes it. Per OWASP, the risk is that inadequate controls let PII be exposed, misused, or accessed by an attacker who manipulates the app or its API, leading to harms like fraud or profiling. The defenses are to minimize the PII you collect, store, and transmit, protect it at rest and in transit, limit access to it, and anonymize where possible. The principle is to handle the minimum personal data necessary and protect it at every stage.
What you should know
- M6 is about personal information: how an app handles PII, not a single bug.
- It spans the data lifecycle: collection, storage, transmission, processing.
- The harm is exposure or misuse: fraud, profiling, or unauthorized access.
- Minimization is central: collect and keep the least PII necessary.
- Protect PII at every stage: at rest, in transit, and in access.
What is M6: Inadequate Privacy Controls?
It is the risk that an app does not adequately protect the personal information it handles. Personally identifiable information, anything that identifies a person or could combine to do so, names, contact details, payment information, location, device identifiers, flows through an app at several stages: it is collected from the user or device, stored locally or on a server, transmitted over the network, and processed for features. M6 is the failure to apply adequate controls across that lifecycle, so PII is collected when it need not be, stored or transmitted without protection, exposed more widely than necessary, or accessible to an attacker who manipulates the app or its backend. Unlike risks tied to a specific technical flaw, M6 is about the app's overall handling of personal data, which is why it intersects so directly with privacy labels, privacy law, and user trust. It treats personal information itself as the asset to protect.
How do privacy controls fall short?
In a handful of recurring ways across the data lifecycle. The table lists them.
| Failure | What it looks like |
|---|---|
| Over-collection | Gathering more PII than the features need |
| Unprotected storage or transit | PII stored or sent without adequate protection |
| Excessive exposure | PII returned or accessible beyond what is needed |
| Weak access controls | PII reachable by manipulating the app or API |
| Indefinite retention | Keeping PII longer than necessary |
The common thread is handling more personal data, more widely, for longer, than the app's purpose requires. Over-collection gathers PII features do not need; unprotected storage or transit leaves it exposed at rest or on the network; excessive exposure returns or makes PII reachable beyond what a given context needs, overlapping with API risks like excessive data exposure; weak access controls let an attacker reach PII by manipulating the app or its API; and indefinite retention keeps personal data around long after its purpose has passed. Each is a privacy control that was not applied where personal data is involved.
How do you address M6?
Minimize personal data and protect it at every stage. Collect only the PII your features genuinely need, and avoid gathering data speculatively, since the data you never collect cannot be exposed. Protect PII at rest with appropriate storage and encryption, and in transit with TLS, the same protections you apply to any sensitive data, because personal data is sensitive data. Limit access to PII so that it is returned and reachable only where a given context requires, and enforce that on the server, since the app cannot be the gatekeeper. Retain personal data only as long as needed and delete it when its purpose ends, which also aligns with deletion rights under privacy law. Anonymize or aggregate where you can, so that what you do keep is less sensitive. And keep your actual handling consistent with your privacy label and disclosures, so users are not surprised. The principle of M6 is data minimization plus protection: hold the least personal data necessary, protect it throughout its lifecycle, and let it go when it is no longer needed.
What to watch out for
The first trap is collecting PII you do not need, often through SDKs or out of habit, which becomes a liability you then have to protect; minimize first. The second is protecting PII in transit but not at rest, or exposing it through an API that returns more than a context needs. The third is keeping personal data indefinitely and a gap between your handling and your privacy disclosures. A pre-submission scan such as PTKD.com (https://ptkd.com) reads the compiled app against OWASP MASVS and surfaces how it stores data and what endpoints and SDKs it contacts, which helps you see where PII is handled, while minimization and retention decisions are yours to make.
What to take away
- M6, Inadequate Privacy Controls, is the OWASP Mobile Top 10 risk about protecting personally identifiable information across collection, storage, transmission, and processing.
- Inadequate controls let PII be over-collected, stored or transmitted without protection, exposed beyond what is needed, reached through weak access controls, or kept indefinitely.
- Address it by minimizing the PII you collect and keep, protecting it at rest and in transit, limiting access server-side, retaining it only as long as needed, and matching your privacy disclosures.
- Use a pre-submission scan such as PTKD.com to surface how your app stores data and what it contacts, then minimize and protect the personal data it handles.
