A permission design issue in OneDrive file selection flows that can grant third-party apps broader access than users expect. Instead of limiting an app to a single uploaded file, the OAuth consent may expose much larger parts of the drive, creating avoidable data exposure and compliance risk.
Expanded Definition
The OneDrive File Picker OAuth Flaw is a permission-scope problem in a file-selection workflow, not a flaw in file storage itself. The issue arises when an app that is only meant to receive a chosen file is instead granted access patterns that reach beyond that single object, often because the consent experience is too broad or the token-backed delegation is more expansive than users assume. That difference between intended selection and actual authorization is the core security boundary.
This term is best understood as an OAuth consent and resource-scoping problem in a cloud collaboration setting. The flaw affects how users, apps, and the hosting platform interpret access, so the practical question is not simply whether a file picker works, but whether the resulting access token and permissions match the user’s real intent. As a result, the term belongs to application security and SaaS governance first, with identity and access consequences emerging from the over-broad delegation.
There is a useful boundary here: a file picker that requests broad drive access for convenience is not automatically a flaw if the design is explicit and justified. The flaw exists when the flow creates a misleadingly narrow expectation while enabling materially wider read or write exposure.
Examples and Use Cases
In practice, this issue appears in workflows where a user thinks they are uploading one document, but the integration is authorized to inspect more of the drive than the user intended. The same pattern can affect consumer and enterprise tenants when the consent screen or picker abstraction hides the real extent of the delegated access.
- A document-signing integration asks for a file through the picker, then later can enumerate additional files because the granted scope was broader than the upload action implied.
- A productivity app uses the picker to attach one report, but the consented token also permits the app to browse shared folders that were never part of the task.
- A custom business app relies on the picker as a user-friendly front end, yet the platform authorization model still permits the app to retain durable access after the initial selection.
- An enterprise tenant reviews a third-party app and finds that the user journey suggested single-file access while the actual delegated permissions support much wider content exposure.
The implementation tradeoff is usability versus least privilege. Narrower scopes and more explicit consent reduce exposure, but they can also make integrations harder to build and support.
Security Implications
When this flaw is misunderstood, organisations can overestimate how tightly third-party apps are constrained. That creates a false sense of control around data sharing, especially where users believe they have approved one file and nothing more. The result can be unintended access to adjacent documents, folder metadata, or other content that was never necessary for the use case.
The security consequence is not only privacy exposure but also governance failure. Access reviews may miss the true scope of delegated permission, retention policies may not reflect what a third party can still reach, and incident response teams may discover too late that a seemingly narrow integration had broader visibility. In regulated environments, that mismatch can complicate records handling, data minimisation, and third-party assurance.
A common practitioner signal is a gap between the user story and the actual token scope. If the business owner describes the app as a single-file selector, but the consent grant or API permission model supports broader browsing or retrieval, the control assumption is already weakened.
Domain and Governance Relevance
This term matters most in cloud application governance, where delegated access must be aligned with the real task the app performs. The issue sits at the intersection of user consent, app registration, token scope, and data exposure, so it is not enough to treat it as a simple UI concern. Security teams need to assess whether the picker flow actually enforces the principle of least privilege or only presents it.
For identity and access governance, the key question is whether a third-party app can accumulate more trust than the user intended through a single approval path. That is especially important when the app is operated by a supplier, because the effective control boundary extends beyond the end user to the app owner and its retention practices. The governance problem is therefore about delegated authority, not just file transfer.
NIST guidance on access control and authorization design provides a useful control lens for this kind of exposure, particularly where user consent does not clearly match effective permission scope. The NIST SP 800-53 Rev 5 Security and Privacy Controls resource is especially relevant when organisations need to tighten approval, review, and enforcement around delegated access.
Risk and Threat Considerations
The material risk is unintended over-authorization of third-party applications, which can expose more content than the user intended and create a broader blast radius than the business expects. In a shared cloud drive environment, that can turn a convenience feature into a data exposure path.
Failure mechanism: The weakness materialises when the authorization model grants broader delegated access than the picker interaction implies, or when a token remains valid beyond the narrow file-selection moment. An attacker does not need to break the platform if the app’s granted scope already allows wider browsing, retrieval, or persistence.
Impact: Sensitive documents, metadata, and adjacent content can become accessible to a third-party app, with downstream risk to confidentiality, compliance, and incident scope. If the app is compromised later, that overbroad permission can be reused to harvest data at scale.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0, CIS Controls v8 and NIST SP 800-63 set the technical controls, while PCI DSS v4.0 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC — Identity Management, Authentication and Access Control | Delegated app access must match intended scope and authorization. |
| Recommendation — Enforce least-privilege app consent and validate delegated access scopes regularly. | ||
| CIS Controls v8 | 6 — Access Control Management | This flaw is fundamentally about overbroad third-party access paths. |
| Recommendation — Restrict third-party app permissions to the minimum required and remove excess grants. | ||
| NIST SP 800-63 | CSP-4 — Federated Identity Assertions | The picker relies on delegated identity assertions and consent trust. |
| Recommendation — Verify federation and consent flows so asserted permissions do not exceed intended use. | ||
| PCI DSS v4.0 | 8 — Identify Users and Authenticate Access | Third-party access scope affects control over systems storing payment-related data. |
| Recommendation — Limit application access to only the data and actions the business purpose requires. | ||
Practitioner Guidance
Why practitioners should care: Treat the picker flow as an authorization boundary, not a convenience layer. If the application owner, security reviewer, and user all describe the integration differently, the access model is probably too broad for the intended task.
Common misunderstanding: Many teams assume a file picker guarantees single-file access. In reality, the picker often sits on top of consent and token scope decisions that must be validated independently.
Practitioner takeaway: Review the actual delegated permission model, not just the user interface, before approving third-party integrations that touch cloud content.
Related resources from NHI Mgmt Group
- How do security teams know whether a file picker integration is too permissive?
- How do security teams know whether a file upload flaw is actually being abused?
- What should teams do immediately when a runtime file-read flaw exposes secrets?
- Why do customised captive portals increase the blast radius of a controller file-read flaw?
