Her Frontend Geliştiricisinin Bilmesi Gereken Web Güvenliği Temelleri

Güvenlik bir backend sorunu gibi gelir. Backend; input'u doğrular, kimlik doğrulamasını yönetir, veriyi güvenli saklar. Frontend ise sadece kendisine verileni render eder — değil mi?

Yanlış. En yıkıcı web zafiyetlerinin önemli bir kısmı tamamen frontend üzerinden sömürülür — ve bunları anlamayan bir frontend geliştirici, ne kadar temiz component yazarsa yazsın, projenin zayıf halkası olur.

Güvenlik mühendisi olmana gerek yok. Ama bunları bilmen gerek.

XSS — Cross-Site Scripting

XSS, en yaygın frontend zafiyetidir. Mantık basit: saldırgan sayfanıza zararlı JavaScript enjekte eder ve kullanıcıların tarayıcıları bu kodu çalıştırır.

Bir yorum bölümünün kullanıcı girdisini ham HTML olarak render ettiğini düşünün. Saldırgan, içinde <script> etiketi olan bir yorum bırakır. O sayfayı yükleyen her kullanıcı artık saldırganın kodunu çalıştırır — session cookie'lerini çalabilir, kullanıcıları kimlik avı sitelerine yönlendirebilir veya sessizce onların adına API çağrıları yapabilir.

Frontend kodda nasıl ortaya çıkar:

// Tehlikeli — asla yapma
element.innerHTML = userInput;

// Güvenli
element.textContent = userInput;

Vue ve React gibi modern framework'ler çıktıyı varsayılan olarak escape eder — bu büyük bir yardımdır. Ama Vue'da v-html ya da React'te dangerouslySetInnerHTML kullandığınız an, bu korumayı kasten devre dışı bırakmış olursunuz. Bu kaçış kapıları bir sebeple var — fakat her kullanım bilinçli bir karar olmalı ve input mutlaka önce sanitize edilmeli.

Kullanıcı tarafından üretilen HTML render etmek zorunda kaldığınızda DOMPurify gibi bir kütüphane kullanın.

CSRF — Cross-Site Request Forgery

CSRF, kullanıcının tarayıcısını kandırarak sitenize bilgisi dışında kimlik doğrulamalı bir istek attırır.

Klasik senaryo: kullanıcı bankasına giriş yapmış. Başka bir sekmede zararlı bir siteyi açıyor. O site, bankanın transfer endpoint'ine submit eden gizli bir form içeriyor. Kullanıcı oturum açtığı için tarayıcısı session cookie'sini otomatik gönderiyor. Banka, geçerli kimlik doğrulamalı bir istek görüyor ve işliyor.

Savunma: CSRF token'ları. Sunucu, her oturum için benzersiz ve tahmin edilemeyen bir token üretir. Form'lar ve state değiştiren istekler bu token'ı içermek zorundadır. Zararlı bir üçüncü taraf site bu token'ı bilemeyeceği için, oluşturduğu sahte istekler reddedilir.

Laravel Sanctum gibi bir framework kullanıyorsanız CSRF koruması çoğunlukla built-in gelir — fakat ne yaptığını anlamanız ve frontend'inizin token'ı doğru şekilde gönderdiğinden emin olmanız gerekir.

Ayrıca: SameSite=Strict veya SameSite=Lax ile yapılandırılmış cookie'ler, tarayıcıya cross-origin isteklerde cookie göndermemesini söyleyerek CSRF'i büyük ölçüde önler.

CSP — Content Security Policy

CSP, XSS'e karşı son savunma hattınızdır. Saldırgan bir script tag'i enjekte etmeyi başarsa bile, doğru yapılandırılmış bir CSP onun çalışmasını engelleyebilir.

CSP, tarayıcıya sayfanızda hangi içerik kaynaklarının yüklenebileceğini ve çalıştırılabileceğini söyleyen bir HTTP response header'ıdır.

Content-Security-Policy: default-src 'self'; script-src 'self' https://trusted-cdn.com;

Bu, tarayıcıya der ki: sadece bu origin'den ve bir güvenilir CDN'den gelen script'leri çalıştır. Enjekte edilen bir inline script veya saldırganın sunucusundan yüklenen bir script? Bloklanır.

CSP'yi yapılandırmak karmaşık gibi gelir, çünkü gerçekten karmaşıktır — uygulamanızı kırmadan doğru ayarlamak iterasyon ister. Ama temel bir politika bile politikasız bir uygulamadan dramatik biçimde iyidir. Önce report-only modda (Content-Security-Policy-Report-Only) başlayın; uygulamadan önce nelerin bloklanacağını görün.

HttpOnly ve Secure Cookie'ler

Kimlik doğrulama token'ları saklıyorsanız, nereye sakladığınız çok ama çok önemlidir.

