atılanlar için bir karışıklığa neden olacak şekilde, kalıcı ve JavaScript olamayan vektörleri (ActiveX, Java, VBScript, Flash veya HTML betikleri) de dahil edecek şekilde diğer kod enjeksiyonu türlerini de içerecek şekilde genişletilmiştir.

XSS açıklıkları, 1990'lardan beri raporlanmakta ve istismar edilmektedir. Geçmişte etkilenmiş önemli siteler arasında Twitter, Facebook, MySpace, YouTube ve Orkut gibi sosyal medya siteleri bulunmaktadır. Siteler arası betik çalıştırma açıklıkları bu yüzden ara bellek taşması açıklığını geçerek en yaygın şekilde raporlanan güvenlik açıklığı olmuştur. 2007 yılında bazı araştırmacılar, web sitelerinin %68'inin XSS saldırılarına karşı açık olduğunu belirtmiştir.

Siteler arası betik çalıştırma açıklıklarının standartlaştırılmış tek bir sınıflandırması bulunmamaktadır, ancak uzmanların çoğunluğu en azından 2 ayrı sınıfa ayırmaktadır: kalıcı olmayan ve kalıcı. Bazı kaynaklar, geleneksel (sunucu tarafındaki kod kusurlarından kaynaklanan) ve DOM-tabanlı (istemci tarafındaki kod içerisinde) olarak iki ayrı gruba daha ayırmaktadır.

Kalıcı olmayan (veya yansıtılmış) siteler arası betik çalıştırma açıklığı en temel web açıklığıdır. Bu açıklık, web istemcisi tarafından, en yaygın olarak HTTP sorgu parametreleri üzerinden (örn. HTML formlarından), sağlanan veri, kullanıcı için bir sonuç sayfası göstermek ve oluşturmak için sunucu taraflı betikler tarafından düzgün bir şekilde sterilize edilmeden hızlıca kullanıldığında ortaya çıkmaktadır.

HTML dokümanları kontrol ifadelerini, formatlamayı ve gerçek içeriği içeren düz ve seri bir yapıya sahip olduğu için, düzgün bir HTML kodlaması olmadan sayfada yer alan kullanıcının sağladığı geçerlenmemiş veri, markup enjeksiyonuna yol açabilmektedir. Potansiyel bir vektör örneği web sitesi arama motorudur: eğer birisi bir metin için arama yaparsa, arama metni, neyin aratıldığını belirtmek amacıyla hiçbir değişikliğe uğramadan sayfada tekrar gösterilmektedir. Eğer cevap paketi HTML kontrol karakterlerini filtrelemiyorsa veya reddetmiyorsa, bir siteler arası betik çalıştırma zafiyeti de beraberinde gelecektir.

Yansıtılmış bir saldırı, genelde e-posta veya bir web sayfası üzerinden yapılmaktadır. Yem, XSS vektörü içeren ve güvenilir bir siteye işaret eden, masum görünümlü bir URL'dir. Eğer güvenilir site XSS vektörüne karşı korumasızsa, linke tıklanması kurban tarayıcısının enjekte edilen betiği çalıştırmasına yol açmaktadır.

Kalıcı (veya depolanmış) XSS açıklığı, siteler arası betik çalıştırma açıklığının en yıkıcı çeşidir. Saldırgan tarafından sağlanan veri sunucuda saklandığında ve sonrasında diğer kullanıcıların düzenli gezinimi sırasında "normal" sayfa üzerinde kalıcı olarak gösterildiğinde ortaya çıkmaktadır.  Tipik bir örneği, kullanıcıların diğer kullanıcıların okuması için HTML formatında mesajlar göndermesine izin veren çevrimiçi mesajlaşmadır.

Örnek olarak, üyelerin ilgilerini çekebilecek diğer üyeleri bulmak için diğer üyelerin profillerini tarayabildikleri bir randevu sitesini düşünelim. Gizlilik nedeniyle, site herkesin gerçek adını ve e-posta adreslerini gizli tutmaktadır. Bu veriler sunucuda gizli olarak tutulmaktadır. Bir üyenin gerçek adının ve e-posta adresinin tarayıcı üzerinde gözüktüğü tek zaman üye giriş yaptığında olmaktadır ve başka hiçbir kimsenin bilgilerini görememektedirler.

