TL;DR: A flaw in Microsoft’s OneDrive File Picker can let connected web apps access a user’s entire OneDrive instead of only selected files, affecting hundreds of apps and potentially millions of users, according to Oasis Security. The issue exposes how vague consent, broad OAuth scopes, and token handling can turn routine file sharing into enterprise data exposure.
At a glance
What this is: This research shows that OneDrive File Picker can overgrant web apps broad read access to user files, rather than limiting access to the selected upload item.
Why it matters: It matters because IAM teams need to govern delegated access, token storage, and consent wording when third-party apps can inherit far more file access than users expect.
Context
OneDrive File Picker is a delegated file access flow, not just a file upload widget. When the consent path is vague and the scope model is broader than the task, users may approve access they do not understand, and web apps can inherit access far beyond the chosen file.
The governance gap is not limited to consumer convenience. In enterprise settings, broad delegated access can expose regulated data, create audit ambiguity, and complicate third-party risk management when app behaviour does not match user intent.
Key questions
Q: What breaks when a file picker grants cloud access instead of true file-level permissions?
A: True least-privilege sharing breaks down because the app may receive access to far more content than the user intended. That can expose entire folders, create persistence through temporary tokens, and make revocation less effective than administrators expect. In practice, the control failure is not just overexposure, but the loss of meaningful user awareness at the moment consent is given.
Q: Why do broad delegated file permissions create more risk than a normal upload flow?
A: Because the permission often outlives the upload. Once an app has broad read access and a usable token, it can keep reaching into OneDrive beyond the original task, which turns a one-time file exchange into an ongoing exposure path for sensitive content.
Q: What are the signs that a third-party file picker integration is mis-scoped?
A: Look for consent prompts that do not clearly state the scope, apps that request drive-wide access for single-file actions, browser-side token storage, and refresh tokens that extend access beyond the immediate upload session. Those are the practical warning signs that the integration is over-permissioned.
Q: How should teams govern delegated access from web apps to cloud file stores?
A: Treat it as an identity governance problem, not just an application integration. Teams should verify scope precision, review which apps can reach user files, control token lifetime, and make revocation simple enough that access can be removed when the business need ends.
Technical breakdown
Why broad OAuth scopes break least privilege in file picker flows
The core problem is that the OneDrive File Picker implementation requests read access to the whole drive even when the user is only selecting one file. That is a privilege-matching failure: the access token reflects the integration’s technical convenience, not the specific task the user approved. When fine-grained scopes do not exist, the app must often request more than it truly needs, and the consent screen becomes the only control boundary visible to the user. If that prompt is vague, the real access scope is effectively hidden behind a normal workflow.
Practical implication: Treat file picker consent as an access grant review point, not a UI step, and validate whether the requested scope matches the business task.
How token storage extends exposure after the upload ends
The article notes that the newer File Picker model can push developers toward Microsoft Authentication Library handling and browser storage patterns that keep tokens accessible longer than necessary. Access tokens are short-lived, but refresh tokens and poorly secured browser storage can prolong the window in which a connected app can continue to access OneDrive content. That changes the risk from a single upload event to persistent delegated access. If tokens are left in session or local storage, the browser itself becomes part of the trust boundary.
Practical implication: Review where access and refresh tokens are stored and remove any browser-side persistence that is not strictly required for the use case.
Why vague consent language weakens delegated access governance
Consent prompts only work when the user can understand the scope being granted. Here, the article describes language that does not clearly communicate that the app may receive access to the entire drive, which means user approval is not an informed control. This is especially problematic in third-party web app ecosystems where the user assumes a task-scoped action but the permission model grants broader read access. The result is a mismatch between perceived consent and actual authorization, which is a governance failure as much as a technical one.
Practical implication: Audit consent text and delegated permission reviews for clarity, and align user messaging with the real access scope rather than the intended workflow.
Threat narrative
Attacker objective: Obtain broad, persistent access to OneDrive content through a delegated app integration rather than limiting access to a single selected file.
- Entry occurs when a user connects a web app to OneDrive through the File Picker and approves the consent prompt for upload-related access.
- Credential exposure follows because the app receives tokens that can be stored insecurely in browser session storage or extended through refresh token issuance.
- Escalation happens when the granted scope allows the app to read the broader OneDrive rather than only the selected file, expanding access beyond the user’s intent.
- Impact is unauthorized exposure of files, which can lead to customer data leakage and compliance violations across personal and enterprise accounts.
NHI Mgmt Group analysis
Consent wording is not a usability detail when delegated file access is involved. This flaw shows that vague prompts can become an authorization failure, because users approve a workflow without understanding the true access boundary. In practice, file-sharing consent must be treated as part of the access model, not a wrapper around it. Practitioners should assume that unclear consent language creates governance debt, not just user confusion.
Browser token handling has become an identity control surface. When access tokens or refresh tokens live in session storage or similar client-side locations, the browser itself inherits part of the trust boundary. That means delegated access is no longer bounded solely by the app and the identity provider. IAM and security teams need to treat token placement as an access-risk decision, not a developer convenience choice.
Task-scoped intent and scope-granted reality are drifting apart. The named concept here is scope-intent mismatch: the user believes they are approving a single-file action, while the integration receives broader drive-level authority. That gap is especially dangerous in ecosystems built on third-party web apps, because delegated access can outlive the original user action. The implication is that governance must evaluate whether the permission model actually matches the user journey.
Third-party app access reviews need to be tied to delegated scope quality, not just app inventory. Hundreds of apps may be connected, but the real control question is whether each app’s granted scopes are proportionate to its function. If one consent flow can expose an entire drive, then app count alone understates the risk. Practitioners should focus on scope precision, token lifetime, and revocation paths as the primary governance variables.
File picker risk sits at the intersection of human IAM and NHI governance. A human user grants consent, but the durable risk is carried by the non-human access token and the connected app using it. That makes this a hybrid identity problem: human approval creates machine authority. The practical conclusion is that delegated app governance must cover both the person who approved access and the service that continues using it.
What this signals
Scope-intent mismatch: The important governance issue is not simply that an app connects to OneDrive, but that delegated access can exceed the task the user thought they approved. When permission text, OAuth scope, and token lifetime do not align, consent becomes a weak control and access review has little to certify.
File picker integrations should be assessed as part of the broader human-plus-NHI delegation chain. The user makes the approval decision, but the app and token carry the lasting authority, so security teams need controls that cover both consent quality and token lifecycle.
For practitioners, the immediate signal is to re-examine third-party file workflows that depend on browser-based auth, especially where refresh tokens or client-side storage can keep OneDrive access alive after the upload is complete.
For practitioners
- Review delegated app scopes Inventory connected apps and verify whether each granted scope matches the actual file-sharing task, especially where OneDrive access is broader than a selected upload item.
- Remove browser-side token persistence Eliminate session storage or local storage patterns that keep access tokens available in the browser longer than needed, and dispose of refresh tokens if they are not required.
- Rework consent wording and approval review Make consent prompts and admin review steps state the real access boundary in plain language so users and reviewers can see when a web app is receiving drive-wide read access.
- Temporarily disable risky file picker flows If the integration cannot enforce least-privilege scopes, remove OneDrive file upload via OAuth and use a safer alternative such as view-only links until the access model is corrected.
- Check token revocation and lifetime controls Confirm that stopping sharing revokes refresh tokens where present and that access token expiry, revocation, and downstream app permissions are actually enforced.
Key takeaways
- The flaw is not just a bad upload experience. It is a delegated access problem that can turn a single user action into broad file exposure.
- The article says hundreds of apps and millions of users may be affected, which makes the issue a governance problem rather than an isolated integration bug.
- Teams should focus on scope precision, token storage, and revocation because those controls determine whether file picker access stays task-scoped or becomes persistent.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5, NIST CSF 2.0 and CSA Cloud Controls Matrix set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | The flaw depends on delegated auth flows that grant more access than the user intends. |
| NHI-05 — Overprivileged NHI | Connected web apps receive broader file access than the task requires. | |
| NHI-07 — Long-Lived Secrets | Refresh tokens and stored access tokens can extend access beyond the upload event. | |
| Recommendation — Review delegated authentication flows for scope precision and remove prompts that obscure the real access granted. Constrain app permissions so web integrations only receive the minimum read scope required for the file action. Eliminate unnecessary refresh tokens and shorten the lifetime of browser-held access credentials. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Authenticator lifecycle and revocation are central when tokens persist after consent. |
| Recommendation — Apply authenticator management controls to token storage, expiry, and revocation for delegated app access. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | This article is about mismatched entitlements and delegated authorisations in a file-sharing flow. |
| Recommendation — Align entitlements with task scope and verify that granted permissions do not exceed the intended file action. | ||
| CSA Cloud Controls Matrix | IAM — Identity and Access Management | Cloud IAM governance is the control plane for delegated web app access to OneDrive content. |
| Recommendation — Govern delegated cloud app access through IAM controls that cover consent, scope, and revocation. | ||
Key terms
- Delegated Access: Delegated access is permission granted to one identity to act on behalf of another user, service, or system. In NHI environments, this usually appears in OAuth-connected apps and automation tooling. It is powerful, but it must be tightly scoped and reviewed because it can persist long after the original business need ends.
- Scope Mismatch: Scope mismatch occurs when the access granted to an application does not align with the user action or business need that triggered the request. In file picker flows, it means a single-file task can result in broad drive-level authority, creating avoidable exposure and audit confusion.
- Refresh Token: A longer-lived credential that can mint new access tokens without forcing the user to authenticate again. Because refresh tokens can preserve access for extended periods, they are a major governance concern when malicious or over-scoped applications are granted consent.
- Consent Prompt: A consent prompt is the user-facing approval step where an application asks permission to access data or services. In enterprise identity, it can become a governance problem when the decision is really organisational rather than personal, because the prompt can obscure who owns the access decision and who bears accountability.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on June 4, 2026.
Updated on October 6, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org