SXG files can't be protected by nonce-based CSP

SXG file is valid for 7 days (IIRC), and that file will serve static response header specified inside SXG file. This doesn't align with the concept of nonce-based CSP, where server needs to serve random nonce for every request.

Since SXG might have DOM-based XSS, attacker can just read nonce inside the SXG file and use same nonce in the XSS payload.

We should expose option to service CSP nonce, which is generated by browser when rendering SXG file. Publisher of SXG file can specify <script nonce={}>, where browser will replace {} with randomly generated nonce for every request. This should be safe because SXG file is a static file, so there is no threat for stored or reflected XSS. The only concern is the DOM XSS.

The issue does not name files, tests, or entry points. Start by reviewing the SXG nonce-based CSP proposal and its DOM-XSS concern; done would require an agreed browser and publisher behavior for per-request nonces.