advanced 2 min answer

Design the browser-side security posture for an application handling sensitive user files.

frontend-securitycspxsstokensdropbox
Show the full answer Hide the answer

The threat that dominates

Cross-site scripting. Script executing in the application's origin can do anything the user can do — read the DOM, call the API with the user's credentials, exfiltrate data. Every other browser-side control is weakened if this one fails, so it deserves defence in depth rather than a single mitigation.

The controls, in order of value

  • A strict Content Security Policy, ideally nonce-based, prohibiting inline script and restricting sources. This is the control that limits the damage when an injection does occur, and it is the one most often deferred because retrofitting it is genuinely painful.
  • Contextual output encoding by default, through a framework that escapes automatically, with dangerous escape hatches audited.
  • Tokens in cookies with HttpOnly, Secure and SameSite, rather than in local storage where any script can read them. This does not prevent XSS from acting, but it prevents token theft and reuse elsewhere.
  • Subresource integrity on third-party scripts, so a compromised CDN cannot silently change what executes.
  • A minimal third-party script inventory. Every included script runs with full origin authority — a tag manager permitting arbitrary script injection is an unmonitored remote code execution path.
  • Origin isolation for user-generated content, serving uploaded files from a separate origin so that an uploaded HTML file cannot execute in the application's origin. For a file-handling product this is the specific control that matters most, and it must be a different origin, not a different path.

The other essentials

Framing controls to prevent clickjacking. CSRF protection where cookie authentication is used. Sensitive data kept out of client storage, since it persists after logout and is readable by any script. And dependency scanning with prompt updates, because a compromised package in the build has the same authority as first-party code and arrives without any injection at all.

The verification that closes the loop

CSP violation reporting, collected and reviewed. It is the only mechanism that tells you an injection attempt happened, and most teams enable the policy without ever reading the reports.