Re: [OAUTH-WG] Feedback on OAuth for browser-based Apps

[David Waite <[e-mail]>]

> On Jul 24, 2019, at 3:03 PM, Aaron Parecki <[e-mail]> wrote:
> 
> On Mon, Jul 22, 2019 at 2:14 AM Dominick Baier
> <[e-mail]> wrote:
> 
<snip>

>> I would rather say that ANY JS app should use CSP to lock down the browser features to a minimal attack surface. In addition, if refresh or access tokens are involved - further settings like disabling inline scripting (unsafe inline) and eval should be disabled.
> 
> I'm not sure what to do with this suggestion. It feels like a blanket
> recommendation of enabling CSP will likely be ignored since it's too
> broad, and recommending disabling inline scripts is overreaching
> unless backed up by a specific threat it's protecting against. Did you
> have a particular threat in mind?

I would say that browser applications should take measures to harden their applications again code injection and arbitrary code execution. Examples include eliminating inline script (and limiting embeddable objects as much as possible) via CSP, and versioning third party resources via techniques like subresource integrity.  Mechanisms such as augmenting the codebase to make sure all appropriate user input, data storage, and output properly sanitize data may be used - although they may be more expensive to implement and audit.

The AS should likewise take into account an application’s overall security posture when deciding appropriate policies around delegated authorization scopes and token lifetimes.

Best current practices include turning the screws tightly around CSP. But it is (theoretically) possible to accomplish the same with brute-force sanitization, which has been made simpler with framework support. It is still ultimately the AS job to decide which clients have which capabilities.

-DW