Box and Dropbox Security Guide: Sharing Controls, Apps and Admin Access

Box and Dropbox tenants hold contracts, HR files, board papers and source material, and the easiest way to lose them is not a platform flaw but an open shared link, an over-privileged admin or a server app that can read every user's content. Both platforms give administrators strong controls, but several of the most important ones (who may approve server apps, default link access, link expiry, how much an integration can see) are choices the tenant owner has to make. This guide explains how identity, sharing and integrations work in Box and Dropbox, how to control admin and app access, what to log and how to harden a tenant. It is written for collaboration platform owners, identity teams and security engineers responsible for an enterprise Box or Dropbox deployment. Feature and setting names follow the Box and Dropbox developer and help documentation as of October 2026; some features depend on plan level.

Key takeaways

• Server apps are the most powerful identities in the tenant. A Box JWT or Client Credentials Grant app gets a Service Account with admin-like privileges, and a Dropbox team-scoped app can act as any member through the Dropbox-API-Select-User header.
• Admin approval is the control point. Box server apps do nothing in an enterprise until a Box Admin authorises them, and any change of scopes or access level needs reauthorisation, so the approval queue is where review belongs.
• Shared links are the main leak path. Box "open" links and Dropbox "Anyone with link" links need no sign-in at all; set company or team-only defaults and an expiry policy before anything else.
• Folder permissions cascade. Box permissions follow a waterfall: a collaborator on a parent folder has the same access to everything below it, so one invitation at the wrong level exposes whole project trees.
• Stream the logs out early. Box keeps admin_logs_streaming events for two weeks and Dropbox activity can take up to 24 hours to appear, so forward events to a SIEM rather than relying on the admin console after an incident.

How identity and access work in Box and Dropbox

Both platforms are organised around a tenant (an "enterprise" in Box, a "team" in Dropbox) with managed users who sign in with a password or through SAML single sign-on, and content owned by those users or by shared team spaces. External people can be invited as collaborators or reached with links, which is what makes these platforms useful and what makes them risky.

Box

• Managed users: accounts that belong to the enterprise and are controlled by its admins.
• Collaborators: any Box user, internal or external, invited to a file or folder with a permission level. Box defines seven: Co-owner, Editor, Viewer Uploader, Previewer Uploader, Viewer, Previewer and Uploader. Several (including Co-owner and Previewer) are Business and Enterprise only and must be enabled under Admin Console, Enterprise Settings, Content & Sharing.
• Waterfall permissions: access granted on a folder applies to every item under it, and a collaborator's level cannot be reduced on a subfolder without changing it on the parent.
• Service Accounts and App Users: created for server-authenticated apps (see below), with names of the form AutomationUser_xxxx.

Dropbox

• Team members: accounts on a Dropbox team, with statuses invited, active, suspended, deleted and disconnected.
• Shared folders and team folders: content shared with members and outsiders; team spaces belong to the team rather than an individual.
• Admins: Dropbox's Team Administration API documentation describes tiered admin roles on some licences, naming team admins, user management admins and support admins.

Sharing models compared

Note that Dropbox's own help text is explicit that disabling downloads only blocks the Dropbox download button; screenshots and other capture still work. Treat download controls as friction, not as data loss prevention. See the Secure File Sharing Guide.

Admin roles and privileged access

Admin accounts on a file platform can read, transfer and delete content, change sharing policy for the whole tenant and approve the integrations that see everything. Treat them as privileged accounts under your PAM programme.

• Box admin tiers: Box has a primary admin, admins and co-admins, and co-admins are given a selected set of privileges (for example, the right to "Run new reports and access existing reports", which is what grants access to enterprise event logs). Give co-admin rights for a specific job rather than making helpdesk staff full admins.
• Dropbox admin tiers: use the narrower user management and support admin roles for day-to-day account work and keep team admin to a small named group.
• Admin-only API calls: Box endpoints that manage users, groups and governance features need an admin or co-admin token, and the Dropbox Dropbox-API-Select-Admin header lets a team token act as a named administrator. Both are privileged paths that do not involve the admin console at all.
• Strong authentication: require SSO with phishing-resistant MFA for every admin. The Dropbox GitHub breach in 2022 showed why: employees typed both a password and a hardware-key one-time code into a fake CircleCI page, and the attacker relayed them in real time. Dropbox's stated response was to accelerate WebAuthn. See the Phishing-Resistant MFA Guide.
• Break-glass: keep one or two emergency admin accounts outside SSO, with long random passwords in a vault, alerting on every sign-in. See the Break-Glass Account Guide.
• Offboarding: Dropbox can suspend a member (API calls then return 401), remove them with data transfer and optional device wipe, and recover a removed member within 7 days. Suspend first during investigations so content is preserved.

