mkwst@, Could you please confirm this issue is similar to 654557/627762.
Please confirm.
Thanks.

Yes, I confirm it's similar to 654557
I mentioned it in my original message:

> Might be related to https://bugs.chromium.org/p/chromium/issues/detail?id=654557

Thank you for providing more feedback. Adding requester "jmukthavaram@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Seems this issue is similar to #627762, hence merging this issue.
Please feel free to Undupe if is not similar.

Thanks..

Re-opening, the nonce attribute of <link rel=preload> is still not respected.

Actually, CSP violation is reported but script resource is preloaded.

Here's what happening:

1. HTML preload scanner scans the <link rel=preload> tag. PreloadScanner knows about nonce, so it creates a PreloadRequest with nonce parameter set.
2. When <link> is parsed and attached to the DOM, LinkLoader creates another request, without setting the nonce parameter.
3. Usually, request of 2. is merged to the request of 1. at ResourceFetcher (in MatchPreload()), but in this case, request of 2 is blocked by CSP before it's merged.

As a result, script is preloaded by 1. but CSP violation is reported by 2. This is very confusing. Also, dynamically created link rel=preload element doesn't work.

We should teach LinkLoader about the nonce atteribute. I'll create a patch.

I think it's significantly more dev friendly to let developers preload the script without a nonce and verify nonces at use time. Is there a particular security issue with that approach?

I agree current situation is confusing though. I'd prefer to ignore nonces for preloads at the CSP level. Mike, WDYT?

Ignoring nonces for preloads completely would make it ~impossible to defend against data exfiltration. Without thinking about it too hard, teaching `LinkLoader` about the attribute seems like a better way to approach the problem. Why would you prefer the opposite, Yoav?

Oops, didn't think about data exfiltration (is `prefetch` bound to a CSP policy? I forget...)

The reason for my preference is dev ergonomics (so not forcing devs to add the nonce everywhere if it's not needed). If there's an actual security/leak concern here, then I retract my objections.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/dc84d178bb099bb55a6ef8948a642fe1194bf956

commit dc84d178bb099bb55a6ef8948a642fe1194bf956
Author: Kunihiko Sakamoto <ksakamoto@chromium.org>
Date: Wed Sep 27 09:46:07 2017

Teach LinkLoader about the 'nonce' attribute

This patch makes LinkLoader propagate the 'nonce' parameter from
link rel=preload, both from element and header. This matches the
standard [1], and consistent with HTMLPreloadScanner's behavior.

[1] https://html.spec.whatwg.org/#obtaining-a-resource-from-a-link-element

Bug:  702612 
Change-Id: Ib28e88c49754d427abe96c3bf0145621132592a7
Reviewed-on: https://chromium-review.googlesource.com/676769
Reviewed-by: Yoav Weiss <yoav@yoav.ws>
Commit-Queue: Kunihiko Sakamoto <ksakamoto@chromium.org>
Cr-Commit-Position: refs/heads/master@{#504613}
[add] https://crrev.com/dc84d178bb099bb55a6ef8948a642fe1194bf956/third_party/WebKit/LayoutTests/external/wpt/preload/dynamic-adding-preload-nonce.html
[add] https://crrev.com/dc84d178bb099bb55a6ef8948a642fe1194bf956/third_party/WebKit/LayoutTests/external/wpt/preload/dynamic-adding-preload-nonce.html.headers
[add] https://crrev.com/dc84d178bb099bb55a6ef8948a642fe1194bf956/third_party/WebKit/LayoutTests/external/wpt/preload/link-header-preload-nonce.html
[add] https://crrev.com/dc84d178bb099bb55a6ef8948a642fe1194bf956/third_party/WebKit/LayoutTests/external/wpt/preload/link-header-preload-nonce.html.headers
[modify] https://crrev.com/dc84d178bb099bb55a6ef8948a642fe1194bf956/third_party/WebKit/Source/core/html/HTMLLinkElement.cpp
[modify] https://crrev.com/dc84d178bb099bb55a6ef8948a642fe1194bf956/third_party/WebKit/Source/core/html/HTMLLinkElement.h
[modify] https://crrev.com/dc84d178bb099bb55a6ef8948a642fe1194bf956/third_party/WebKit/Source/core/html/LinkStyle.cpp
[modify] https://crrev.com/dc84d178bb099bb55a6ef8948a642fe1194bf956/third_party/WebKit/Source/core/loader/LinkLoader.cpp
[modify] https://crrev.com/dc84d178bb099bb55a6ef8948a642fe1194bf956/third_party/WebKit/Source/core/loader/LinkLoader.h
[modify] https://crrev.com/dc84d178bb099bb55a6ef8948a642fe1194bf956/third_party/WebKit/Source/core/loader/LinkLoaderTest.cpp
[modify] https://crrev.com/dc84d178bb099bb55a6ef8948a642fe1194bf956/third_party/WebKit/Source/platform/loader/LinkHeader.cpp
[modify] https://crrev.com/dc84d178bb099bb55a6ef8948a642fe1194bf956/third_party/WebKit/Source/platform/loader/LinkHeader.h