Bir saldırganın, Mallory'nin, siteye katıldığını ve sitede gördüğü insanların gerçek isimlerini öğrenmek istediğini varsayalım. Bunu yapabilmek için, diğer kullanıcıların tarayıcısında kendi profiline baktıklarında çalışacak bir betik yazar. Betik daha sonra bu bilgileri toplayan Mallory'e ait bir sunucuya mesaj gönderir.

Bunu yapabilmek için, "Sizin için ideal ilk randevuyu tanımlayınız" sorusuna Mallory (normal gözükecek) kısa bir cevap verir, ancak cevabının sonuna isimleri ve e-posta adreslerini çalmak için yazdığı betiği ekler. Eğer betik  etiketleri içerisine alınmışsa ekranda gözükmeyecektir. Sonrasında başka bir üye olan Bob'un Mallory'nin profiline baktığını varsayalım. Betik otomatik olarak tarayıcı tarafından çalıştırılacak ve Bob'un gerçek adı ve e-posta adresini doğrudan onun makinesi aracılığıyla çalacaktır.

Kalıcı XSS açıklıkları, saldırganın kötücül betiği bireysel olarak kurbanların hedeflenmesine veya üçüncü parti bir siteyi kullandırtmaya gerek olmadan otomatik olarak çalıştırıldığı için diğer türlere göre çok daha önemlidir. Özellikle sosyal ağ sitelerinde, kod istemci taraflı bir solucan türü oluşturarak hesaplar arasında kendisini yayacak şekilde tasarlanabilmektedir.

Enjeksiyon yöntemleri çok farklı olabilir; bazı durumlarda saldırgan böyle bir açıklığı istismar etmek için doğrudan web uygulaması ile etkileşime geçmeye ihtiyaç duymayabilmektedir. Saldırgan tarafından kontrol edilebilen ve web uygulaması tarafından alınan herhangi bir veri (e-posta, sistem logları, IM vb. üzerinden), enjeksiyon vektörü olabilmektedir.

Tarihsel olarak XSS açıklıkları ilk olarak, tüm veriyi sunucu tarafında işleyen uygulamalarda bulunmaktaydı. Kullanıcı girdisi (XSS vektörleri dahil) sunucuya gönderilmekte ve sonrasında kullanıcıya web sayfası olarak geri gelmekteydi. Geliştirilmiş bir kullanıcı deneyimine olan ihtiyaç, AJAX kullanarak sunucudan ihtiyacı olduğunda veri çeken ve istemci tarafında çalışan bir sunum katmanı mantığına (JavaScript ile yazılabilir) sahip uygulamaların yaygınlaşmasına neden oldu.

JavaScript de kullanıcı girdisini işlediği ve web sayfası içeriğinde gösterdiği için, DOM-tabanlı siteler arası betik çalıştırma açıklığı olarak isimlendirilen yeni bir yansıtılmış XSS sınıfı oluştu. Bir DOM tabanlı XSS saldırısında, kötücül veri web sunucusuna ulaşmamaktadır. Bunun yerine, tamamen istemci tarafında olacak şekide JavaScript kodu tarafından yansıtılmaktadır.

Örnek bir DOM tabanlı XSS açıklığı, 2011 yılında pek çok JQuery eklentisinde bulunan açıklıktır. DOM tabanlı XSS saldırıları için önleme stratejileri, geleneksel XSS önleme yöntemlerine çok benzerdir ancak JavaScript kodu içerisinde uygulanmaktadır ve web sayfaları içerisinde bulunmaktadır (örn. girdi denetimi ve sterilizasyon). Bazı JavaScript çerçeveleri bu ve diğer türdeki saldırılara karşı dahili önlemlere sahiptir — örneğin Angular.js.

Self-XSS, kurbanı kötücül JavaScript kodunu tarayıcısında çalıştırmaya ikna etmeye çalışan ve sosyal mühendisliğe dayanan bir XSS açıklık çeşididir. Sosyal mühendislik yöntemleriyle kullanıcının kod çalıştırmasını sağlamaya dayandığı için teknik olarak bir XSS açıklığı olmasa da, düzgün bir şekilde yapıldığında normal bir XSS açıklığıyla aynı risklere sahip olmaktadır.