Integrations, API tokens and service accounts

Most of the content that leaves a file platform through an integration leaves under a non-human identity: a server app's Service Account, a team-scoped token or a user's refresh token held by a third party. These are the identities to inventory first.

Box application types

• Service Account: authorising a JWT or CCG app creates a Service Account that Box describes as having admin-like privileges. It owns and collaborates on content like any user, so its collaborations need the same review as a person's.
• Access level: choose "App Access Only" when the app only needs its Service Account, App Users or content they own or collaborate on. Choose "App + Enterprise Access" only when it must reach managed users' existing content, and only combine it with "Generate User Access Tokens" when impersonating managed users is the purpose.
• Approval and reauthorisation: enterprise admins authorise server apps by Client ID under Admin Console, Platform, Platform Apps. Authorisation is a snapshot, so a developer who later adds scopes or raises the access level must resubmit the app for reauthorisation. Enable "Disable unpublished apps by default" so OAuth apps also need admin enablement.
• Auth type switching: the enterprise setting "Switch server app auth type (CCG or JWT)" is off by default; leave it off unless there is a migration plan.
• Downscoping: Box supports downscoping access tokens before handing them to a front end or a less trusted component, so a browser never holds the Service Account's full token.

Dropbox application types

• User-linked apps: an access token for one user and app pair. Apps choose "App Folder" (limited to /Apps/<app name>) or "Full Dropbox" access; prefer App Folder for anything that only needs its own files.
• Team-linked apps: requesting team scopes produces a token tied to the team, not to the admin who approved it. With the team_data.member scope the app can use Dropbox-API-Select-User to act as any member, or Dropbox-API-Select-Admin in "Whole Team" mode to read team folders and members' home namespaces. That is read access to the whole company's files.
• Token lifetime: Dropbox issues short-lived access tokens; long-lived tokens are deprecated and were only available until mid 2021. Background integrations request token_access_type=offline and receive a refresh token, which is now the long-lived secret to protect.
• Client type: public clients (single-page, desktop, mobile) should use PKCE with code_challenge_method S256, and app owners should disable the legacy implicit grant in the App Console if unused.
• Revocation: admins can view and revoke member-linked apps through the team linked apps functions, and apps can revoke their own tokens with the token revoke endpoint.

The Dropbox Sign breach in 2024 is the non-human version of this risk: an attacker who reached an automated system configuration tool compromised a back-end service account with broad production privileges, and customers' API keys and OAuth tokens were among the data exposed. Dropbox restricted API key use until customers rotated. Keep a rotation runbook for every Box and Dropbox credential you issue to integrations. See the SaaS and OAuth App Governance Guide and the SaaS API Token Security Guide.

Logging and detection

Box exposes two enterprise event feeds. admin_logs is the Enterprise Event History API: one year of events, chronological, without duplicates. admin_logs_streaming is the Enterprise Event Stream API: two weeks of events, low latency, possibly duplicated or out of order, so de-duplicate on event ID. Admin Console reports can be exported for seven years. Dropbox records team activity under Admin console, Activity, with categories including Apps, Devices, Logins, Members, Passwords, Sharing, SSO, Team policies and Two-factor authentication; file operations are logged only on Business Plus, Advanced and Enterprise plans, and entries generally appear within a few hours and at most 24.

T1567.002 cuts both ways: your own users or an intruder may push data out to a personal Box or Dropbox account. Detect that at the proxy or CASB rather than in your tenant's logs. Box Shield adds anomaly detection, deep-learning malware detection and context-rich alerts on top of the raw events, and Shield Pro adds ransomware activity detection.

Metrics that show it is working

• Public links: number of open or "Anyone with link" links, and the share of them with an expiry date.
• External collaborations: count of external collaborators on folders classified confidential, trending down.
• Server apps: percentage of approved apps with a named owner, App Access Only and a review in the last 12 months.
• Admins: number of full admins (target: a small fixed number) and percentage using phishing-resistant MFA (target: 100%).
• Log coverage: hours of delay between an event and its arrival in the SIEM, and whether any day has gaps.
• Response: median time to revoke a suspect app token or public link after an alert.