localStorage sayfanızda çalışan herhangi bir JavaScript için erişilebilirdir. Bir XSS saldırısı başarılı olursa ve token localStorage'daysa, gitti demektir. Saldırgan onu aldı.

HttpOnly cookie'lere JavaScript hiç erişemez. Bunlar isteklerle otomatik gönderilir ama document.cookie'den ve her türlü script'ten görünmezdir. Bu XSS riskini ortadan kaldırmaz, ama en değerli hedefi ortadan kaldırır.

Secure cookie'ler sadece HTTPS üzerinden gönderilir. Bu flag olmadan token, güvensiz bir bağlantıda düz metin olarak iletilebilir.

Kombinasyon — HttpOnly; Secure; SameSite=Lax — herhangi bir kimlik doğrulama cookie'sinin temel zeminidir.

Set-Cookie: session=abc123; HttpOnly; Secure; SameSite=Lax

Bu backend tarafından set edilir, ama frontend geliştiricilerin bunu anlaması şart — çünkü token'ları nerede saklayacağına dair mimari karar genellikle full-stack ekibin birlikte verdiği bir karardır.

HTTPS Her Yerde

2026'da bu apaçık olmalı, ama hâlâ internal araçlarda, staging ortamlarında ve küçük projelerde atlanıyor.

HTTPS olmadan her şey düz metindir. Şifreler, token'lar, form verileri, API cevapları — aynı ağdaki herkes tarafından okunabilir. Halka açık Wi-Fi'da bu gerçek ve tetiklenmesi sıradan bir saldırıdır.

HTTPS aynı zamanda service worker'lar, HTTP/2 ve sadece güvenli origin'lerde çalışan bazı güvenlik header'ları gibi özelliklerin de ön koşuludur. HTTPS'siz herhangi bir şey yayına almanın meşru bir nedeni yoktur.

Bağımlılık Zafiyetleri

node_modules klasörünüz sizin yazmadığınız devasa bir saldırı yüzeyidir.

Yüklediğiniz her npm paketi, projenizde çalışan kod demektir. Paketler ele geçirilir. Zararlı sürümler yayınlanır. Bağımlılıkların bağımlılıkları, hiç doğrudan denetlemeyeceğiniz zafiyetler taşır.

Düzenli olarak npm audit çalıştırın. Bağlı olduğunuz bir paketin bilinen zafiyeti olduğunda otomatik uyarı almak için Dependabot veya Snyk gibi araçlar kullanın. Bağımlılıkları güncel tutun — saplantılı değil, ama bir program dahilinde.

event-stream olayı, ua-parser-js ihlali, node-ipc sabotajı — hepsi tedarik zinciri üzerinden gerçekleşti. Gerçek bir saldırı vektörüdür.

Frontend Geliştiricisinin Güvenlik Kontrol Listesi

• Asla sanitize edilmemiş kullanıcı input'unu DOM'a enjekte etme.

• innerHTML, v-html, dangerouslySetInnerHTML kullanmaktan mutlak gerekli olmadıkça kaçın — kullanıyorsan mutlaka sanitize et.

• Kimlik doğrulama token'larını HttpOnly cookie'lerde sakla, localStorage'da değil.

• Backend'inin hangi CSRF korumasını kullandığını anla ve frontend'inin onunla uyumlu çalıştığından emin ol.

• Content Security Policy yapılandır.

• Her yerde HTTPS kullan, staging dahil.

• npm audit çalıştır ve bağımlılıkları güncel tut.

• Üçüncü taraf script'lerinin neye erişebildiğini bil — her analytics, chat ve reklam script'i sayfaya tam erişimle çalışır.

Güvenlik, Kalitenin Bir Parçasıdır

Güvenlik, dikkatsiz frontend kodu koruyan bir backend hendeği değildir. Tarayıcı bir yürütme ortamıdır ve onun içinde çalışan her şey sizin sorumluluğunuzdur.

Sızma testi uzmanı olmana gerek yok. Bir saldırının nasıl çalıştığını, kodunun bir açık yarattığını fark edip yayına çıkmadan kapatabilecek kadar anlamana ihtiyacın var.

Bunu ciddiye alan geliştiriciler kalıcı şeyler kurar. Almayanların eninde sonunda çok kötü bir günü olur.

Güvenlik kalitenin bir parçasıdır — ondan ayrı değil.

Arekan'da frontend uygulamalarını güvenlik ilk günden gömülü olacak şekilde inşa ediyoruz. CSP yapılandırmasından güvenli kimlik doğrulama akışlarına kadar bunu sonradan eklenecek bir iş olarak görmüyoruz.

Güvenebileceğin bir şey inşa et.

Yazar: Salih Usmanov, Frontend Engineer.