Siteler arası betik çalıştırma açıklıklarını istismar etmek isteyen saldırganlar, her bir açıklık sınıfına farklı şekillerde yaklaşmalıdır. Her bir sınıf için özel bir saldırı vektörü burada açıklanacaktır. Aşağıdaki isimler, bilgisayar güvenliğinde yaygın olarak kullanılan Alice-Bob isimlendirmesinden alınan teknik terimlerdir.

Tarayıcı İstismar Çerçeve Yazılımı (Browser Exploitation Framework) web sayfasına ve kullanıcının yerel ortamına saldırmak için kullanılabilmektedir.

Bu saldırıyı engellemek için aşağıdaki birkaç önlem alınabilir:

Bob'un web sitesi yazılımı, script etiketlerini kaldırmalı veya çalışamaz hale getirmek için bir şey yapmalıydı, ancak güvenlik açıklığı zaten yapmamış olmamasından kaynaklanmaktadır.

Bağlamsal çıktı kodlama/çevirimi, XSS saldırılarını durdurmak icing kullanılan birincil savunma mekanizmasıdır. Güvenilmeyen metinlerin HTML dokümanı içerisinde nereye konulacağına bağlı olarak kullanılabilecek HTML varlık çevirimi, JavaScript çevirimi, CSS çevirimi ve URL kodlaması gibi pek çok farklı çevirim yöntemi bulunmaktadır. Zengin veri formatını kullanması gerekmeyen pek çok web uygulaması, basit bir şekilde XSS saldırıları riskini büyük ölçüde ortadan kaldırmak için kodlamayı/çevirimi kullanabilir.

Yaygın olarak tavsiye edilse de, saddle beş XML özel karakteri üzerinde HTML varlık kodlamasının kullanılması pek çok XSS saldırısı vektörünün engellemesinde yetersiz kalmaktadır. Kodlama genelde zor olduğu için, güvenlik için geliştirilmiş kodlama kütüphanelerinin kullanımı genellikle daha kolay bir çözüm olmaktadır.

Web uygulamalarının pen çoğu (örn. formula ve webmail) kullanıcıların belirli bir HTML etiketi setini kullanmalarına izin vermektedir. Kullanıcıdan HTML girdisi (örn. çok) alınırken, çıktı kodlaması (örn. very büyük), kullanıcı girdisi tarayıcı tarafından HTML girdisi olarak yorumlanması gerektiğinden ("çok büyük" şeklinde göstermek yerine "çok büyük" şeklinde göstermesi) yeterli olmamaktadır. will not suffice since the user input needs to be rendered as HTML by the browser (so it shows as "very large", instead of "very large"). Kullanıcıdan HTML girdisi alınırken XSS saldırılarının durdurulabilmesi çok daha karmaşık bir durumdur. Güvenilmeyen HTML girdisi, herhangi bir XSS kodu içermediğinden emin olunabilmesi için bir HTML sterilizasyon motorundan geçmelidir.

Pek çok geçerleme yöntemi, aşağıdaki gibi bazı "riskli" html etiketlerinin kaldırılmasına (kara liste uygulama) dayanmaktadır:Bu yaklaşım ile ilgili pek çok sorun bulunmaktadır. Örneğin, başarılı bir şekilde kullanıldığında XSS saldırısı ile sonuçlanabilecek bazı görünürde zararsız etiketlerin bırakılması.

(aşağıdaki örneğe bakınız) Diğer bir yaygın yöntem ise " ve ' işaretlerinin kullanıcı girdisinden çıkarılmasıdır. Ancak, bu da veri Gizleme (Obfuscation) ile gizlenebileceği için atlatılabilmektedir.

İçerik filtreleme dışında, siteler arası betik çalıştırma önlemleri için başka kesin çözüm getirmeyen yöntemler de yaygın olarak kullanılmaktadır. Bir örneği, çerez tabanlı kullanıcı kimlik doğrulaması yapılırken ilave güvenlik kontrollerinin uygulanmasıdır.  Çoğu web uygulaması bireysel HTTP istekleri arasında kimlik doğrulaması yapabilmek için oturum çerezlerini kullanmaktadır ve istemci taraflı betikler genelde bu çerezlere erişebildiği için basit XSS istismarları bu çerezleri çalabilmektedir. Bu tehditi ortadan kaldırmak için (genel olarak XSS problemini çözmese