CSP — data: in the script allow-list

Content-Security-Policy

This site ships a CSP. Workflow: read the policy in DevTools → Network → reload → the document request → Response Headers. Then attempt payloads and let the console's red violations name the directive that blocks each one. That list is your map.

this page's policy (also verbatim in the response headers) 
Content-Security-Policy: script-src 'self' https://cdn.stuxnet.pro data:; object-src 'none'; img-src 'self' data:
attachment preview attachment preview

The preview renders straight from a data: URI — that feature is why the policy carries a data: allowance (img-src, and unfortunately also script-src).Sites rarely explain why they allow things; functionality needed it, and the policy grew from there.

Method — read the policy, then pair it
  1. Baseline: <script>alert(1)</script> → dead. Console: inline execution needs 'unsafe-inline' and this policy doesn't grant it.
  2. Try the hunch the data: allowance suggests: serve HTML inside an object — <object data="data:text/html;base64,…"></object> → dead. Console blames object-src: that directive is fully closed.
  3. The pairing rule: every tag answers to its own directive — script ↔ script-src, object ↔ object-src, image ↔ img-src. You don't pick the tag first, you pick the allowed directive first and the tag follows.
  4. data: lives in script-src here. So the same data: idea — streamed, encoded HTML/JS — works when delivered through the element that directive governs: <script src="data:…">.
  5. Why does script-src allow data: at all? The attachment preview above needs data: URIs, and the policy grew from there. Allowances born from features are the holes — you don't control why sites allow things, you only control what you do with the allowance.
  6. No ruleset on this page's business logic — the only judge is the policy string above. Colliding with it head-on fails; finding the generous directive wins.
Spoiler — the hunch that dies (and why it's still the right hunch) 
<object data="data:text/html;base64,PHNjcmlwdD5hbGVydCgxKTwvc2NyaXB0Pg=="></object>

Base64 inside is <script>alert(1)</script>. The console refuses it naming object-src 'none'. Right idea, wrong door — objects are simply not allowed here.

Spoiler — the payload that fires 
<script src="data:text/javascript,alert(1)"></script>
<script src="data:text/javascript;base64,YWxlcnQoMSk="></script>

Same serve-it-as-data move, now through the allowed directive: script-src lists data:, so a script tag may load its code straight from a data: URI — plain or base64. On real targets you may not have a script tag but another element — hunt the same allowance in ITS directive and pair the element you do control.