In September 2015 a Dropbox security engineer published four posts on getting a Content Security Policy into production — what broke, what they had to build, and what they would do differently. The policy is still in their response headers today.
The part worth reading is what nearly stopped them, and it was not writing the policy or deploying it. It was that the violation reports coming back were unusable: mostly browser extensions and injected malware rather than attacks on their site. They had to build a three-stage filter before the data meant anything.
What their headers say
www.dropbox.com — HTTP response header
content-security-policy: report-to csp-metaserver-dynamic;
report-uri https://www.dropbox.com/csp_log?policy_name=metaserver-dynamic;
script-src 'unsafe-eval' 'strict-dynamic'
'nonce-geJS2gGDCRq2aliITopu54yda80='
Two nonces regenerated per response, 'strict-dynamic' so modern browsers ignore the host allowlist and trust the nonce instead, and a reporting endpoint they run themselves.
Not a customer
Dropbox has no relationship with Report URI and nothing here is an endorsement. They collect their own reports at their own endpoint. The reason the page exists is the architecture they chose — a policy in the header, and something watching what it reports — because the second half is the part most teams never get to.