Hardening baseline

Decision guidance

• Small organisations: start with team-only or company-only default links, mandatory expiry, SSO with MFA and a short allowlist of apps. One person reviewing the Activity page weekly is a reasonable start if logs are also exported.
• Large or regulated organisations: add classification (Box Shield or a third-party labelling scheme), forward events to a SIEM, separate admin roles by function and put server-app approval through change management with a named business owner.
• JWT or Client Credentials Grant on Box: JWT keeps a private key that never travels and can be paired with a public key per environment; CCG is simpler but rests on a shared secret. Choose JWT when the secret would sit in many places; either way, store the credential in a secrets manager, never in config files in source control.
• Team-scoped or user-scoped Dropbox apps: grant team scopes only to tools whose purpose is tenant-wide (backup, eDiscovery, DLP). Anything that serves one department should be a user-linked app with App Folder access where possible.

Phased rollout

1. Inventory (weeks 1 to 2): export all admins, approved Box Platform Apps with access level and scopes, Dropbox team-linked and member-linked apps, and every public link. Assign an owner to each app.
2. Admins first (weeks 2 to 3): reduce full admins, move others to co-admin or narrower admin roles, enforce SSO and phishing-resistant MFA, create break-glass accounts.
3. Logging (week 3): connect admin_logs_streaming and the Dropbox event log to the SIEM, and test that a test share and a test app approval both arrive.
4. Sharing policy in pilot (weeks 4 to 6): apply company or team-only defaults and default link expiry to one department; measure help desk tickets and exceptions. Existing links are not changed by new defaults, so plan a separate clean-up.
5. Clean up (weeks 6 to 10): notify owners, then expire public links older than an agreed age on confidential folders, and remove stale external collaborators.
6. Apps (ongoing): move server apps to App Access Only where possible, rotate keys and secrets, revoke unowned apps, and require reauthorisation through change control.
7. Rollback: keep exports of previous sharing settings and app authorisations. If a policy breaks a business process, grant a time-boxed exception for the specific folder or app rather than reverting the tenant default.

Common misconfigurations

• Open links as the default: users pick the first option. If the default is public, confidential folders end up public, and new tenant defaults do not retroactively fix existing links.
• Server apps approved with App + Enterprise Access "just in case": the app's Service Account can then reach every managed user's content, and its credential becomes the most valuable secret in the tenant.
• config.json and client secrets in code: the Dropbox GitHub breach found developer API keys in copied repositories; Box config.json files contain the private key and passphrase together. Scan repositories for both. See the Secrets Management Guide.
• Invitations at the top of the tree: because of waterfall permissions, inviting an external partner to a parent folder to share one subfolder exposes everything beside it.
• No owner for integrations: team-linked apps keep working after the admin who approved them leaves, because the token is tied to the team. Without an owner and review date nobody notices when the vendor is breached.
• Relying on the console after an incident: two weeks of streaming retention and up-to-24-hour Dropbox delays mean evidence is late or gone unless it is already in a SIEM.

Framework mapping

Practitioner checklist

• Set tenant default link access to company or team-only and turn on a default expiry for new links.
• Report every open or "Anyone with link" link on confidential content and expire or justify each one.
• Limit full admins to a small named group with SSO, phishing-resistant MFA and separate admin accounts.
• Require admin authorisation for all Box server apps and enable "Disable unpublished apps by default".
• Review every Box app for App Access Only versus App + Enterprise Access and every Dropbox app with team_data.member.
• Store Box config.json files, client secrets and Dropbox refresh tokens in a secrets manager and scan code for them.
• Stream Box admin_logs_streaming and Dropbox activity to the SIEM and alert on new apps, MFA disablement and mass download.
• Review external collaborators on confidential folders every quarter and remove stale ones.
• Keep a rotation and revocation runbook for every integration credential, tested at least once a year.

Standards and references

• Box Developer: Security best practices
• Box Developer: JWT authentication
• Box Developer: Platform app approval
• Box Developer: Enterprise events
• Dropbox: OAuth guide
• Dropbox: Authentication types
• Dropbox Help: Shared link settings
• MITRE ATT&CK: Data from Cloud Storage

Related NHI Mgmt Group resources: SaaS Security Guide · SaaS and OAuth App Governance Guide · Top 10 SaaS Security Risks · SaaS Security Buyer's Guide · Secure File Sharing Guide