nonce generated in blade file is different from that in response header

[jd5am]

I have created a policy that extends the basic policy and in there I specify the following directives:

            ->addDirective(Directive::IMG, 'd0.awsstatic.com')
            ->addDirective(Directive::DEFAULT, 's3.eu-west-2.amazonaws.com')
            ->addDirective(Directive::STYLE, 's3.eu-west-2.amazonaws.com')
            ->addDirective(Directive::IMG, 's3.eu-west-2.amazonaws.com')
            ->addDirective(Directive::MEDIA, 's3.eu-west-2.amazonaws.com')
            ->addDirective(Directive::SCRIPT, 's3.eu-west-2.amazonaws.com')
            ->addDirective(Directive::STYLE, 'maxcdn.bootstrapcdn.com')
            ->addDirective(Directive::SCRIPT, 'ajax.googleapis.com')
            ->addDirective(Directive::SCRIPT, 'cdnjs.cloudflare.com');

Also, I have in-line CSS in my blade files e.g.

<div class="margin-top-15 margin-bottom-15" style="color:#fbb858;">

AND (in another blade file)

<style nonce="{{ csp_nonce() }}">
    .modal-content-color {
        color: #fbb858;
    }
</style>

TWO issues I have

1. How do I specify the nonce in the inline-block of my div attribute?
2. I get a different nonce in my inline-style when compared to the response header. Therefore, I get the following error in my console log:

Refused to apply inline style because it violates the following Content Security Policy directive: "style-src 'self' 'nonce-JtEJ5TaHmHaA6zWodDAjL6PeLSqcz1jx' s3.eu-west-2.amazonaws.com maxcdn.bootstrapcdn.com". Either the 'unsafe-inline' keyword, a hash ('sha256-QUfDAksSVn8Wxl3zqrHA+td64lo9rOocO2iUohUW9uk='), or a nonce ('nonce-...') is required to enable inline execution.

**### In my inline style, I see nonce:

    <script nonce="MGM2YTliYWY1MGMzNmQ1ZA==">

Whereas in my response header I see nonce: JtEJ5TaHmHaA6zWodDAjL6PeLSqcz1jx**

What am I missing?

Thanks for your help.

[jd5am]

Just an update to one of my two issues -- seems that reinstalling the package did the trick. I now get the same nonce in both the response header as well as the inline-styles.

But, I'm a little unsure how to address inline-blocks, e.g.
<div class="margin-top-15 margin-bottom-15" style="color:#fbb858;">

I think it has something to do with specifying unsafe-inline somewhere -- but where exactly?
The alternative (and longwinded way) would be to add it to the stylesheet and use a nonce there (as mentioned, this now works). But unfortunately there are so many places where this app uses inline-blocks....

Please help someone?

Thanks.

[jhjvandenbroek]

I believe nonces can only be added to <style> and <script> tags. True inline styling like in the div in your post can't be whitelisted and must indeed be refactored into a stylesheet

[jd5am]

Thanks @jhjvandenbroek! Yes, this is what I think I'll have to now do.

We have encountered a couple more issues, however:

issue 1) I still see "Refused to apply inline style because it violates the following CSP directive". It then points to a jquery.min.js plugin file that is hosted on our S3 bucket....with the S3 domain already being listed as a directive! Any ideas why? I mean, if the S3 domain is listed as a directive (for scripts), surely I should now see this error? I am posting a screenshot to illustrate the problem:

issue 2) We have an external JS file where we have specified nonce="{{ csp_nonce() }} within the <script> tag (see attached screenshot). However, it appears that the nonce is not being generated and I see the actual code itself.

[jd5am]

for issue 2: Further testing seems to indicate when I call the js script directly within the blade file the nonce value is generated. However, when placed inside an includes file, it does not!? How odd.

Again -- it only happens for SOME js include files. Other js include files seem to generate the nonce!

Anyone else had something similar happen to them?

[jd5am]

Both issues now fixed - wasn't an issue with the package rather with the application - whew!

issue 1: the blade file didn't have the .blade.php extension (it only had the .php extension)
issue 2: instead of self-hosting jquery.min.js, we call it from the code.jquery.com CDN.