unsafe-eval csp violation

[hokiepokedad2]

Describe the bug?

While attempting to harden our security policies on the client via CSP headers, we noticed the okta-uath-js.umd.js library is using unsafe-eval calls such as Function(). Here is a sample definition of our policy:

<meta http-equiv="Content-Security-Policy"
        content="default-src 'self' 'unsafe-inline'; img-src https://* 'self' data:;">

Notice that we are not using 'unsafe-eval'. Our client site is Angular 12.

What is expected to happen?

Website continues to render with no errors violation our csp policy.

What is the actual behavior?

okta-auth-js.umd.js:2

   Uncaught EvalError: Refused to evaluate a string as JavaScript because 'unsafe-eval' is not an allowed source of script in the following Content Security Policy directive: "default-src 'self' 'unsafe-inline'".

at Function (<anonymous>)
at Object.5666 (okta-auth-js.umd.js:2:134527)
at n (okta-auth-js.umd.js:2:135279)
at Object.7757 (okta-auth-js.umd.js:2:9295)
at n (okta-auth-js.umd.js:2:135279)
at okta-auth-js.umd.js:2:152055
at okta-auth-js.umd.js:2:135961
at okta-auth-js.umd.js:2:222
at okta-auth-js.umd.js:2:81
at Object.69494 (okta-auth-js.umd.js:2:2)

Reproduction Steps?

On a fresh angular app, or even a simple html page with a reference to the okta-auth-js library, specify the following meta tag in the head element:

<meta http-equiv="Content-Security-Policy"
        content="default-src 'self' 'unsafe-inline'; img-src https://* 'self' data:;">

Browse to the site and open the developer tools console. Take note of the error presented.

okta-auth-js.umd.js:2

   Uncaught EvalError: Refused to evaluate a string as JavaScript because 'unsafe-eval' is not an allowed source of script in the following Content Security Policy directive: "default-src 'self' 'unsafe-inline'".

at Function (<anonymous>)
at Object.5666 (okta-auth-js.umd.js:2:134527)
at n (okta-auth-js.umd.js:2:135279)
at Object.7757 (okta-auth-js.umd.js:2:9295)
at n (okta-auth-js.umd.js:2:135279)
at okta-auth-js.umd.js:2:152055
at okta-auth-js.umd.js:2:135961
at okta-auth-js.umd.js:2:222
at okta-auth-js.umd.js:2:81
at Object.69494 (okta-auth-js.umd.js:2:2)

SDK Versions

"@okta/okta-angular": "^5.0.0",
"@okta/okta-auth-js": "6.0",

Execution Environment

MS Edge, Chrome Browsers
Windows 10/Server 2019
Visual Studio 2022 IIS Express or IIS/Kestrel hosting angular app

Additional Information?

No response

[jaredperreault-okta]

@hokiepokedad2 what meta tag are you using?

[hokiepokedad2]

@hokiepokedad2 what meta tag are you using?

Sorry about that. I forgot to enclose the tag in a codeblock. I've updated the description but here it is also:

<meta http-equiv="Content-Security-Policy"
        content="default-src 'self' 'unsafe-inline'; img-src https://* 'self' data:;">

[jaredperreault-okta]

I was able to repro the bug in our sample Angular app, however when I attempted to repro in a non-Angular (React) app I did not get the error or any other CSP violations.

Seems like this might be a problem with Angular itself:

• https://angular.io/guide/security
• Inline <style> elements violates style-src Content Security Policy angular/angular#6361

[hokiepokedad2]

Yes, we actually have 'unsafe-inline' set for style-src also. The meta tag I added above was just a quick and dirty rule. Even specifying 'unsafe-inline' for style-src, I get the 'unsafe-eval' violation:

<meta http-equiv="Content-Security-Policy"
        content="default-src 'self' 'unsafe-inline'; img-src https://* 'self' data:; style-src 'self' 'unsafe-inline';">

If I remove all references of Okta Auth JS from our app, the violation is no longer reported.

[jaredperreault-okta]

Internal Reference: OKTA-475241

[hokiepokedad2]

Hi @jaredperreault-okta - have there been any thoughts intenlrnally on this? Fortunately we have a Middleware component in our dotnet app to block any type of script injections but this still prevents us from using our csp rules to instruct client browsers to block unsafe-eval scripts. For now, we have allowed unsafe-eval but would like to see if theres been any movements on this or if anyone else have observed this behavior?

[jaredperreault-okta]

We do not have a fix for this quite yet, but we believe the issue involves bundle selection. It seems your app is pulling in the umd bundle of auth-js, which includes the syntax your CSP rule doesn't like. Assuming you're using the standard angular build tools, the build is resolving exports.default which points to the umd bundle. In the meantime, if you can find a way to override which bundle is pulled in during build to the es bundle (defined here) it may fix the issue before we release a patch

[jaredperreault-okta]

@hokiepokedad2 Our cjs and umd bundles are generated via babel. Babel pulls in some corejs3 plugins and transforms which includes Facebook's regenerator-runtime, which includes the usage of Function your meta tag is flagging. I was able to confirm my suggestion using Okta's angular sample app

Inside the okta-hosted-login sample, I added the following to extra-webpack-config.js

resolve: {
    alias: {
      // '@okta/okta-auth-js': path.resolve(__dirname, 'node_modules/@okta/okta-auth-js/dist/okta-auth-js.umd.js'),
      '@okta/okta-auth-js': path.resolve(__dirname, 'node_modules/@okta/okta-auth-js/esm/index.js'),
    }
  },

This tells the Angular build process to specifically use the esm bundle instead of the cjs \ umd bundles, which include the aforementioned regenerator-runtime dependency

More Info:

• "The Function constructor is eval" warning from Mozilla Addons Linter facebook/regenerator#475
• CSP unsafe-eval in Web Worker in Chrome Browser which is always strict mode facebook/regenerator#450