Box is secure. Your integration is the question.

Box's own controls are good at what they can see: the link inventory, content classification, the access event stream, and an admin gate on every server-auth app. All of that is Box-side state. None of it reaches the config file your deploy serves at its web root, the token your page hands to a browser, the webhook receiver that never checks a signature, or the API route that forwards a query-string user id into As-User. Those are written by your team, run on your infrastructure, and are invisible to the console by construction.

Box's JWT server-auth flow hands you exactly one file, and tells you it is the only chance you get to save the private key. That is precisely why it ends up committed next to the code and deployed with it. Anyone holding it mints a JWT assertion, exchanges it for a Service Account token, and reaches everything the app can reach — and if the app was authorised with enterprise access, that is the enterprise's content. Rotating a leaked one means a new key pair in the Developer Console and re-authorisation in the Admin Console.

Most cloud credentials announce themselves. An AWS key starts AKIA, a Supabase token sbp_, a Grafana token glsa_ — match the prefix and you're done. A Box client secret and a Box access token are 32 characters of undifferentiated letters and digits with no prefix at all, which is also an exact description of every build hash, cache key, ETag and asset fingerprint in a modern bundle. A scanner that flags the value flags your whole deploy.

So the value is never the signal. The name it was assigned to is — and the value only has to look like a real one rather than a placeholder.

A Box app with the right advanced features can act as any user in the enterprise — Box describes the Client Credentials Grant as letting an app "act on behalf of any user in an enterprise." That power is delegated through one header. The failure is not Box granting it; the failure is your app deciding who to be from something the caller controls.

The ids aren't guessed. They're the ones the app itself handed out in an id-named form field, plus their immediate neighbours — so the probe is a real account, not a fishing expedition. box_user_id, box_subject_id and as_user also join the hidden-parameter sweep, which finds the ones your API accepts but never documents.

Box signs every webhook with HMAC-SHA256 over the body concatenated with the delivery timestamp, sends two signatures so keys can rotate, and tells implementers two things in writing: reject a payload older than ten minutes, and compare the digests with a timing-safe function. Almost nobody writes that comparison themselves — the SDK does it. Which is the problem.

It fires from a package.json or lockfile your deploy actually serves, matched on an exact pinned version — never a range, never a guess. The version comparison is semantic, so the 10.x line reads as newer than 3.8.1 rather than older, which a string comparison gets backwards.

In March 2019, researchers enumerated Box enterprise subdomains and their shared links and found more than 90 companies exposing hundreds of thousands of documents — passport scans, bank details, network diagrams, VPN configs, years of internal meeting archives. Apple, Discovery, Amadeus and Box itself were in the set. That was not a Box vulnerability: Box enterprise content is private by default, and every one of those links had been set to public by someone. Box's own guidance since then is blunt about the mechanism — custom shared URLs "can be easily guessed by outside parties," and links posted on a website get indexed by search engines.

These live inside your tenant, so no external scan can see them and nobody should tell you otherwise. They are the other half of a Box integration review, and they're short: