Frontend Uygulamalarında Güvenlik Ağırlıklı Geliştirme Süreci

Frontend güvenliği, uygulama bittikten sonra birkaç güvenlik aracı çalıştırıp onay vermekten çok daha geniş bir mühendislik konusudur. Tarayıcıda çalışan kod; oturum bilgileri, API yanıtları, kullanıcı girdileri, üçüncü taraf scriptleri ve farklı origin'lerle sürekli iletişim kurar. Bu nedenle küçük görünen bir frontend kararı XSS, veri sızıntısı, yetkisiz işlem veya supply-chain riski oluşturabilir. On yılı aşan geliştirme deneyimimde en güvenilir sonuçları, güvenliği ayrı bir kontrol aşaması olarak değil gereksinimden production izlemeye kadar bütün yaşam döngüsüne dağıtan ekiplerde gördüm. Bu rehber, Frontend Uygulamalarında Güvenlik Ağırlıklı Geliştirme Süreci oluşturmak isteyen ekipler için threat modeling, XSS savunması, CSP, session güvenliği, dependency kontrolleri, CI/CD güvenlik kapıları ve incident response konularını tek bir çalışma modeli altında ele alıyor.

Frontend Güvenliği Nedir ve Neden Geliştirme Sürecinin Parçası Olmalıdır?

Frontend güvenliği, tarayıcıya gönderilen kodun, kullanıcı verisinin ve uygulamanın backend ile kurduğu iletişimin kötüye kullanım risklerini azaltmayı amaçlar. Bu alan yalnızca JavaScript dosyalarında açık aramakla sınırlı değildir. Authentication akışı, cookie politikası, DOM'a veri yazma yöntemi, iframe izinleri, third-party script seçimi ve build pipeline aynı güvenlik yüzeyinin parçalarıdır. Bir risk ne kadar erken bulunursa architecture değişikliği veya kod düzeltmesi o kadar düşük maliyetle yapılabilir. Bu nedenle güvenli frontend geliştirme, tasarım kararlarından production monitoring'e kadar kesintisiz bir süreç olarak ele alınmalıdır.

Frontend Artık Sadece Bir UI Katmanı Değildir

Modern frontend uygulamaları yalnızca backend'den gelen HTML'i görselleştiren ince bir katman değildir. SPA ve server-rendered uygulamalar authentication state yönetebilir, ödeme akışları başlatabilir, hassas API sonuçlarını işleyebilir ve third-party SDK'larla doğrudan iletişim kurabilir. Browser tarafında feature flag, telemetry, dosya yükleme, encryption helper ve cross-origin messaging gibi görevler de bulunabilir. Bu yetenekler arttıkça frontend'in saldırı yüzeyi de genişler. Güvenlik modeli component tasarımı kadar network, browser policy ve dependency davranışlarını da kapsamalıdır.

Tarayıcı Neden Güvenilmeyen Bir Ortam Kabul Edilmelidir?

Kullanıcının tarayıcısına gönderilen JavaScript, HTML ve configuration kullanıcı tarafından görülebilir ve değiştirilebilir. DevTools üzerinden request oluşturmak, client state'i değiştirmek veya route guard'ı atlamak mümkündür. Bu nedenle frontend tarafından gönderilen role, fiyat, izin veya kullanıcı kimliği backend açısından güvenilir veri kabul edilmemelidir. Kullanıcının cihazında saklanan veriler de XSS, zararlı extension veya fiziksel cihaz erişimi gibi risklerle karşılaşabilir. Frontend güvenlik kontrolleri kullanıcı deneyimini korur ancak nihai authorization ve hassas veri doğrulaması güvenilir server tarafında yapılmalıdır.

Security by Design ve Shift Left Security

Security by Design, güvenlik gereksinimlerinin ürün tasarımının başlangıcında ele alınmasını ifade eder. Shift Left Security ise güvenlik kontrolünü geliştirme döngüsünün mümkün olduğunca erken aşamalarına taşır. Threat model tasarım yapılırken, lint ve SAST kod yazılırken, dependency kontrolü pull request sırasında çalıştırılabilir. Böylece production'a yakın aşamada bulunan büyük architecture problemleri azalır. Güvenliği erkene almak güvenlik ekibinin sorumluluğunu geliştiricilere devretmek değil, ekiplerin aynı risk modelini birlikte kullanmasını sağlamaktır.

Güvenliği Sonradan Eklemek Neden Yeterli Değildir?

Uygulama tamamlandıktan sonra yalnızca penetration test yapmak structural tasarım problemlerini pahalı hale getirir. Örneğin bütün authentication modeli browser JavaScript'in eriştiği uzun ömürlü token üzerine kurulmuşsa küçük patch yerine mimari değişiklik gerekebilir. Third-party script envanteri hiç tutulmamışsa hangi kodun production'da çalıştığını belirlemek bile zaman alır. CSP sonradan eklendiğinde yıllardır kullanılan inline script alışkanlıkları enforcement'a geçişi zorlaştırabilir. Erken security requirement bu tür borçların oluşmasını önemli ölçüde azaltır.

Güvenli Frontend Geliştirme Yaşam Döngüsü Nasıl Oluşturulur?

Güvenli yaşam döngüsü gereksinim, tasarım, implementasyon, verification, release ve operasyon aşamalarını birbirine bağlar. Her aşamanın kendi security çıktısı bulunmalıdır. Gereksinimde acceptance criteria, tasarımda threat model, implementasyonda secure coding kuralları ve CI aşamasında otomatik kontroller oluşturulabilir. Production monitoring ise uygulamanın gerçek çalışma ortamındaki ihlalleri ve dependency değişikliklerini takip eder. Bulunan her incident veya hata sonraki feature tasarımına geri beslenerek güvenlik standardını zaman içinde geliştirir.

Gereksinim Aşaması

Feature geliştirilmeden önce hangi verinin işlendiği ve hangi kullanıcıların hangi işlemleri yapabileceği belirlenmelidir. Authentication, authorization ve data privacy beklentileri user story'nin dışında bırakılmamalıdır. Third-party entegrasyon, dosya yükleme veya cross-origin communication varsa risk daha tasarım başlamadan görünür hale getirilmelidir. Security acceptance criteria test edilebilir biçimde yazılmalıdır. “Güvenli olacak” gibi genel ifadeler yerine cookie politikası, authorization davranışı ve loglanmayacak veriler açıkça belirtilmelidir.

Tasarım Aşaması

Tasarım aşamasında data flow ve trust boundary'ler çıkarılır. Kullanıcı girdisinin hangi API'ye gittiği, hangi component'te render edildiği ve hangi third-party sistemlerle paylaşıldığı görünür hale gelir. Threat modeling olası misuse ve abuse senaryolarını erken ortaya çıkarır. Authentication modelinde token'ın browser'a gelip gelmeyeceği gibi temel kararlar bu aşamada alınmalıdır. Güvenlik maliyeti architecture çizimi üzerinde değişiklik yapmak production kodunu yeniden yazmaktan çok daha düşüktür.

Implementasyon Aşaması

Implementasyon aşamasında ekip güvenli varsayılan API ve component'leri kullanmalıdır. Kullanıcı kontrollü content doğrudan HTML sink'lerine gönderilmemeli, gerekli rich HTML uygun sanitization katmanından geçmelidir. Authentication helper, HTTP client ve postMessage wrapper gibi hassas noktalar merkezi modüllerde tutulabilir. Yeni dependency eklenirken package geçmişi ve bakım durumu değerlendirilmelidir. Code review checklist aynı kontrollerin her pull request'te tekrar uygulanmasını sağlar.

Verification ve Testing Aşaması

Verification yalnızca unit testlerin geçmesini kontrol etmek değildir. SAST, SCA, secret scanning ve security-focused integration testleri farklı risk sınıflarını değerlendirir. Authentication regression, CSP davranışı ve safe rendering gibi kritik senaryolar otomatikleştirilebilir. DAST gerçek çalışan uygulamada ek güvenlik sinyali sağlar. Yüksek riskli feature'lar için manuel security review otomasyonun kapsamadığı business logic problemlerini inceler.

Release ve Deployment Aşaması

Release aşamasında development ortamında doğru olan security configuration'ın production'a gerçekten taşındığı doğrulanmalıdır. CSP header, HSTS, cookie attribute'ları ve environment variable configuration bu kontroller arasındadır. Public source map, debug endpoint veya test credential yanlışlıkla deployment artifact içinde kalmamalıdır. Third-party script listesi release öncesi mevcut baseline ile karşılaştırılabilir. Security gate yalnızca vulnerability scanner sonucuna değil configuration ve deployment integrity'sine de bakmalıdır.

Operasyon ve Sürekli İzleme

Production ortamında dependency vulnerability, CSP violation ve client error telemetry sürekli izlenebilir. Log ve error report içinde token, kişisel veri veya hassas request body bulunmamalıdır. Third-party script source değişiklikleri takip edilmelidir. Critical vulnerability yayınlandığında etkilenen dependency'nin hangi uygulamalarda bulunduğu hızlıca tespit edilebilmelidir. Monitoring sadece alarm üretmemeli, incident owner ve remediation süreciyle bağlantılı olmalıdır.

Güvenlik Geri Bildirim Döngüsü

Bulunan her güvenlik problemi yalnızca kapatılacak tekil ticket olarak görülmemelidir. Aynı hata tekrar oluşabiliyorsa lint kuralı, test helper veya design system değişikliğiyle sistematik biçimde engellenebilir. Incident sonrası threat model güncellenebilir. Code review checklist yeni öğrenilen risk pattern'ini kapsayabilir. Böylece ekip her problemden kalıcı process ve tooling iyileştirmesi çıkarır.

Gereksinim Aşamasında Frontend Güvenliği

Frontend güvenlik borcunun önemli bölümü requirement dokümanında güvenlikle ilgili beklentilerin hiç yazılmamasından oluşur. Developer feature'ı business requirement'a göre doğru geliştirir ancak session timeout, data exposure veya authorization beklentisini tahmin etmek zorunda kalır. Security requirement product owner, frontend, backend ve güvenlik sorumluları arasında ortak kontrat oluşturur. Gereksinim mümkün olduğunca test edilebilir olmalıdır. Hassas veri ve trust boundary daha ilk refinement toplantısında konuşulduğunda sonraki architecture kararları daha sağlam hale gelir.

Security Requirement Nasıl Yazılır?

İyi security requirement belirli bir risk ve doğrulanabilir beklenen davranış tanımlar. “Sistem güvenli olmalıdır” ifadesi test yazmak için yeterli değildir. Bunun yerine “oturum cookie'si JavaScript tarafından okunamamalıdır” veya “yetkisiz kullanıcı API kaynağına doğrudan request gönderdiğinde 403 almalıdır” gibi net kriterler kullanılabilir. Requirement teknik solution'ı gereksiz yere kilitlemeden güvenlik sonucunu tarif etmelidir. İlgili risk değiştiğinde requirement da versionlanmalı ve test kapsamı güncellenmelidir.

Authentication Gereksinimleri

Authentication requirement kullanıcı kimliğinin nasıl doğrulandığını ve session'ın hangi koşullarda sonlandığını açıklar. Login, logout, session expiration ve yeniden authentication gerektiren kritik işlemler belirlenebilir. Browser'ın hangi credential bilgisine erişebileceği architecture kararının parçasıdır. MFA veya step-up authentication ihtiyacı varsa yalnızca backend değil frontend flow da bunu desteklemelidir. Authentication error mesajları gereksiz account bilgisi sızdırmamalıdır.

Authorization Gereksinimleri

Authorization requirement hangi rol veya attribute'un hangi kaynak ve işlemlere erişebildiğini tanımlar. Frontend yalnızca uygun UI'ı gösterebilir ancak gerçek izin kontrolünün backend'de yapılması requirement içinde açıkça belirtilmelidir. Direct API request ile hidden button'ın aynı policy'ye tabi olduğu doğrulanmalıdır. Role değişikliği session sırasında gerçekleşebiliyorsa stale frontend state yönetimi planlanmalıdır. Yetkisiz response frontend'de güvenli ve anlaşılır biçimde ele alınmalıdır.

Veri Gizliliği Gereksinimleri

Hangi verilerin hassas olduğu ve browser'da ne kadar süre tutulabileceği belirlenmelidir. Local cache, analytics event ve error monitoring payload'ları bu kapsamda değerlendirilmelidir. Kişisel veya hassas veri URL query string'e konmamalıdır. Browser history, referrer ve log mekanizmaları bu veriyi istemeden taşıyabilir. Data minimization gereksiz bilginin frontend'e hiç gönderilmemesini hedeflemelidir.

Browser Security Gereksinimleri

CSP, cookie attribute'ları, frame policy ve HTTPS gibi browser seviyesindeki güvenlik beklentileri requirement içinde tanımlanabilir. Uygulamanın başka origin tarafından frame edilmesine gerek yoksa bunun açıkça engellenmesi beklenebilir. Third-party scriptlerin hangi origin'lerden yüklenebileceği belirlenebilir. Cross-origin API iletişiminin allowlist'i architecture ile uyumlu tutulmalıdır. Browser support policy security feature seçimlerini etkilediği için requirement ile birlikte ele alınmalıdır.

User Story'lere Güvenlik Acceptance Criteria Eklemek

Security acceptance criteria feature'ın tamamlanma koşullarını somutlaştırır. Rich text gösteren feature için “kullanıcı kontrollü HTML sanitize edilmeden DOM'a yazılmamalıdır” kriteri eklenebilir. Admin route için frontend görünürlüğünün yanında backend authorization test edilmesi şart koşulabilir. Third-party widget için CSP ve sandbox requirement yazılabilir. Acceptance criteria automated veya manuel test evidence ile kapatılmalıdır.

Security Definition of Done Belirlemek

Definition of Done bütün feature'lara uygulanacak minimum güvenlik standardını oluşturur. Yeni dependency review, threat model kontrolü ve security test sonucu bu listede bulunabilir. Her küçük CSS değişikliğinde full threat model gerekli olmayabilir, bu nedenle risk bazlı trigger tanımlanmalıdır. Authentication, payment veya user-generated content değişiklikleri daha yüksek review seviyesi gerektirebilir. Standard ekip tarafından kolay ulaşılabilir ve kısa olmalıdır.

Hassas Veri Sınıflandırması Yapmak

Frontend hangi veriyi hassas kabul edeceğini bilmeden doğru storage ve logging kararı veremez. Public, internal, confidential ve restricted gibi sınıflar kullanılabilir. Token, kimlik bilgisi ve ödeme verisi yüksek koruma gerektirir. Browser'a gönderilmesi gerekmeyen restricted data API response'tan tamamen çıkarılmalıdır. Data classification analytics, cache ve error monitoring tasarımına da yön verir.

Threat Modeling ile Frontend Risklerini Tasarım Aşamasında Bulmak

Threat modeling saldırı gerçekleşmeden önce uygulamanın nereden ve nasıl kötüye kullanılabileceğini sistematik biçimde düşünmeyi sağlar. Amaç gelecekteki bütün saldırıları tahmin etmek değildir. Kritik data flow, trust boundary ve attack surface görünür hale getirilerek riskli tasarım kararları erken bulunur. Frontend açısından browser, API, third-party script, iframe ve user-controlled content önemli sınırlar oluşturur. Model feature değiştikçe yaşayan doküman olarak güncellenmelidir.

Threat Modeling Nedir?

Threat modeling sistemin varlıklarını, veri akışını, güven sınırlarını ve olası tehditleri analiz eden tasarım çalışmasıdır. Ekip önce neyi korumaya çalıştığını belirler. Ardından saldırganın hangi input, origin veya dependency üzerinden sisteme etki edebileceği değerlendirilir. Riskler olasılık ve etkiye göre önceliklendirilebilir. Sonuç yalnızca diyagram değil, uygulanabilir security requirement ve test case üretmelidir.

Frontend Data Flow Diagram Oluşturma

Data Flow Diagram browser'ın hangi backend ve third-party servislerle iletişim kurduğunu gösterir. Kullanıcı girdisinin formdan API'ye, response'tan DOM'a nasıl geçtiği işaretlenebilir. Authentication cookie veya token'ın hangi bileşenlerden geçtiği ayrıca belirtilmelidir. postMessage, iframe ve WebSocket gibi klasik request dışı kanallar unutulmamalıdır. Diyagram sade tutulmalı ve riskli sınırları görünür hale getirmelidir.

Trust Boundary'leri Belirleme

Trust boundary farklı güven seviyelerine sahip iki sistem veya context arasındaki geçiştir. Browser ile backend arasındaki request bunun klasik örneğidir. Third-party JavaScript aynı page origin'inde çalıştığında beklenenden yüksek yetkiye sahip olabilir. Cross-origin iframe ayrı security context oluştursa bile messaging yanlış tasarlanırsa yeni risk doğar. Her sınırda hangi verinin doğrulandığı ve hangi identity bilgisinin güvenilir kabul edildiği yazılmalıdır.

Browser ile Backend Arasındaki Sınır

Backend browser'dan gelen hiçbir authorization bilgisini yalnızca client kontrolüne dayanarak kabul etmemelidir. Request body, query ve header kullanıcı tarafından değiştirilebilir. Frontend validation kullanıcı deneyimi sağlar ancak server validation'ın yerini tutmaz. API her request'te gerçek session veya token üzerinden kullanıcı yetkisini doğrulamalıdır. Response da frontend tarafından beklenen schema'ya göre kontrollü biçimde işlenebilir.

Frontend ile Third-Party Script Arasındaki Sınır

Sayfanızın origin'inde çalışan third-party JavaScript çoğu zaman DOM ve JavaScript-accessible storage'a sizin kodunuzla benzer erişime sahip olur. Bu nedenle script eklemek yalnızca network dependency eklemek değildir. Vendor compromise veya yanlış configuration hassas veriye erişim riski oluşturabilir. CSP ve SRI belirli senaryolarda ek savunma sağlar. En güçlü kontrol gerçekten gerekmeyen third-party script'i hiç yüklememektir.

iframe ve Cross-Origin Sınırları

Cross-origin iframe same-origin policy sayesinde parent DOM'a doğrudan erişemez, ancak postMessage gibi kontrollü iletişim kanalları kullanılabilir. Sandbox iframe capability'lerini daha da sınırlandırabilir. Aynı origin iframe'e hem script hem same-origin izni vermek sandbox etkisini azaltabilir. Message alıcıları origin ve message schema doğrulaması yapmalıdır. Cross-origin sınırı otomatik olarak bütün business logic risklerini çözmez.

STRIDE ile Frontend Threat Modeling

STRIDE tehditleri Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service ve Elevation of Privilege başlıklarıyla düşünmeye yardımcı olur. Frontend'de spoofing sahte authentication state, tampering client state değişikliği ve information disclosure hassas API response örnekleriyle ele alınabilir. Elevation of privilege yalnızca hidden admin route üzerinden düşünülmemeli, backend authorization ile birlikte incelenmelidir. STRIDE checklist ekiplerin threat model toplantısında aynı soru setini kullanmasını sağlar. Her kategori bütün feature'larda eşit risk taşımayacağı için sonuç risk bazlı değerlendirilmelidir.

Attack Surface Analizi

Attack surface uygulamanın dışarıdan etkileşime açık noktalarının toplamıdır. Form inputs, URL parameters, DOM sinks, third-party scripts, API endpoints ve browser messaging kanalları frontend için temel örneklerdir. Yeni dependency veya widget attack surface'i artırabilir. Kullanılmayan route, script ve legacy API kaldırıldığında güvenlik yüzeyi küçülür. Inventory bu nedenle security çalışmasının önemli parçasıdır.

Her Yeni Feature'da Threat Model Güncellemek

Her CSS veya text değişikliği tam threat modeling toplantısı gerektirmez. Yeni trust boundary, authentication akışı, user-generated content veya third-party integration eklendiğinde model mutlaka gözden geçirilmelidir. Pull request template threat model update gerekip gerekmediğini sorabilir. Diyagram değişmediyse kısa gerekçe yeterli olabilir. Modelin code repository yakınında tutulması güncelliğini artırır.

Frontend Uygulamalarındaki Temel Güvenlik Riskleri

Frontend risklerinin önemli bölümü kullanıcı kontrollü verinin yanlış yorumlanması, browser credential davranışının yanlış anlaşılması ve fazla güven verilen third-party code çevresinde toplanır. XSS halen client-side güvenliğin merkezindeki risklerden biridir. CSRF cookie tabanlı authentication kullanan uygulamalarda ayrıca değerlendirilmelidir. Supply-chain ve cross-origin communication modern uygulamalarda daha fazla önem taşır. Riskleri isim olarak bilmek yeterli değildir ve her riskin uygulamanızdaki gerçek data flow ile ilişkilendirilmesi gerekir.

Cross-Site Scripting (XSS)

XSS saldırganın kontrol ettiği içeriğin browser tarafından script veya executable markup olarak yorumlanmasına yol açar. Etki session işlemlerinin kötüye kullanılması, kullanıcı adına request gönderme veya hassas verinin okunması olabilir. Modern framework'ler default escaping ile birçok yaygın problemi azaltır ancak raw HTML escape hatch'leri riski geri getirir. Output encoding ve sanitization farklı context'lerde doğru kullanılmalıdır. CSP ve Trusted Types ise ikinci savunma katmanı sağlayabilir.

Stored XSS

Stored XSS zararlı içeriğin database veya başka kalıcı storage içinde tutulup daha sonra kullanıcılara sunulmasıyla oluşur. Yorum, profil açıklaması veya CMS content gibi alanlar risk taşıyabilir. Input'u yalnızca kaydederken filtrelemek yeterli güvence değildir çünkü content farklı context'lerde render edilebilir. Output context'e uygun encoding veya gerektiğinde HTML sanitization uygulanmalıdır. Rich content gerekmiyorsa plain text render en güvenli varsayımdır.

Reflected XSS

Reflected XSS request içindeki saldırgan kontrollü verinin response içinde güvenli encoding olmadan geri yansıtılmasıyla oluşabilir. Search query ve error page parametreleri klasik örneklerdir. Modern SPA'da server response yerine client router veya query parsing üzerinden benzer davranış görülebilir. URL'den gelen veri güvenilir kabul edilmemelidir. HTML yerine text API kullanmak ve context-aware output handling uygulamak temel savunmadır.

DOM-Based XSS

DOM-Based XSS server response güvenli olsa bile client JavaScript'in saldırgan kontrollü string'i tehlikeli DOM sink'ine taşımasıyla oluşabilir. innerHTML, bazı HTML parsing API'leri ve string-to-code mekanizmaları risk oluşturur. URL fragment ve postMessage data'sı common source olabilir. Trusted Types injection sink kullanımını merkezi politika üzerinden sınırlamaya yardımcı olur. Data flow analysis source ile sink arasındaki yolu bulmak için kullanılabilir.

Cross-Site Request Forgery (CSRF)

CSRF authenticated kullanıcının browser'ını kullanarak istemediği state-changing request'in hedef uygulamaya gönderilmesini amaçlar. Cookie browser tarafından request'e otomatik eklendiği için cookie-based session modelleri özellikle değerlendirilmelidir. SameSite önemli bir savunma katmanıdır ancak tek kontrol olarak görülmemelidir. Anti-CSRF token ve Origin doğrulaması architecture'a göre uygulanabilir. XSS mevcutsa birçok CSRF kontrolünün saldırgan tarafından aşılabileceği de göz önünde bulundurulmalıdır.

Clickjacking

Clickjacking uygulamanın saldırgan kontrollü bir sayfada görünmez veya yanıltıcı frame içinde gösterilerek kullanıcının istemediği bir kontrole tıklamasına yol açabilir. Hassas işlem ekranlarının başka site tarafından frame edilmesine ihtiyaç yoksa framing tamamen engellenebilir. CSP frame-ancestors modern kontrol olarak tercih edilir. Legacy compatibility için X-Frame-Options ayrıca değerlendirilebilir. UI içinde yalnızca JavaScript frame-busting koduna güvenmek yeterli savunma değildir.

Open Redirect

Open redirect kullanıcı kontrollü URL'nin doğrulama yapılmadan navigation hedefi olarak kullanılmasına dayanır. Saldırgan güvenilir domain üzerinden kötü amaçlı başka adrese yönlendiren link oluşturabilir. Login sonrası return URL gibi parametreler allowlist veya same-origin kuralıyla sınırlandırılmalıdır. Yalnızca string prefix kontrolü subdomain ve URL parsing hatalarına yol açabilir. Platform URL parser kullanılıp protocol ve origin açık biçimde doğrulanmalıdır.

Client-Side Data Leakage

Frontend'e gönderilen her veri kullanıcının cihazında görünür hale gelir. Hidden field, disabled component veya JavaScript object içinde saklamak gizlilik sağlamaz. API response yalnızca gerçekten gereken alanları döndürmelidir. Error monitoring ve analytics payload'ları hassas data için ayrıca filtrelenmelidir. Browser cache, URL ve console log da data leakage kaynakları olarak değerlendirilmelidir.

Dependency ve Supply-Chain Saldırıları

Frontend build sistemi yüzlerce direct ve transitive package çalıştırabilir. Zararlı package yalnızca production bundle'a girmekle kalmayıp install veya build aşamasında da etkili olabilir. Lockfile dependency ağacının kontrolünü artırır ancak package'ın güvenli olduğunu kanıtlamaz. SCA, update review ve install script politikaları defense-in-depth sağlar. Dependency sayısını azaltmak hem bakım hem security yüzeyini küçültür.

Güvensiz Cross-Origin İletişimi

postMessage gibi API'ler farklı origin'ler arasında kontrollü iletişim sağlar. targetOrigin="*" kullanımı hassas verinin yanlış alıcıya gönderilmesine yol açabilir. Alıcı tarafta event.origin kontrol edilmezse saldırgan iframe hierarchy içinden beklenmeyen mesaj gönderebilir. Origin doğrulamasından sonra message schema da kontrol edilmelidir. Origin doğru olsa bile trusted sender'ın ele geçirilmiş olabileceği defense-in-depth modelinde düşünülmelidir.

XSS'e Dayanıklı Frontend Kodlama

XSS savunmasının ilk prensibi kullanıcı kontrollü veriyi bulunduğu context'e uygun biçimde data olarak işlemektir. Plain text gösterilecek content HTML parser'a hiç verilmemelidir. Rich HTML gerçekten gerekiyorsa güvenilir sanitization katmanı kullanılmalıdır. Framework'lerin escaping davranışı bilinmeli ve raw HTML API'leri özel review gerektirmelidir. Trusted Types ve CSP, uygulamadaki injection sink kullanımını daha kontrollü hale getirerek temel secure coding yaklaşımını destekler.

Output Encoding

Output encoding kullanıcı kontrollü karakterlerin bulunduğu context'te executable syntax olarak yorumlanmasını engeller. HTML body, attribute, URL ve JavaScript context aynı encoding yöntemini kullanmaz. Modern framework template'leri text interpolation sırasında çoğu temel encoding işlemini otomatik yapar. Raw DOM manipulation yapıldığında developer bu güvenli varsayımı kaybedebilir. Kullanıcının düz metni için textContent gibi text odaklı API'ler HTML parsing'den daha güvenli tercih oluşturur.

Sanitization

Sanitization izin verilen HTML yapısını korurken riskli element, attribute veya protocol'leri kaldırmayı hedefler. Rich text editor çıktısı bunun tipik kullanım alanıdır. Sanitizer configuration uygulama ihtiyacından daha geniş izin listesi taşımamalıdır. Sanitize edilen sonuç sonradan string manipulation ile tekrar güvensiz hale getirilmemelidir. Kullanılan sanitizer dependency olarak düzenli güncellenmeli ve bütün raw HTML yolları merkezi helper üzerinden geçmelidir.

Validation ile Sanitization Arasındaki Fark

Validation verinin uygulamanın beklediği biçime uyup uymadığını kontrol eder. Sanitization ise özellikle HTML gibi içeriği belirli güvenlik politikasına göre dönüştürür veya riskli parçaları çıkarır. Kullanıcı adı yalnızca belirli karakterleri kabul ediyorsa validation uygun olabilir. Rich HTML içeriği tamamen reddetmeden göstermek gerekiyorsa sanitization gerekir. Validation'ı XSS için tek savunma olarak kullanmak encoding ve sanitization gereksinimini ortadan kaldırmaz.

innerHTML ve Benzeri Dangerous Sink'lerden Kaçınmak

innerHTML verilen string'i HTML olarak parse eder ve bu nedenle injection sink olarak değerlendirilir. Düz text için textContent kullanılmalıdır. Element oluşturmak gerekiyorsa createElement ve güvenli property assignment daha kontrollü yaklaşım sağlar. Raw HTML zorunluysa yalnızca merkezi sanitization ve Trusted Types policy üzerinden geçmesi tercih edilmelidir. Code search veya lint rule doğrudan sink kullanımını pull request sırasında görünür hale getirebilir.

React'te dangerouslySetInnerHTML Güvenliği

React normal JSX interpolation sırasında string değerleri escape ederek birçok klasik XSS riskini azaltır. dangerouslySetInnerHTML bu güvenli varsayımı bilinçli olarak devre dışı bırakır. Kullanıcı veya CMS kontrollü HTML doğrudan bu API'ye verilmemelidir. Rich content sanitize edilerek merkezi wrapper component üzerinden render edilebilir. Wrapper dışındaki bütün kullanım code review veya lint kuralıyla engellenirse güvenlik yüzeyi önemli ölçüde daralır.

Vue ve Angular'da Raw HTML Riskleri

Vue'nun raw HTML rendering mekanizmaları ve Angular'ın trust bypass API'leri yanlış kullanıldığında framework escaping korumasını aşabilir. Template interpolation varsayılan olarak tercih edilmelidir. Framework'ün “trust” veya raw HTML escape hatch'i veriyi kendi başına güvenli hale getirmez. Uygulama merkezi sanitization policy belirlemelidir. Framework upgrade sırasında security guidance ve behavior değişiklikleri ayrıca incelenmelidir.

DOMPurify Kullanımı

DOMPurify kullanıcı kontrollü HTML'i sanitize etmek için yaygın kullanılan istemci tarafı çözümüdür. Ancak doğru configuration ve güncel version kullanımı önemlidir. Sanitized content'e daha sonra tehlikeli markup eklenmemelidir. Allowed tags ve attributes ürün ihtiyacına göre daraltılabilir. Trusted Types policy içinde DOMPurify kullanmak raw HTML üretimini merkezi güvenlik kapısından geçirmeye yardımcı olur.

Trusted Types

Trusted Types DOM XSS injection sink'lerine sıradan string verilmesini sınırlamak için browser seviyesinde policy modeli sağlar. CSP içindeki require-trusted-types-for 'script' enforcement etkin olduğunda belirli sink'ler trusted type bekler. Böylece uygulamanın her yerinde ayrı ayrı sanitization unutmak yerine güvenilir dönüşüm noktaları merkezi hale getirilebilir. 2026 itibarıyla modern tarayıcılarda desteğin genişlemesi bu yaklaşımı daha uygulanabilir hale getiriyor. Yine de policy'nin kendisi güvenli sanitization uygulamazsa Trusted Types tek başına koruma sağlamaz.

TrustedHTML

TrustedHTML bir Trusted Types policy üzerinden üretilmiş ve HTML sink'lerine aktarılabilen tiptir. Nesne doğrudan constructor ile oluşturulmaz, policy'nin createHTML() fonksiyonu üzerinden elde edilir. Policy içinde DOMPurify gibi sanitizer kullanılabilir. Bu model code review sırasında raw HTML üreten az sayıdaki policy noktasına odaklanmayı kolaylaştırır. Policy isimleri CSP trusted-types directive ile allowlist halinde sınırlandırılabilir.

DOM XSS Sink'lerini Merkezi Hale Getirmek

Uygulama boyunca onlarca doğrudan innerHTML kullanımı varsa güvenlik review'u zorlaşır. Raw HTML ihtiyacı birkaç merkezi wrapper veya policy içinde toplanabilir. Trusted Types enforcement doğrudan string assignment yapılan eski code path'leri çalışma zamanında görünür hale getirir. Migration önce report ve telemetry ile başlayabilir. Her yeni sink kullanımının security review gerektirmesi uzun vadede DOM XSS yüzeyini azaltır.

Content Security Policy ile İkinci Savunma Katmanı Oluşturmak

CSP browser'a hangi script, style, frame, connection ve diğer kaynakların kullanılabileceğini bildiren HTTP response policy'sidir. Güçlü CSP XSS ve clickjacking gibi bazı saldırıların etkisini azaltabilir. Buna rağmen CSP, output encoding ve sanitization yerine kullanılmamalıdır. Modern yaklaşım mümkün olduğunda nonce veya hash tabanlı strict policy kullanmayı hedefler. Production'a doğrudan sert enforcement eklemek yerine Report-Only ile gerçek dependency davranışı ölçülüp kontrollü geçiş yapılabilir.

CSP Nedir?

Content Security Policy server tarafından gönderilen policy'yi browser'ın uygulamasını sağlar. Script origin, network connection, frame embedding ve base URL gibi alanlar sınırlandırılabilir. Policy violation olduğunda browser resource'u engelleyebilir veya Report-Only modunda yalnızca raporlayabilir. CSP'nin koruma seviyesi directive'lerin ne kadar dar olduğuna bağlıdır. Geniş wildcard ve gereksiz unsafe seçenekleri policy'nin değerini ciddi biçimde azaltabilir.

default-src ve script-src

default-src özel directive tanımlanmayan bazı resource türleri için fallback kaynak politikası sağlar. script-src JavaScript execution ve source kontrolü açısından özellikle kritiktir. Script policy mümkün olduğunca nonce veya hash tabanlı tasarlanmalıdır. unsafe-inline kullanımı XSS savunmasını zayıflatabilir. Her resource türü için gereksiz origin açmak yerine ihtiyaç odaklı allowlist kullanılmalıdır.

Nonce ve Hash Kullanımı

Nonce her HTTP response için tahmin edilemez yeni değer olarak oluşturulur ve izin verilen script elementleriyle eşleştirilir. Aynı nonce'u uzun süre tekrar kullanmak modelin amacını bozar. Hash yaklaşımı içeriği sabit scriptler için uygun olabilir. Script içeriğindeki en küçük değişiklik hash'i değiştireceği için build pipeline ile otomatik üretim yararlıdır. Attacker-controlled markup'a otomatik nonce ekleyen middleware tasarımı güvenlik açığı oluşturabileceği için nonce yalnızca güvenilir template noktalarına yazılmalıdır.

strict-dynamic

strict-dynamic nonce veya hash ile güvenilmiş script'in dinamik olarak yüklediği scriptlere güven zinciri aktarabilir. Modern uygulamalardaki dynamic loader ve bundler davranışını yönetmeyi kolaylaştırabilir. Bu directive nonce veya hash modeliyle birlikte düşünülmelidir. Eski browser fallback policy ayrıca değerlendirilebilir. CSP deployment testleri bütün kritik route ve feature'larda gerçek script loading davranışını doğrulamalıdır.

object-src ve base-uri

object-src 'none' eski plugin ve object embedding yüzeyini kapatmak için strict CSP örneklerinde sık kullanılır. base-uri 'none' veya uygun dar policy saldırganın base URL manipülasyonu ile relative link davranışını değiştirmesini engellemeye yardımcı olur. Bu directive'ler çoğu modern uygulamada düşük compatibility maliyetine sahiptir. Yine de legacy embed ihtiyacı test edilmelidir. Policy yalnızca script-src ile sınırlı tutulmayıp bütün browser behavior katmanını kapsamalıdır.

frame-ancestors

frame-ancestors sayfanın hangi origin'ler tarafından frame edilebileceğini belirler. Framing ihtiyacı yoksa 'none' güçlü varsayımdır. Kendi site origin'i gerekiyorsa 'self' kullanılabilir. Bu directive default-src üzerinden fallback almaz ve HTTP CSP header içinde açıkça tanımlanmalıdır. Clickjacking savunmasında modern yaklaşım olarak X-Frame-Options'ın yerini büyük ölçüde alır.

connect-src ile Data Exfiltration Riskini Azaltmak

connect-src fetch, XHR, WebSocket, EventSource ve benzeri script bağlantılarının gidebileceği origin'leri sınırlar. XSS gerçekleştiğinde saldırganın rastgele external endpoint'e veri göndermesini zorlaştırabilir. Ancak image veya form gibi başka exfiltration yolları ayrı directive'lere bağlıdır. Bu nedenle connect-src tek başına data exfiltration engeli olarak görülmemelidir. Gerçek API ve telemetry origin listesi düzenli olarak küçültülmelidir.

Content-Security-Policy-Report-Only

Report-Only header policy violation'larını raporlar ancak browser resource'u engellemez. Legacy uygulamaya CSP eklerken hangi inline script veya external origin'in mevcut olduğunu görmek için güvenli başlangıç sağlar. Raporlar noisy olabilir ve browser extension kaynaklı olaylar filtrelenmelidir. Sensitive URL veya data rapor endpoint'ine taşınmamalıdır. Report-Only sonsuza kadar kalmamalı ve enforcement migration için belirli plan bulunmalıdır.

CSP Report-Only'den Enforcement'a Geçiş

İlk aşamada production trafik üzerinde violation inventory çıkarılır. Gerekli kaynaklarla gereksiz legacy scriptler birbirinden ayrılır. Inline code nonce veya external file modeline taşınır. Policy küçük kullanıcı grubu veya selected route üzerinde enforcement ile test edilebilir. Violation oranı kabul edilebilir seviyeye geldiğinde bütün uygulamaya enforcement uygulanır.

CSP Violation Raporlarını İzlemek

Violation raporu directive, blocked URI ve document context hakkında debugging sinyali sağlar. Rapor endpoint saldırgan tarafından yüksek hacimli istekle doldurulabileceği için rate limit ve aggregation kullanılmalıdır. Browser extension ve local development gürültüsü ayrı sınıflandırılabilir. Yeni release sonrası belirli directive violation artışı regression sinyali olabilir. Dashboard violation sayısını yalnızca toplam değil route ve release ID bazında göstermelidir.

Authentication ve Session Güvenliği

Frontend authentication güvenliğinde en önemli sorulardan biri credential bilgisinin browser JavaScript tarafından erişilebilir olup olmadığıdır. localStorage kolay kullanım sunar ancak XSS gerçekleştiğinde script tarafından okunabilir. HttpOnly cookie JavaScript erişimini engeller fakat browser request'lere cookie'yi otomatik eklediği için CSRF modeli ayrıca düşünülmelidir. Access ve refresh token yaşam süreleri architecture ile uyumlu olmalıdır. Session güvenliği tek storage seçimi değil XSS, CSRF, expiration, rotation ve logout davranışlarının birlikte ele alınmasıdır.

Frontend'de Token Saklama Problemi

SPA authentication tasarımında token'ı nereye koyacağınız riskleri farklı biçimde dağıtır. JavaScript-accessible storage XSS durumunda token extraction riskini artırır. Cookie modelinde credential JS tarafından okunamasa bile CSRF ve cookie scope doğru yönetilmelidir. In-memory token page refresh sonrasında kaybolur ve persistence için başka mekanizma gerektirir. Bu nedenle tek evrensel storage cevabı yerine threat model ve authentication architecture birlikte değerlendirilmelidir.

localStorage Kullanmanın Güvenlik Riskleri

localStorage aynı origin'de çalışan JavaScript tarafından okunabilir. Bu nedenle başarılı XSS saldırganın burada saklanan bearer token'ı almasına izin verebilir. Veri browser kapansa bile kalıcı olabilir. Hassas credential için localStorage'ı varsayılan çözüm yapmak riskli bir alışkanlıktır. Uygulama farklı model kullanamıyorsa XSS yüzeyi, token ömrü ve refresh tasarımı özellikle güçlü kontrollerle sınırlandırılmalıdır.

sessionStorage ve In-Memory Storage

sessionStorage tab yaşam döngüsüyle sınırlı olsa da aynı page origin'inde çalışan JavaScript tarafından erişilebilir. Bu nedenle XSS'e karşı localStorage'dan temel olarak farklı bir koruma sağlamaz. In-memory storage persistence azaltır ve page refresh ile token kaybolabilir. Buna rağmen mevcut page context içindeki malicious script bellekteki token'ı kullanabilir. Storage seçimi XSS önlemlerinin yerine geçmemelidir.

HttpOnly Cookie

HttpOnly attribute cookie'nin document.cookie gibi JavaScript API'leri üzerinden okunmasını engeller. Cookie yine fetch veya normal navigation request'leriyle browser tarafından server'a gönderilebilir. Bu nedenle XSS token extraction riskinin bir bölümünü azaltır ancak XSS saldırganının kullanıcı adına request göndermesini bütünüyle engellemez. Cookie session modeli CSRF kontrolleriyle birlikte tasarlanmalıdır. Session identifier mümkün olduğunca dar scope ve kısa uygun lifetime kullanmalıdır.

Secure

Secure cookie'nin HTTPS bağlantıları üzerinden gönderilmesini sağlar. Production uygulaması authentication cookie'sini HTTP üzerinden taşımamalıdır. Secure tek başına cookie içeriğini JavaScript'ten korumaz. HttpOnly ve SameSite gibi diğer attribute'larla birlikte kullanılmalıdır. HSTS HTTPS kullanımının downgrade ve yanlış HTTP erişimi riskini ayrıca azaltır.

SameSite

SameSite cookie'nin cross-site request'lerde gönderilme davranışını sınırlar. Strict en dar davranışı sunarken bazı normal external navigation akışlarını etkileyebilir. Lax güvenlik ve kullanılabilirlik arasında farklı denge kurar. None cross-site kullanım sağlar ve Secure gerektirir. Attribute browser default'una bırakılmadan açıkça belirlenmeli ve CSRF için tek savunma kabul edilmemelidir.

Domain ve Path Scope

Cookie Domain yalnızca gerekli host kapsamına izin verecek şekilde dar tutulmalıdır. Geniş parent domain scope'u farklı subdomain'lerin cookie behavior'ına etki etmesine yol açabilir. __Host- prefix destekleyen browser'larda host-only davranışı güçlendirmeye yardımcı olur. Path attribute request scope'u kontrol eder ancak tek başına güvenlik sınırı değildir. Session cookie scope architecture diagram üzerinde açıkça belgelenmelidir.

Access Token ve Refresh Token Ayrımı

Access token genellikle API erişiminde kullanılan daha kısa ömürlü credential olarak tasarlanır. Refresh token yeni access token elde etmek için daha yüksek değerli ve daha uzun ömürlü olabilir. Browser uygulamalarında refresh token'ın JavaScript-accessible alanda tutulması riskli olabilir. BFF yaklaşımı token lifecycle'ını server tarafına taşıyabilir. Token ömürleri, revocation kabiliyeti ve kullanıcı deneyimi birlikte değerlendirilmelidir.

Token Rotation

Refresh token rotation her refresh işleminde önceki token'ın yerine yeni token üretmeyi amaçlar. Eski token tekrar kullanılırsa replay şüphesi oluşabilir. Uygulama concurrency ve birden fazla tab davranışını doğru yönetmelidir. Rotation logic frontend yerine authorization server veya güvenilir backend bileşeninde uygulanmalıdır. Incident response süreci token family veya session revocation desteğini kullanabilmelidir.

Logout Sırasında Session Temizliği

Logout yalnızca frontend state içinde kullanıcı objesini silmek olmamalıdır. Server session veya refresh capability de geçersiz hale getirilmelidir. Browser cache veya client query cache hassas user data tutuyorsa temizlenmelidir. Shared device senaryoları özellikle düşünülmelidir. Logout sonrası back navigation eski hassas content'i göstermemelidir.

Backend for Frontend (BFF) ile SPA Güvenliğini Artırmak

BFF yaklaşımı browser ile backend servisleri arasında uygulamaya özel güvenilir server katmanı oluşturur. Authentication token'ları browser JavaScript'e vermek yerine BFF üzerinde tutulabilir. Browser yalnızca HttpOnly session cookie ile BFF'ye bağlanır. Bu model token extraction riskini azaltabilir fakat cookie authentication nedeniyle CSRF ve session security konularını ortadan kaldırmaz. Architecture ek server bileşeni ve operasyon maliyeti getirdiği için uygulamanın risk seviyesine göre seçilmelidir.

BFF Pattern Nedir?

Backend for Frontend belirli bir frontend istemcisinin ihtiyaçlarına özel API facade veya orchestration katmanıdır. Browser doğrudan birçok backend servisine bağlanmak yerine BFF endpoint'leriyle iletişim kurar. BFF authentication token ve downstream API çağrılarını server tarafında yönetebilir. Response yalnızca frontend'in gerçekten ihtiyacı olan veriyle sınırlandırılabilir. Bu model security dışında API aggregation ve client simplicity avantajı da sağlayabilir.

Token'ları Browser JavaScript'ten Uzak Tutmak

BFF OAuth veya başka authorization token'larını server-side session ile ilişkilendirebilir. Browser JavaScript token değerini doğrudan görmez. XSS gerçekleşse bile token string'inin storage'dan alınması zorlaşır. Buna rağmen malicious script authenticated browser üzerinden BFF'ye request gönderebilir. Dolayısıyla XSS prevention, CSRF ve authorization kontrolleri yine zorunludur.

HttpOnly Session Cookie Kullanımı

Browser BFF session identifier'ını HttpOnly, Secure ve uygun SameSite attribute'larıyla taşıyabilir. Cookie mümkün olduğunca host-only ve dar scope'ta tutulmalıdır. Session data server tarafında saklanabilir veya güvenli token formatıyla yönetilebilir. Session fixation ve rotation davranışları authentication event'lerinde değerlendirilmelidir. Logout server session'ı geçersiz hale getirmelidir.

BFF Kullanıldığında CSRF Riski

BFF cookie-based authentication kullandığında browser cookie'yi request'e otomatik ekleyebilir. Bu nedenle state-changing endpoint'ler CSRF açısından korunmalıdır. SameSite, anti-CSRF token ve Origin verification birlikte kullanılabilir. GET request state değiştirmemelidir. XSS'in CSRF savunmalarını etkileyebileceği unutulmamalıdır.

BFF Ne Zaman Tercih Edilmeli?

Hassas OAuth token'larının browser JavaScript'e verilmesini istemeyen yüksek değerli uygulamalarda BFF güçlü seçenek olabilir. Çok sayıda downstream API ve kompleks authentication flow bulunan sistemlerde orchestration avantajı da sağlar. Basit public site için ek server katmanı gereksiz olabilir. Hosting modeli, latency ve operasyon ownership değerlendirilmelidir. Karar threat model ve ürün ölçeğine dayanmalıdır.

Frontend'de Authorization Konusunda En Yaygın Hata

Frontend authorization'daki en yaygın hata UI görünürlüğünü gerçek erişim kontrolü sanmaktır. Route guard veya hidden button kullanıcı deneyimini düzenler ancak saldırgan doğrudan API request gönderebilir. Browser kodu kullanıcı kontrolündeki ortamda çalışır. Bu nedenle gerçek authorization kontrolü her hassas backend endpoint'te uygulanmalıdır. Frontend role bilgisi yalnızca kullanıcının erişebileceği işlevleri doğru biçimde göstermeye yardımcı olur.

Route Guard Gerçek Bir Güvenlik Kontrolü müdür?

Hayır, client-side route guard tek başına gerçek güvenlik sınırı değildir. Kullanıcı JavaScript state'ini değiştirebilir veya route bundle'a doğrudan erişebilir. Guard yine de kullanıcıya erişemeyeceği ekranları göstermemek açısından değerlidir. API backend'de ayrıca authentication ve authorization yapmalıdır. Route guard defense-in-depth ve UX katmanı olarak konumlandırılmalıdır.

Button Gizlemek Yetkilendirme Değildir

Admin butonunu DOM'dan kaldırmak kullanıcının ilgili API endpoint'ini çağırmasını engellemez. Request DevTools veya başka HTTP client üzerinden oluşturulabilir. Backend işlem yetkisini authenticated principal üzerinden doğrulamalıdır. Frontend button visibility aynı policy bilgisini UX için kullanabilir. Policy duplication varsa backend ile frontend davranışının zaman içinde ayrışmaması için merkezi permission model tasarlanmalıdır.

API Authorization Neden Backend'de Yapılmalıdır?

Backend saldırganın doğrudan değiştiremeyeceği güvenilir authorization boundary'dir. Request'teki role veya user ID client'tan geldiği için doğrulanmadan kabul edilmemelidir. Server session veya doğrulanmış token claim'leri üzerinden gerçek principal belirlenir. Kaynak sahipliği ayrıca database seviyesinde kontrol edilebilir. Object-level authorization eksikliği UI guard ile düzeltilemez.

RBAC ve ABAC'ın Frontend'deki Rolü

RBAC role tabanlı, ABAC ise attribute ve context tabanlı policy modelidir. Frontend bu policy'nin sonucunu kullanarak uygun UI'ı gösterebilir. Bütün policy engine'i client'a taşıyıp gerçek authorization olarak kullanmak doğru değildir. Server kararından türetilen capability listesi frontend'e gönderilebilir. UI ve backend aynı permission isimlerini kullandığında davranış tutarlılığı artar.

CSRF Saldırılarına Karşı Koruma

CSRF savunması özellikle browser'ın credential'ı otomatik gönderdiği session modellerinde önem taşır. SameSite güçlü bir başlangıçtır ancak tek kontrol olarak düşünülmemelidir. Framework'ün built-in CSRF koruması varsa doğru yapılandırmayla kullanılması genellikle en güvenli seçenektir. State-changing request'lerde token veya Origin doğrulaması eklenebilir. GET endpoint'lerin state değiştirmemesi CSRF riskini ve genel HTTP semantik hatalarını azaltır.

CSRF Nasıl Çalışır?

Saldırgan authenticated kullanıcının browser'ını hedef uygulamaya istenmeyen request göndermeye yönlendirir. Browser uygun cookie'leri otomatik eklediğinde server request'in kullanıcının gerçek niyetiyle oluşturulup oluşturulmadığını tek başına anlayamaz. Eğer state-changing endpoint ek doğrulama yapmıyorsa işlem gerçekleşebilir. Attack kullanıcının mevcut yetkileriyle sınırlıdır. Bu nedenle yüksek değerli işlemlerde yeniden doğrulama ve kullanıcı confirmation ek katman sağlar.

SameSite Cookie Kullanımı

SameSite cross-site request'lerde cookie gönderimini kısıtlayarak birçok CSRF senaryosunu azaltır. Strict daha dar, Lax ise navigation use case'leri açısından daha esnek davranır. External identity flow veya embedded uygulama gibi senaryolar SameSite seçimini etkileyebilir. Browser default'una güvenmek yerine explicit attribute yazılmalıdır. SameSite framework CSRF token mekanizmasının yerine otomatik olarak geçirilmemelidir.

Anti-CSRF Token

Anti-CSRF token server'ın legitimate application context tarafından bilinen ek değeri state-changing request ile doğrulamasını sağlar. Synchronizer token veya double-submit gibi farklı pattern'ler kullanılabilir. Token tahmin edilemez ve session ile doğru ilişkilendirilmiş olmalıdır. Query string üzerinden taşınması log ve history leakage riski oluşturabilir. Framework'ün yerleşik implementation'ı varsa custom protocol yazmak yerine onu kullanmak tercih edilmelidir.

Origin ve Referer Doğrulaması

Server state-changing request'in Origin header'ını beklenen origin ile karşılaştırabilir. Origin bulunmadığı belirli durumlarda Referer fallback olarak değerlendirilebilir. String contains veya suffix kontrolü yerine tam origin parsing kullanılmalıdır. Proxy ve deployment topology target origin hesaplamasını etkileyebilir. Bu kontrol token ve SameSite ile defense-in-depth olarak daha değerlidir.

Cookie-Based Authentication ile CSRF İlişkisi

Cookie browser tarafından otomatik request'e eklendiği için CSRF modeli cookie auth ile doğrudan ilişkilidir. HttpOnly cookie JavaScript'in cookie'yi okumasını engeller fakat CSRF'yi çözmez. SameSite cross-site gönderimi sınırlar. Anti-CSRF token request'in uygulama context'inden geldiğini doğrulamaya yardımcı olur. BFF kullanan SPA'lar da bu nedenle CSRF tasarımını açıkça ele almalıdır.

API İletişimini Güvenli Hale Getirmek

Frontend ile API arasındaki iletişim HTTPS, authentication, authorization ve veri doğrulaması birlikte kullanılarak güvenli hale gelir. CORS yalnızca browser cross-origin erişim politikasının bir parçasıdır ve API authorization'ın yerine geçmez. Client aldığı response'un beklenen schema'ya sahip olduğunu doğrulayabilir. Hassas bilgi URL'ye veya hata mesajına gereksiz eklenmemelidir. API tasarımı frontend güvenlik modelinin ayrılmaz parçasıdır.

HTTPS Zorunluluğu

Authentication veya hassas veri taşıyan production uygulamalarında HTTPS temel gereksinimdir. TLS network üzerindeki passive ve active müdahalelere karşı confidentiality ve integrity sağlar. Mixed content HTTP resource nedeniyle güvenliği zayıflatabilir. HSTS browser'ın domain'e sonraki erişimlerde HTTPS kullanmasını zorunlu hale getirmeye yardımcı olur. Local development için farklı certificate modeli kullanılabilir ancak production security requirement değişmez.

CORS Nedir ve Ne Değildir?

CORS browser'ın script tarafından yapılan cross-origin request sonucunun okunmasına hangi origin'ler için izin verileceğini yöneten mekanizmadır. Server response header'ları bu kararı browser'a bildirir. CORS authentication veya authorization sistemi değildir. Browser dışındaki client CORS politikasını uygulamak zorunda değildir. API her request'te gerçek credential ve permission doğrulamasını yapmalıdır.

Frontend CORS'a Bir Güvenlik Duvarı Gibi Güvenebilir mi?

Hayır, CORS network firewall veya API access control değildir. Saldırgan kendi HTTP client'ından endpoint'e doğrudan ulaşabilir. CORS yalnızca browser'daki cross-origin JavaScript erişim davranışını sınırlar. Sensitive operation server-side authorization gerektirir. Allowlist mümkün olduğunca dar tutulsa da bu yalnızca defense-in-depth ve browser isolation kontrolüdür.

API Response Validation

Frontend API response'un her zaman beklenen shape'e sahip olduğunu varsaymamalıdır. Schema validation runtime hatalarını ve beklenmeyen data flow'u azaltabilir. Validation security boundary olarak backend authentication'ın yerini tutmaz. Özellikle postMessage veya third-party API gibi daha düşük güvenli kaynaklarda strict schema değerlidir. Unknown field'ların DOM'a veya log'a kontrolsüz taşınmaması gerekir.

Hassas Bilgiyi Query String'e Koymamak

URL query string browser history, access log, analytics ve referrer üzerinden farklı sistemlere taşınabilir. Token, password veya hassas kişisel veri URL içine konmamalıdır. OAuth protocol gibi standardın zorunlu kıldığı geçici değerler ilgili specification'ın güvenlik modeline göre yönetilmelidir. Application-specific secret body veya secure server-side session içinde tutulmalıdır. Log pipeline URL'lerde sensitive pattern masking uygulayabilir.

Güvenli Error Response Yönetimi

Backend error response stack trace, database query veya internal system detail içermemelidir. Frontend kullanıcıya anlaşılır fakat minimum bilgi veren mesaj göstermelidir. Debugging için correlation ID kullanılabilir. Client error monitoring request body ve token'ları otomatik scrub etmelidir. Authentication error'larında account existence gibi gereksiz bilgiler saldırgana verilmemelidir.

postMessage, iframe ve Cross-Origin Güvenliği

Cross-origin browser context'leri arasında iletişim gerektiğinde postMessage güçlü fakat dikkat gerektiren API'dir. Gönderici mümkün olduğunda kesin target origin belirtmelidir. Alıcı origin ve message schema doğrulaması yapmalıdır. iframe sandbox yalnızca gereken capability'leri açacak şekilde uygulanabilir. Clickjacking savunması ve third-party isolation birlikte düşünüldüğünde iframe architecture daha kontrollü hale gelir.

postMessage Kullanırken targetOrigin

postMessage gönderirken alıcının origin'i biliniyorsa * yerine kesin protocol, host ve gerektiğinde port yazılmalıdır. Böylece target window başka origin'e navigate edilmişse hassas mesaj yanlış siteye iletilmez. Target origin configuration merkezi constant veya trusted URL parser üzerinden yönetilebilir. User-controlled origin doğrudan targetOrigin yapılmamalıdır. Wildcard yalnızca içeriğin gerçekten public olduğu ve target origin'in teknik olarak bilinmediği özel durumlarda değerlendirilmelidir.

Gelen Mesajlarda event.origin Kontrolü

Message event listener bütün window'lardan mesaj alabileceği için sender identity açıkça doğrulanmalıdır. event.origin beklenen exact origin listesiyle karşılaştırılmalıdır. Gerekirse event.source belirli iframe window reference'ıyla eşleştirilebilir. Origin doğrulandıktan sonra event.data schema validation'dan geçmelidir. Gelen data hiçbir zaman otomatik olarak HTML sink'e gönderilmemelidir.

iframe Sandbox Kullanımı

sandbox iframe içindeki script, form, navigation ve origin behavior'ına ek kısıtlamalar getirir. Varsayılan olarak kısıtlayıp yalnızca gerçekten gereken token'ları açmak daha güvenlidir. Aynı-origin content için hem allow-scripts hem allow-same-origin kombinasyonu sandbox değerini önemli ölçüde azaltabilir. Untrusted content mümkünse ayrı origin'den servis edilmelidir. Sandbox business requirement'a göre düzenli test edilmelidir.

Clickjacking'e Karşı frame-ancestors

Uygulamanın başka siteler tarafından frame edilmesine gerek yoksa CSP frame-ancestors 'none' kullanılabilir. Sadece kendi origin'iniz gerekiyorsa 'self' tercih edilebilir. Belirli partner embed use case'i varsa allowlist mümkün olduğunca dar tutulmalıdır. Policy HTTP header olarak gönderilmelidir. X-Frame-Options legacy defense-in-depth olarak kullanılabilir ancak modern policy frame-ancestors üzerinden yönetilmelidir.

Üçüncü Taraf Widget'ları İzole Etmek

Third-party widget'ı mümkün olduğunda cross-origin sandboxed iframe içinde çalıştırmak aynı page context'e doğrudan script eklemekten daha güçlü isolation sağlar. Widget yalnızca ihtiyaç duyduğu capability'leri almalıdır. postMessage contract version ve schema içermelidir. Payment veya chat gibi widget'larda sensitive data paylaşımı minimum tutulmalıdır. Vendor değişikliği trust model'i etkilediği için security review tekrarlanmalıdır.

Third-Party JavaScript Güvenliği

Third-party JavaScript sayfanızın origin'i içinde çalışıyorsa ciddi yetkilere sahip olabilir. Analytics veya chat etiketi küçücük snippet gibi görünse bile remote code yükleyebilir. Vendor compromise supply-chain riskini doğrudan kullanıcı browser'ına taşır. Script envanteri, CSP, SRI ve minimum privilege yaklaşımı birlikte kullanılmalıdır. Kullanılmayan third-party entegrasyonları kaldırmak en etkili risk azaltma yöntemlerinden biridir.

Analytics ve Tag Manager Riskleri

Analytics scriptleri kullanıcı davranışı ve page content hakkında geniş erişim elde edebilir. Tag manager runtime sırasında yeni script yükleyebildiği için code review sınırını aşabilir. Hangi ekiplerin tag yayınlayabildiği governance konusu olmalıdır. Sensitive form değerleri analytics payload'a otomatik taşınmamalıdır. Tag değişiklikleri release kadar görünür audit trail ile takip edilmelidir.

Payment ve Chat SDK'ları

Payment SDK yüksek değerli kullanıcı akışına erişirken chat SDK page-wide DOM ile etkileşebilir. Script yalnızca gereken route ve zamanda yüklenmelidir. Cross-origin iframe isolation mümkünse tercih edilmelidir. Vendor security update'leri düzenli izlenmelidir. Kullanıcının temel işlemi third-party script failure durumunda güvenli şekilde devam etmeli veya açık hata göstermelidir.

Subresource Integrity (SRI)

SRI external script veya stylesheet içeriğinin beklenen cryptographic hash ile eşleşmesini browser seviyesinde doğrular. Dosya değişmişse browser kaynağı çalıştırmaz veya uygulamaz. Cross-origin resource kullanımında uygun CORS davranışı ve crossorigin configuration gerekir. Sürekli değişen unversioned vendor URL'lerinde SRI operasyonel olarak zor olabilir. Mümkün olduğunda versioned immutable asset tercih edilmelidir.

CSP ile Third-Party Script Kısıtlama

CSP script'in hangi source veya nonce ile çalışabileceğini sınırlar. Her yeni vendor domain'i script-src allowlist'e eklemek yerine gerçekten gerekli olup olmadığı değerlendirilmelidir. Tag manager gibi dynamic loader strict CSP tasarımını etkileyebilir. Third-party script'in ayrıca connect-src veya frame-src ihtiyaçları bulunabilir. Policy diff security review sırasında görünür olmalıdır.

Third-Party Script Envanteri Tutmak

Envanter script URL, owner, business purpose, route ve data access bilgisi içerebilir. Vendor dependency'nin ne zaman eklendiği ve son review tarihi kaydedilmelidir. Script CSP allowlist ile inventory otomatik karşılaştırılabilir. Sahibi bulunmayan script removal adayıdır. Inventory incident sırasında hangi uygulamaların compromised vendor'dan etkilendiğini hızlı göstermelidir.

Kullanılmayan Script'leri Kaldırmak

Eski campaign veya artık kullanılmayan chat widget production'da gereksiz attack surface oluşturur. Script removal performansı da iyileştirebilir. Usage telemetry veya owner confirmation kaldırma kararını destekler. Tag manager container düzenli olarak temizlenmelidir. “Belki ileride kullanılır” gerekçesiyle remote code'u sürekli production'da çalıştırmak doğru değildir.

npm ve Open Source Dependency Güvenliği

Frontend projelerinde dependency ağacı application code'dan çok daha büyük olabilir. Direct dependency yanında yüzlerce transitive package build ve runtime davranışını etkiler. Package güvenliğini yalnızca bilinen CVE taramasıyla sınırlamak supply-chain risklerinin önemli bölümünü kaçırır. Lockfile, reproducible install, SCA, SBOM ve install-script policy birlikte kullanılmalıdır. Her küçük iş için yeni package eklememek dependency güvenliğinin en sade fakat etkili ilkelerinden biridir.

Supply-Chain Attack Nedir?

Supply-chain saldırısı doğrudan uygulamanıza saldırmak yerine kullandığınız package, build sistemi veya dağıtım kanalını hedefler. Compromised dependency install sırasında veya production bundle içinde zararlı code çalıştırabilir. Transitive dependency nedeniyle ekip package adını hiç bilmeden etkilenebilir. Dependency provenance ve update review önemlidir. Incident plan dependency'yi hızlı pinleme, kaldırma veya build'i durdurma imkanına sahip olmalıdır.

Direct ve Transitive Dependency Farkı

Direct dependency package.json içinde uygulamanın açıkça eklediği pakettir. Transitive dependency ise direct package'ın kendi dependency'si olarak gelir. Güvenlik taraması bütün tree'yi kapsamalıdır. Direct package güncel olsa bile alt dependency bilinen vulnerability taşıyabilir. SBOM gerçek deployed dependency ağacını görünür hale getirmeye yardımcı olur.

Typosquatting

Typosquatting bilinen package adına çok benzeyen zararlı package yayınlayarak developer'ın yanlış isimle kurulum yapmasını hedefler. Copy-paste yapmadan elle package adı yazılan komutlarda risk artabilir. Yeni dependency adı registry ve resmi repository üzerinden doğrulanmalıdır. Package download sayısı tek başına güven işareti değildir. Organization policy allowlist veya internal proxy üzerinden installation riskini azaltabilir.

Dependency Confusion

Dependency confusion internal package adıyla public registry'de daha yüksek version yayınlanması gibi resolution davranışlarını kötüye kullanabilir. Private scope ve registry configuration doğru yapılmalıdır. Internal package adları public registry'ye fallback etmemelidir. CI ve developer makinesi aynı registry policy'yi kullanmalıdır. Package manager configuration security review kapsamına alınmalıdır.

Compromised Maintainer Riski

Meşru package maintainer hesabı ele geçirildiğinde trusted package yeni zararlı sürüm yayınlayabilir. Lockfile otomatik latest update riskini azaltabilir fakat güncelleme anında review gerekir. Kritik dependency maintainer ve release değişiklikleri izlenebilir. Package install script veya obfuscated code yeni version diff'inde dikkat çekmelidir. Büyük dependency update'leri ayrı pull request olarak almak review'u kolaylaştırır.

Lockfile Kullanımı

package-lock.json dependency tree'nin belirli resolution'ını kaydeder. Repository'ye commit edilmesi developer ve CI ortamlarında aynı tree'nin kurulmasına yardımcı olur. Lockfile değişikliği code review'da görünür olmalıdır. Büyük ve açıklanamayan transitive değişiklikler ayrıca incelenmelidir. Lockfile dependency'nin güvenli olduğunu doğrulamaz fakat build determinism ve change visibility sağlar.

npm ci ile Reproducible Build

npm ci mevcut lockfile üzerinden temiz kurulum yapmak için CI ortamlarına uygun komuttur. package.json ile lockfile uyuşmuyorsa komut lockfile'ı sessizce değiştirmek yerine hata verir. Mevcut node_modules temizlenerek kurulum tekrarlanır. Bu davranış build reproducibility açısından değerlidir. Aynı install configuration'ın developer ve CI ortamında version control altında tutulması gerekir.

Software Composition Analysis (SCA)

SCA dependency tree'yi bilinen vulnerability, license ve package metadata açısından analiz eder. npm audit temel vulnerability sinyali sağlayabilir ancak tek SCA kontrolü olarak yeterli görülmemelidir. Private advisory ve farklı ecosystem coverage ihtiyacı kuruma göre değişebilir. Finding exploitability ve gerçek deployed kullanım açısından triage edilmelidir. Critical vulnerability otomatik security gate'i tetikleyebilir.

SBOM Oluşturma

Software Bill of Materials deployed artifact'ın hangi software bileşenlerini içerdiğini görünür hale getirir. Güncel npm sürümleri npm sbom komutuyla SPDX veya CycloneDX formatı üretebilir. SBOM vulnerability olayı sırasında etkilenen dependency'nin hangi ürünlerde bulunduğunu hızlıca araştırmayı kolaylaştırır. Build artifact ile SBOM aynı release ID altında saklanmalıdır. SBOM tek başına vulnerability scanner değildir ve inventory amacı taşır.

Dependency Adı

SBOM her bileşenin açık package veya component adını içermelidir. Scope bilgisi package identity açısından korunmalıdır. Benzer isimli package'lar karıştırılmamalıdır. Internal component naming organization standardıyla uyumlu tutulabilir. Dependency adı vulnerability ve license database eşleştirmesinin temel alanıdır.

Versiyon

Exact version vulnerability exposure belirlemek için kritik bilgidir. Semver range yerine deployed resolved version kaydedilmelidir. Build her zaman lockfile ve artifact ile eşleştirilebilir olmalıdır. Version upgrade sonrasında eski deployment'ların hangi version'ı kullandığı ayrıca bilinebilmelidir. Incident response yalnızca main branch package.json'a bakarak karar vermemelidir.

Kaynak

Package'ın hangi registry, repository veya artifact kaynağından geldiği provenance açısından önemlidir. Public registry ile internal package aynı isimde bulunabilir. Source metadata dependency confusion analizinde yardımcı olur. Git URL veya remote tarball dependency ayrıca review gerektirebilir. Organization package proxy kullanıyorsa gerçek upstream bilgisi korunmalıdır.

Lisans ve Bakım Durumu

Dependency güvenliği yalnızca vulnerability sayısından ibaret değildir. Uzun süredir bakım almayan package gelecekte security fix sağlayamayabilir. License kullanımı kurum politikasıyla uyumlu olmalıdır. Maintainer activity ve release frequency risk değerlendirmesine dahil edilebilir. Kritik işlevde abandoned package replacement planı oluşturulmalıdır.

Frontend Kodunda Secret Yönetimi

Browser'a gönderilen hiçbir değer gerçek anlamda secret kabul edilmemelidir. Build sırasında environment variable JavaScript bundle'a gömülüyorsa kullanıcı onu indirebilir ve inceleyebilir. Source map olmasa bile minified bundle içindeki string bulunabilir. Gerçek credential ve private API key server tarafında kalmalıdır. Frontend yalnızca public client identifier veya kullanıcıya görünmesi güvenlik problemi yaratmayan configuration değerleri taşımalıdır.

Frontend'e Gerçek Secret Konabilir mi?

Hayır, kullanıcıya indirilen frontend code içinde gerçek secret güvenli biçimde saklanamaz. Obfuscation, minification veya Base64 encoding bu gerçeği değiştirmez. Kullanıcı browser memory ve network request'leri inceleyebilir. Secret gerektiren işlem backend veya serverless trusted environment üzerinde yapılmalıdır. Frontend yalnızca yetkilendirilmiş public endpoint'e request göndermelidir.

Environment Variable'lar Neden Gizli Değildir?

Build tool belirli environment variable'ı client code içine replace ederse değer final bundle'ın parçası olur. Değişkenin adında SECRET yazması onu gizli yapmaz. Framework'ler genellikle client-exposed ve server-only environment variable için farklı prefix veya API sunar. Build configuration yanlışsa server secret istemeden client bundle'a taşınabilir. CI secret scanning final artifact üzerinde de çalıştırılabilir.

API Key'lerin Bundle İçinde Görünmesi

Bazı public API key'ler ürün tasarımı gereği browser'da bulunabilir ve security secret değildir. Bu durumda key server tarafında origin, quota veya scope ile sınırlandırılmalıdır. Private credential browser'a konmamalıdır. Vendor “frontend key” sunuyorsa dokümantasyonda public kullanım için tasarlandığı doğrulanmalıdır. Public key görünürlüğü gizlenmeye çalışılmamalı, kötüye kullanım sınırlandırılmalıdır.

Public ve Server-Only Environment Variable Ayrımı

Framework configuration hangi variable'ın client'a expose edildiğini açık biçimde ayırmalıdır. Naming convention ekip tarafından bilinmelidir. Server-only secret client component veya browser bundle import zincirine girmemelidir. Build-time test public bundle içinde forbidden pattern arayabilir. Shared config package server ve client export'larını ayrı entry point olarak tasarlayabilir.

Build Log'larında Secret Sızıntısı

Secret doğrudan frontend bundle'a girmese bile CI log'larına yanlışlıkla yazılabilir. Debug command bütün environment'ı print etmemelidir. CI provider secret masking tek savunma kabul edilmemelidir. Error stack veya failed command argument hassas value taşıyabilir. Secret exposure fark edildiğinde log silmenin yanında credential rotation yapılmalıdır.

Source Map Güvenliği

Source map production JavaScript'i orijinal source code ile eşleştirerek debugging'i kolaylaştırır. Public source map uygulama kaynak kodunu, dosya yapılarını ve bazı yorumları kullanıcıya açabilir. Bu durum tek başına vulnerability değildir ancak saldırgana uygulama yapısı hakkında daha fazla bilgi verebilir. Secret zaten source code içinde bulunmamalıdır. Kurumsal uygulamalarda source map error monitoring sistemine private upload edilip public web server'dan kaldırılabilir.

Production Source Map Riskleri

Public source map minified bundle'ın daha kolay okunmasını sağlar. Internal endpoint isimleri ve feature code daha görünür hale gelebilir. Security by obscurity gerçek savunma olmadığı için source map kapatmak XSS veya authorization açığını düzeltmez. Yine de gereksiz source disclosure azaltılabilir. Deployment policy public map ihtiyacını debugging gereksinimiyle birlikte değerlendirmelidir.

Source Kodunun İstenmeden Açığa Çıkması

Source map source content'i embed ediyorsa orijinal dosyanın büyük bölümünü içerebilir. Internal comment ve test helper production artifact'e taşınabilir. Bu nedenle build pipeline map dosyalarını açıkça yönetmelidir. CDN bucket wildcard upload yanlışlıkla map'i public hale getirmemelidir. Release sonrası automated URL kontrolü map exposure'ı test edebilir.

Private Error Monitoring Source Map Upload

Birçok error monitoring sistemi source map'i private artifact olarak kabul edip stack trace symbolication için kullanabilir. Browser yalnızca minified bundle'ı alır. Build ID veya release ID map ile deployed JavaScript'i eşleştirir. Upload tamamlandıktan sonra public artifact'ten map çıkarılabilir. Monitoring platformu access control ve retention politikasıyla korunmalıdır.

Production Deployment Politikası

Organization source map'in hangi application tier'larında public olabileceğini tanımlamalıdır. Public açık kaynak projesi ile private kurumsal dashboard farklı karar verebilir. Policy build tool configuration ve CDN deployment rule'a çevrilmelidir. Security gate deployed asset listesinde .map dosyalarını kontrol edebilir. Exception gerekiyorsa owner ve gerekçe bulunmalıdır.

HTTP Security Headers ile Browser'ı Sertleştirmek

HTTP security headers browser'ın uygulamayı hangi güvenlik politikalarıyla çalıştıracağını belirler. CSP, HSTS, no-sniff, referrer ve permissions policy farklı riskleri azaltır. Bu header'lar frontend repository yerine CDN veya backend configuration içinde bulunabilir ancak frontend ekibinin behavior'a etkisini bilmesi gerekir. Deployment ortamları arasında header farkı olmamalıdır. Automated integration test production benzeri response üzerinde beklenen header değerlerini doğrulayabilir.

Content-Security-Policy

CSP script, style, connection, frame ve diğer kaynakların kullanımını sınırlar. Strict nonce veya hash yaklaşımı XSS defense-in-depth için güçlü modeldir. Policy application's real asset architecture ile uyumlu olmalıdır. Gereksiz wildcard ve unsafe seçenekleri kaldırılmalıdır. Violation monitoring deployment sonrası sürekli devam etmelidir.

Strict-Transport-Security

HSTS destekleyen browser'a belirli süre boyunca siteye yalnızca HTTPS üzerinden erişmesini söyler. Bu politika HTTP downgrade ve kullanıcının yanlışlıkla insecure URL açması riskini azaltır. includeSubDomains yalnızca bütün subdomain'ler HTTPS için hazırsa kullanılmalıdır. Preload daha güçlü operasyon taahhüdü gerektirir. Yanlış uzun süreli HSTS configuration geri dönüşü zorlaştırabileceği için kontrollü rollout gerekir.

X-Content-Type-Options

X-Content-Type-Options: nosniff browser'ın belirli kaynaklarda MIME type sniffing yapmasını engellemeye yardımcı olur. Server doğru Content-Type göndermelidir. Bu header özellikle script ve stylesheet response'larında unexpected content interpretation riskini azaltır. Modern deployment template'lerinde güvenli default olarak kullanılabilir. Yine de yanlış MIME configuration'ı uygulama functionality'sini bozabilir ve test edilmelidir.

Referrer-Policy

Referrer-Policy navigation ve resource request sırasında hedef siteye ne kadar source URL bilgisinin gönderileceğini kontrol eder. Hassas path veya query bilgisinin third-party origin'e taşınmasını azaltabilir. Modern güvenli default'lardan biri origin bilgisini cross-origin request'te sınırlandırır. Uygulamanın analytics ihtiyacı data minimization ile dengelenmelidir. Sensitive token zaten URL içinde bulunmamalıdır.

Permissions-Policy

Permissions-Policy geolocation, camera, microphone gibi güçlü browser feature'larının hangi origin'ler tarafından kullanılabileceğini kontrol eder. Uygulama kullanmadığı capability'leri kapatabilir. Third-party iframe için ayrıca allow attribute üzerinden dar izin verilebilir. Policy privacy ve security yüzeyini azaltır. Browser support ve directive isimleri deployment sırasında güncel dokümantasyonla doğrulanmalıdır.

Cross-Origin Politikaları

COOP, COEP ve CORP gibi cross-origin politikaları browsing context ve resource isolation üzerinde daha güçlü kontrol sağlayabilir. SharedArrayBuffer gibi belirli capability'ler cross-origin isolation gerektirebilir. Bu header'lar third-party resource compatibility'sini etkileyebilir. Uygulamaya körlemesine eklenmemelidir. Threat model ve feature ihtiyacı üzerinden staged rollout yapılmalıdır.

X-Frame-Options ve Modern Alternatifi

X-Frame-Options eski fakat halen bazı compatibility senaryolarında kullanılan clickjacking header'ıdır. DENY veya SAMEORIGIN temel seçenekleridir. Modern CSP frame-ancestors daha esnek ve güncel kontroldür. İkisi defense-in-depth için birlikte kullanılabilir. Yeni policy tasarımında ana kaynak frame-ancestors olmalıdır.

Güvenli Frontend Kod Review Süreci

Code review güvenlik bilgisini ekip içinde en hızlı dağıtan süreçlerden biridir. Reviewer yalnızca syntax veya component naming değil trust boundary ve dangerous API kullanımına da bakmalıdır. Her pull request için çok uzun checklist kullanmak verimsiz olur. Bunun yerine risk trigger'ları özel ek review başlatabilir. Authentication, raw HTML, third-party script ve dependency değişikliği bu trigger'lar arasında bulunabilir.

Pull Request Security Checklist

PR template kullanıcı kontrollü data, auth değişikliği, new dependency ve security header değişimi gibi kısa sorular içerebilir. Developer risk olmadığını düşündüğünde gerekçeyi yazabilir. Checklist otomatik testin yerini tutmaz. Amaç reviewer'ın doğru alanlara dikkat etmesini sağlamaktır. Çok uzun ve her zaman aynı cevap verilen form zamanla anlamını kaybeder.

Yeni Dependency Eklenirken Sorulması Gerekenler

İlk soru gerçekten dependency gerekip gerekmediğidir. Package maintenance durumu, transitive tree, install script ve license incelenebilir. Aynı iş platform API ile küçük kodla yapılabiliyorsa dependency riskinden kaçınılabilir. Package source ve official repository doğrulanmalıdır. Dependency addition ayrı commit olduğunda lockfile diff review daha anlaşılır olur.

Dangerous API Kullanımlarını Review Etmek

innerHTML, raw HTML framework API'leri, eval ve dynamic script creation gibi noktalar security-sensitive olarak işaretlenebilir. Static analysis bu kullanımın önemli bölümünü bulabilir. Reviewer input source ve sanitization path'ini kontrol eder. Kullanım gerçekten gerekliyse merkezi güvenli wrapper tercih edilir. Exception'ın neden var olduğu code comment yerine test ve helper design ile görünür olmalıdır.

Authentication Değişikliklerine Ek Review

Login, token refresh, cookie veya logout değişikliği sıradan UI refactor olarak değerlendirilmemelidir. Security owner veya authentication domain uzmanı ek reviewer olabilir. Session lifetime ve CSRF etkisi incelenir. Frontend ile backend deploy sırası compatibility açısından planlanır. Regression test user session'ın eski ve yeni version'da güvenli çalıştığını doğrulamalıdır.

Güvenlik Açısından Hassas Dosyalar İçin CODEOWNERS

Authentication helper, CSP config veya CI security policy gibi dosyalar ek owner review gerektirebilir. CODEOWNERS mekanizması ilgili ekip onayı olmadan merge'i engelleyebilir. Çok fazla dosyayı security owner'a bağlamak bottleneck oluşturabilir. Sadece yüksek riskli boundary'ler seçilmelidir. Ownership çalışan kişiden çok ekip seviyesinde tanımlandığında sürdürülebilir olur.

Security Champion Modeli

Security Champion frontend ekibinde security konularında daha fazla sorumluluk ve eğitim alan geliştiricidir. Bu kişi güvenlik ekibinin yerine geçmez. Threat model toplantılarını kolaylaştırır ve ekipte secure coding bilgisini yayar. Security review tek kişiye bağımlı kalmamalıdır. Champion rotation veya yedekleme modeli bilgi yayılımını artırır.

Frontend CI/CD Pipeline'ına Güvenlik Eklemek

CI/CD güvenlik kontrollerini her değişiklikte tekrar edilebilir hale getirir. SAST source code pattern'lerini, SCA dependency riskini, secret scanning credential exposure'ı değerlendirir. Build artifact integrity ve license kontrolü supply-chain görünürlüğünü artırır. Security gate risk seviyesine göre merge veya deployment kararını etkileyebilir. Araç sayısını artırmak yerine sonuçları doğru triage eden ve false positive'leri yöneten süreç kurulmalıdır.

Static Application Security Testing (SAST)

SAST source code veya build representation üzerinde güvenlik pattern'leri arar. DOM XSS sink, insecure randomness veya hardcoded secret benzeri riskler rule set'e göre bulunabilir. Framework-aware rule daha yüksek doğruluk sağlar. SAST sonucu doğrudan vulnerability kabul edilmeden developer tarafından context içinde incelenmelidir. Custom secure coding standard'ları için organization-specific rule yazılabilir.

Software Composition Analysis (SCA)

SCA package tree'yi bilinen security advisory ve metadata ile karşılaştırır. Direct ve transitive dependency birlikte taranmalıdır. Finding gerçek production bundle'da kullanılmayan dev dependency'de olabilir ve risk buna göre değerlendirilir. Buna rağmen vulnerable build tool supply-chain açısından yine önem taşıyabilir. Fix yalnızca version bump değil breaking change ve exploitability review içermelidir.

Secret Scanning

Secret scanning repository, commit history ve build artifact içinde credential pattern arayabilir. False positive azaltmak için high-confidence token formatları kullanılabilir. Secret commit edildiyse yalnızca git history'den silmek yeterli değildir. Credential derhal rotate edilmelidir. Pre-commit kontrolü geliştiriciye push öncesi erken feedback sağlayabilir.

Dependency License Kontrolü

Open source license güvenlik açığı değildir fakat distribution ve kullanım yükümlülükleri nedeniyle governance konusudur. CI allowed ve denied license policy uygulayabilir. Unknown veya custom license manuel review gerektirebilir. Transitive dependency de license obligation taşıyabilir. Security ve legal süreç aynı dependency inventory'den yararlanabilir.

Build Artifact Integrity

CI'da test edilen source ile production'a deploy edilen artifact aynı olmalıdır. Artifact hash ve provenance kaydı bu bağı güçlendirir. Build başka ortamda tekrar yapılıyorsa dependency veya environment farkı oluşabilir. Immutable artifact promotion daha güvenilir modeldir. Release ID deployed bundle, SBOM ve source commit'i ilişkilendirmelidir.

Security Gate Oluşturmak

Security gate hangi finding'in merge veya deployment'ı durduracağını önceden tanımlar. Critical vulnerability normal koşullarda blocker olmalıdır. High finding exploitability ve remediation availability ile değerlendirilebilir. Existing accepted risk ile yeni regression ayrılmalıdır. Gate override yalnızca kayıtlı risk acceptance süreciyle yapılmalıdır.

Critical Vulnerability

Critical finding kullanıcı hesabı, hassas veri veya code execution açısından yüksek etki taşıyabilir. Yeni critical vulnerability bulunan artifact production'a çıkarılmamalıdır. Finding'in gerçekten uygulamayı etkileyip etkilemediği hızlı triage edilmelidir. False positive kanıtlanırsa suppression süreli ve belgeli olmalıdır. Fix mevcut değilse feature disable veya dependency removal gibi containment seçenekleri değerlendirilir.

High Vulnerability

High vulnerability risk seviyesi yüksek olsa da context-based değerlendirme gerekebilir. Exploitability, attack surface ve public exposure dikkate alınır. Belirli SLA içinde remediation zorunlu olabilir. Yeni high finding merge'i blocker yapılabilir. Risk kabulü gerekiyorsa yönetim ve security owner onayı bulunmalıdır.

Risk Acceptance Mekanizması

Bazen vulnerability hemen düzeltilemez veya business nedeniyle kısa süreli exception gerekebilir. Risk acceptance finding, etki, compensating control ve expiration date içermelidir. “Sonra bakılacak” açık uçlu kabul sayılmamalıdır. Owner belirlenmelidir. Süre dolduğunda pipeline exception'ı otomatik olarak tekrar failure'a çevirebilir.

Frontend Güvenlik Test Stratejisi

Frontend security testing bir araçtan ibaret değildir. Unit test secure helper behavior'ını, integration test authentication flow'u ve DAST çalışan uygulamanın external behavior'ını değerlendirir. XSS ve CSP gibi browser-level kontroller gerçek browser ortamında doğrulanmalıdır. Dependency security ayrı SCA süreci gerektirir. Manuel security review business logic ve architecture risklerini tamamlar.

Security Unit Testleri

Sanitization wrapper, URL validator ve permission mapping gibi güvenlik helper'ları unit test için uygundur. Safe ve unsafe input sınıfları test edilebilir. Test payload gerçek saldırı çalıştırmak yerine zararsız işaretleyicilerle sink behavior'ını doğrulayabilir. Security helper refactor olduğunda regression hemen görünür. Unit test browser header veya gerçek authorization kontrolünün yerine geçmez.

Authentication Regression Testleri

Login, expired session, refresh, logout ve unauthorized response senaryoları otomatik E2E test kapsamına alınmalıdır. Logout sonrası protected API request başarısız olmalıdır. Session expiry sırasında kullanıcı güvenli şekilde yeniden authentication flow'a yönlendirilmelidir. Multi-tab behavior ürün için önemliyse ayrıca test edilir. Cookie attribute'ları response header seviyesinde doğrulanabilir.

XSS Payload Testleri

XSS testleri kullanıcı kontrollü data'nın text yerine executable markup olarak yorumlanıp yorumlanmadığını doğrular. Test ortamında zararsız marker kullanmak yeterlidir. Rich text sanitizer için allowed ve blocked HTML fixture'ları tutulabilir. Test yalnızca tek klasik script tag pattern'ine bağlı kalmamalıdır. Asıl hedef source-to-sink güvenlik kontratını doğrulamaktır.

CSP Testleri

Integration test production benzeri response'ta beklenen CSP header'ın bulunduğunu kontrol edebilir. Browser test izin verilmeyen inline script'in çalışmadığını doğrulayabilir. Nonce her response'ta farklı olmalıdır. CSP Report-Only yanlışlıkla enforcement yerine production'da kalmamalıdır. Third-party route'ların policy'de gereksiz wildcard açmadığı kontrol edilebilir.

CSRF Testleri

State-changing endpoint geçersiz veya eksik CSRF token ile request aldığında başarısız olmalıdır. Cross-site Origin simülasyonu integration testte kontrol edilebilir. SameSite cookie attribute ayrıca response testinde doğrulanabilir. CSRF testinin yalnızca frontend değil backend endpoint behavior'ını kapsaması gerekir. GET request'lerin state değiştirmediği API contract testiyle kontrol edilebilir.

Dependency Security Testleri

CI dependency tree üzerinde vulnerability scan çalıştırabilir. Audit threshold projenin risk modeline göre belirlenir. Lockfile değişikliği scanner sonucuyla birlikte review edilir. SBOM release artifact olarak üretilir. Known accepted findings ayrı policy dosyasında expiration ile yönetilebilir.

Dynamic Application Security Testing (DAST)

DAST çalışan uygulamayı dışarıdan test ederek HTTP ve browser behavior'ındaki security problemlerini arar. Staging veya güvenli test environment kullanılır. Scanner production data'ya zarar verecek state-changing testler çalıştırmamalıdır. Authentication setup doğru yapılmazsa protected route coverage eksik kalabilir. DAST source-aware SAST ve manuel review'u tamamlayan ayrı katmandır.

Manuel Security Review

Business logic ve architecture problemi otomatik scanner tarafından bulunmayabilir. Reviewer user journey, trust boundary ve abuse case üzerinden feature'ı inceler. Authentication ve payment gibi yüksek riskli feature daha derin review almalıdır. Finding yalnızca code satırı değil risk scenario ile yazılmalıdır. Manuel review sonucu mümkün olan yerlerde otomatik regression teste dönüştürülmelidir.

Penetration Testing Ne Zaman Gerekli?

Yüksek riskli public uygulama, önemli authentication değişikliği veya ödeme akışı bağımsız penetration test gerektirebilir. Regulatory veya müşteri requirement ayrıca test sıklığını belirleyebilir. Penetration test secure development lifecycle'ın yerine geçmez. Test belirli tarihteki uygulama state'ini değerlendirir. Findings remediation ve retest ile kapatılmalıdır.

Release Öncesi Frontend Security Gate

Release security gate development boyunca yapılan kontrollerin production artifact üzerinde son doğrulamasıdır. Amaç her şeyi yeniden manuel test etmek değildir. Kritik vulnerability, dependency durumu, CSP, header ve secret exposure gibi yüksek değerli kontroller otomatik olarak doğrulanabilir. Third-party script diff release change set ile karşılaştırılabilir. Security sign-off yalnızca riskli release'lerde ek insan onayı gerektirecek şekilde ölçeklenebilir.

Kritik Zafiyet Kontrolü

Release artifact'a bağlı açık critical vulnerability bulunmamalıdır. Scanner result source commit ve lockfile ile ilişkilendirilir. Yeni advisory release hazırlanırken yayınlanmış olabilir ve son scan zamanı önem taşır. Accepted risk ayrı listede görünmelidir. Critical finding doğrulanırsa release otomatik durmalıdır.

Dependency Audit

Final lockfile bütün direct ve transitive dependency'ler için analiz edilir. npm audit temel kontrol olarak kullanılabilir. Daha geniş SCA sonucu gerekiyorsa pipeline aynı release üzerinde onu da çalıştırır. Dependency update sonrası test ve security review tamamlanmalıdır. Release SBOM immutable artifact ile birlikte saklanmalıdır.

CSP Doğrulaması

Production response gerçek CSP header ile test edilmelidir. Staging ile production CDN configuration farklı olabilir. Policy enforcement açık olmalı ve yanlışlıkla yalnızca Report-Only kalmamalıdır. Nonce ve allowed origin behavior representative route'larda doğrulanır. CSP violation dashboard release sonrası kontrol edilir.

Security Header Kontrolü

HSTS, no-sniff, Referrer-Policy ve diğer gerekli header'lar automated HTTP test ile doğrulanabilir. Redirect response ve HTML response farklı config taşıyabilir. CDN layer header'ı overwrite edebilir. Header value organization standardıyla karşılaştırılır. Test public deployment URL üzerinde çalıştırıldığında gerçek edge configuration doğrulanır.

Production Environment Variable Kontrolü

Build artifact client-exposed environment variable listesiyle analiz edilebilir. Development endpoint veya debug flag production bundle içinde kalmamalıdır. Secret scanning final JavaScript dosyalarında da çalışabilir. Public configuration'in doğru environment'a işaret ettiği kontrol edilir. Authentication issuer veya API origin typo'su güvenlik ve availability problemi yaratabilir.

Source Map Kontrolü

Public source map policy izin vermiyorsa deployed asset listesinde map bulunmamalıdır. Error monitoring upload'ın başarılı olduğu release metadata ile doğrulanabilir. Source map reference comment final bundle içinde public URL göstermemelidir. CDN cache eski map'i tutuyor olabilir. Release validation gerçek URL üzerinden 404 veya erişim policy'sini kontrol edebilir.

Third-Party Script Kontrolü

Production script inventory approved baseline ile karşılaştırılır. Tag manager üzerinden son dakika eklenen scriptler de kapsama alınmalıdır. Yeni source CSP diff'te görünür olabilir. Owner bulunmayan veya test edilmemiş script release öncesi kaldırılabilir. SRI kullanılan external immutable asset hash'i version ile uyumlu olmalıdır.

Security Sign-Off

Her release manuel security sign-off gerektirirse süreç bottleneck oluşturabilir. Risk bazlı model yalnızca authentication, payment, new third-party veya accepted critical risk gibi trigger'larda insan onayı isteyebilir. Normal release automated gate ile ilerler. Sign-off hangi evidence'ın incelendiğini kaydeder. Approval güvenlik sorumluluğunu tek kişiye devretmez.

Production'da Frontend Güvenliğini İzlemek

Security çalışması deployment ile bitmez çünkü dependency ve threat durumu sürekli değişir. CSP violation yeni injection veya yanlış deployment sinyali olabilir. Client error monitoring beklenmedik security behavior'ı gösterebilir. Third-party script upstream değişikliği sizin repository'nizde commit olmadan gerçekleşebilir. Production monitoring güvenlik olayını mümkün olduğunca erken tespit etmek için release ve ownership bilgisiyle birlikte çalışmalıdır.

CSP Violation Monitoring

CSP report endpoint violation'ları merkezi telemetry sistemine gönderebilir. Browser extension kaynaklı false signal'ler filtrelenmelidir. Yeni external script origin'i sudden spike oluşturursa araştırılmalıdır. Release ID ile correlation regression tespitini kolaylaştırır. Report endpoint sensitive data retention politikasına uygun olmalıdır.

Client-Side Error Monitoring

Unexpected Trusted Types exception veya CSP-blocked resource client error olarak görülebilir. Error monitoring security control regression'ını erken gösterebilir. Stack trace faydalıdır fakat user input veya token payload'a eklenmemelidir. Session replay kullanılıyorsa sensitive field masking ayrıca gereklidir. Error metric security alert ile normal bug alert'inden ayrılabilir.

Hassas Veriyi Loglamamak

Frontend console ve remote logging sistemine access token, password veya payment bilgisi gönderilmemelidir. Error object otomatik serialize edilirken request header içerebilir. Logging helper sensitive key filtering uygulamalıdır. Production console debug log'ları mümkün olduğunca azaltılmalıdır. Incident sırasında daha fazla telemetry gerekirse geçici debug mode privacy review ile açılmalıdır.

Dependency Vulnerability Monitoring

Repository değişmese bile yeni advisory mevcut dependency'yi vulnerable hale getirebilir. Scheduled SCA taraması bu durumu bulur. SBOM hangi deployed release'lerin etkilendiğini gösterir. Critical advisory alert doğrudan owner ekibe yönlendirilmelidir. Patch unavailable ise compensating control veya dependency removal değerlendirilir.

Third-Party Script Değişikliklerini İzlemek

External unversioned script içeriği repository'niz değişmeden farklılaşabilir. SRI immutable asset'te bu değişimi engelleyebilir. SRI kullanılamayan vendor script için source hash monitoring uyarı sağlayabilir. Tag manager publish event ayrı audit log'a alınmalıdır. Unexpected change incident triage başlatmalıdır.

Güvenlik Alarm Eşikleri

Her CSP violation alarm üretirse ekip kısa sürede alert fatigue yaşar. Threshold route, directive ve source riskine göre belirlenebilir. Yeni unknown script origin tek occurrence olsa bile yüksek önem taşıyabilir. Known browser extension violation aggregate edilerek düşük priority tutulabilir. Alarm her zaman owner ve önerilen ilk investigation adımını içermelidir.

Frontend Security Incident Response Süreci

Client-side güvenlik incident'inde hızlı containment önemlidir çünkü zararlı script binlerce aktif session üzerinde çalışabilir. İlk adım incident kapsamını ve etkilenen release'i belirlemektir. Credential compromise varsa revocation frontend patch'ten önce gerekebilir. Zararlı dependency veya third-party source mümkün olduğunca hızlı izole edilmelidir. Incident sonrası root cause ve process improvement aynı ciddiyetle ele alınmalıdır.

Incident Detection

Incident CSP alert, vulnerability advisory, kullanıcı bildirimi veya monitoring anomalisinden başlayabilir. İlk sinyal doğrulanmadan panik deployment yapılmamalıdır. Security owner incident severity belirler. İlgili release ve route telemetry ile eşleştirilir. Evidence silinmeden güvenli biçimde saklanmalıdır.

Etki Alanını Belirleme

Hangi version, kullanıcı grubu ve route'un etkilendiği hızlıca belirlenmelidir. SBOM dependency incident'lerinde yardımcı olur. Third-party script yalnızca belirli country veya tag condition altında yükleniyor olabilir. Authentication token exposure varsa session window değerlendirilir. Scope bilinmeden gereksiz bütün sistemi kapatmak availability etkisini artırabilir.

Compromised Token'ları İptal Etme

Credential sızıntısı doğrulanırsa yalnızca frontend patch yayınlamak yeterli değildir. Access token kısa ömürlü olsa bile refresh session revoke edilmelidir. Kullanıcı yeniden login olmak zorunda kalabilir. Incident communication kullanıcı etkisini açıkça anlatmalıdır. Rotation ve revocation capability önceden tasarlanmışsa response çok daha hızlı olur.

Zararlı Dependency'yi İzole Etme

Compromised package dependency tree'den çıkarılmalı veya güvenli version'a pinlenmelidir. Lockfile güncellenir ve temiz build yapılır. Build cache zararlı artifact taşıyabileceği için güvenilir olmayan cache temizlenebilir. SBOM üzerinden diğer repository'ler taranır. Package yalnızca dev dependency olsa bile install script çalıştırmış olabileceği için CI credential exposure ayrıca incelenmelidir.

CSP ile Geçici Containment

Belirli external script origin'inin compromise olduğu incident'te CSP hızlı containment sağlayabilir. Origin policy'den çıkarılıp browser'ın kaynağı yüklemesi engellenebilir. Bu geçici önlem root cause fix'in yerine geçmez. Functionality kaybı business owner ile değerlendirilir. Policy change hızlı release mekanizmasıyla kontrollü uygulanmalıdır.

Patch ve Redeployment

Patch en küçük güvenli değişiklik olarak hazırlanmalıdır. Security regression test incident scenario'yu yeniden üretir ve fix'i doğrular. Artifact clean environment'da build edilir. Canary veya staged deployment uygulanabilir. Monitoring patch sonrasında aynı indicator'ın devam edip etmediğini kontrol eder.

Post-Incident Review

Incident kapandıktan sonra yalnızca “kim hata yaptı” sorusuna odaklanmak süreç gelişimini engeller. Threat model neden riski yakalamadı veya hangi gate eksikti değerlendirilmelidir. Yeni lint, test, dependency policy veya monitoring kontrolü eklenebilir. Response süresi ve iletişim sorunları da incelenir. Action item'lar owner ve son tarih taşımalıdır.

Frontend Güvenliğinde Ölçülmesi Gereken Metrikler

Security metriği yalnızca scanner'ın bulduğu toplam issue sayısı olmamalıdır. Risk severity, remediation hızı ve review coverage daha anlamlı operasyon sinyalleri sağlar. CSP violation veya security regression trend'i frontend-specific bilgi sunar. Metrikler ekipleri issue gizlemeye teşvik etmeyecek şekilde tasarlanmalıdır. Amaç güvenlik programının iyileşip iyileşmediğini görmek ve darboğazları bulmaktır.

Açık Critical/High Vulnerability Sayısı

Critical ve high açık finding sayısı mevcut risk exposure'ın önemli göstergesidir. Existing accepted risk ayrı gösterilmelidir. Finding sayısını düşürmek uğruna false positive olarak kapatma baskısı yaratılmamalıdır. Route ve application criticality ek context sağlar. Hedef yeni critical vulnerability'nin mümkün olduğunca sıfır bekleme süresiyle ele alınmasıdır.

Mean Time to Remediate

MTTR finding'in açılmasından güvenli fix'in production'a ulaşmasına kadar geçen süreyi ölçebilir. Severity bazlı ayrı hedefler daha anlamlıdır. Critical issue günlerce backlog'da kalmamalıdır. Dependency patch ile architecture fix süreleri doğal olarak farklıdır. Metric process bottleneck bulmak için kullanılmalı, bireysel performans puanına dönüştürülmemelidir.

Dependency Patch Süresi

Yeni vulnerability advisory ile patched version deployment arasındaki süre dependency güvenlik olgunluğunu gösterir. Update automation bu süreyi azaltabilir. Breaking major upgrade daha uzun plan gerektirebilir. Critical package için daha sıkı SLA uygulanabilir. Patch bulunmayan durumda compensating control ve risk status ayrıca izlenmelidir.

Security Review Coverage

Yüksek riskli change'lerin ne kadarının security review aldığı ölçülebilir. Bütün PR'ları review edilmiş saymak anlamlı değildir. Authentication, raw HTML ve new third-party trigger'ları kapsama girmelidir. Review sonucunda bulunan issue türleri process improvement için analiz edilebilir. Coverage yüzdesi tek başına review kalitesini göstermez.

CSP Violation Sayısı

CSP violation toplamı deployment configuration ve unexpected script activity hakkında sinyal verir. Raw count trafik büyüdükçe doğal olarak artabilir. Milyon page view başına rate daha anlamlı olabilir. Known extension noise ayrı tutulmalıdır. Unknown script-src violation özel alarm kategorisi olabilir.

Security Regression Oranı

Daha önce düzeltilmiş security problem türünün tekrar ortaya çıkması regression'dır. Aynı root cause tekrar ediyorsa test veya secure abstraction eksikliği vardır. Regression rate zaman içinde düşmelidir. Finding kapatılırken mümkün olan yerlerde automated test eklenmesi bu metriği iyileştirir. Design system fix geniş regression sınıfını tek noktada engelleyebilir.

Frontend Ekipleri İçin Güvenlik Definition of Done

Security Definition of Done her feature'ın minimum güvenlik kontrollerinden geçtiğini görünür hale getirir. Liste çok uzun olursa formaliteye dönüşür. Risk trigger'ları gerektiğinde daha derin review başlatmalıdır. Requirement, threat model, user-controlled data, authentication, dependency ve production configuration temel başlıklar olarak kullanılabilir. Otomatik test sonucu evidence sağlayarak manuel checkbox sayısını azaltır.

Security Requirement Karşılandı mı?

User story'de tanımlanan authentication, privacy veya browser security requirement test edilmelidir. Requirement değiştiyse acceptance criteria güncellenmelidir. Feature yalnızca happy path ile kapatılmamalıdır. Unauthorized ve error scenario ayrıca doğrulanmalıdır. Evidence ilgili test veya review link'iyle ticket'a eklenebilir.

Threat Model Güncellendi mi?

Feature yeni trust boundary veya data flow ekliyorsa threat model değişmelidir. Değişiklik gerekmiyorsa kısa değerlendirme kaydı yeterlidir. Model repository ile aynı versioning sürecinde tutulabilir. New third-party integration kesin review trigger'ı olabilir. Threat model yalnızca büyük proje başlangıcında oluşturulup unutulmamalıdır.

Kullanıcı Kontrollü Veriler Güvenli mi?

Input source'tan DOM veya API sink'e kadar data flow incelenmelidir. Plain text doğru encoding API ile render edilmelidir. Rich HTML gerektiğinde sanitization uygulanmalıdır. URL, postMessage ve storage verisi de kullanıcı kontrollü kabul edilebilir. Raw sink kullanımı özel test gerektirmelidir.

Authentication ve Authorization İncelendi mi?

Feature protected resource kullanıyorsa backend authorization doğrulanmalıdır. Frontend route guard tek kontrol olmamalıdır. Session veya token handling değiştiyse security review yapılmalıdır. Logout ve expiration scenario test edilmelidir. Permission denial kullanıcıya hassas bilgi sızdırmadan gösterilmelidir.

Dependency'ler Kontrol Edildi mi?

Yeni package gerçekten gerekli olmalıdır. Version, maintenance ve transitive dependency değerlendirilir. Lockfile diff review edilir. SCA sonucu kabul edilebilir olmalıdır. Install script veya remote dependency özel risk taşıyorsa ek kontrol uygulanmalıdır.

Otomatik Güvenlik Testleri Geçti mi?

SAST, SCA ve secret scanning pipeline sonucunun başarılı olması gerekir. Relevant feature-specific tests ayrıca çalışmalıdır. Suppression varsa expiration ve owner bulunmalıdır. Test yalnızca main branch'te değil pull request aşamasında feedback vermelidir. Flaky security test kapatılmak yerine root cause çözülmelidir.

Production Konfigürasyonu Doğrulandı mı?

Header, cookie ve environment variable production benzeri environment'ta test edilmelidir. Source map ve debug setting policy ile uyumlu olmalıdır. Third-party script source listesi beklenen durumdadır. CSP enforcement aktif olmalıdır. CDN veya reverse proxy application config'i yanlışlıkla değiştirmemelidir.

Frontend Güvenliğinde Yapılmaması Gerekenler

Bazı frontend güvenlik hataları araç eksikliğinden değil yanlış varsayımdan kaynaklanır. Browser'ın güvenilir olduğunu düşünmek bunların başında gelir. Token storage, route guard ve environment variable konusunda yaygın yanlış alışkanlıklar bulunur. Güvenliği sadece release sonunda penetration test'e bırakmak process hatasıdır. Aşağıdaki örnekler ekip standardında açık anti-pattern olarak belgelenebilir.

Token'ları localStorage'a Varsayılan Olarak Koymak

localStorage kullanımı teknik olarak kolay olduğu için authentication tasarımının otomatik seçimi haline gelmemelidir. XSS başarılı olduğunda JavaScript token'ı okuyabilir. Token threat model, lifetime ve alternative architecture değerlendirilmeden storage seçilmemelidir. HttpOnly cookie veya BFF bazı uygulamalarda daha uygun olabilir. Seçim security ve product gereksinimi üzerinden gerekçelendirilmelidir.

Frontend Route Guard'a Authorization Olarak Güvenmek

Route guard yalnızca UI navigation kontrolüdür. Kullanıcı API request'i doğrudan oluşturabilir. Backend protected endpoint'te permission doğrulamalıdır. Frontend guard yine iyi kullanıcı deneyimi için kullanılabilir. Security documentation bunu açıkça “UX control” olarak sınıflandırmalıdır.

Kullanıcı Verisini innerHTML ile Render Etmek

Plain text kullanıcı verisi HTML parser'a gönderilmemelidir. textContent veya framework interpolation daha güvenli varsayımdır. Rich HTML gerçekten gerekiyorsa sanitizer kullanılmalıdır. Raw HTML API merkezi wrapper dışında yasaklanabilir. Trusted Types enforcement migration hedefi olarak eklenebilir.

CSP'de Gereksiz unsafe-inline Kullanmak

unsafe-inline script policy'nin XSS savunma değerini zayıflatabilir. Legacy inline code nonce veya external module modeline taşınmalıdır. Bir framework plugin'i nedeniyle bütün siteye unsafe izin vermek yerine özel çözüm aranmalıdır. Report-Only migration gerçek dependency'leri bulmaya yardımcı olur. Policy zaman içinde daha dar hale getirilmelidir.

Her npm Paketini Kontrol Etmeden Eklemek

Bir utility için package eklemek transitive dependency ve install script yüzeyini büyütebilir. Package popularity güvenlik garantisi değildir. Dependency eklemek architecture kararı olarak review edilmelidir. Küçük native API çözümü yeterliyse package gereksiz olabilir. Kullanılmayan dependency düzenli temizlenmelidir.

Frontend Environment Variable'larını Secret Sanmak

Client bundle'a gömülen environment value kullanıcı tarafından görülebilir. Bu nedenle private credential bu mekanizmayla saklanamaz. Framework client prefix'leri yalnızca exposure davranışını açık hale getirir. Secret gerektiren iş server side yapılmalıdır. Final bundle secret scanning bu hatayı deployment öncesi yakalayabilir.

Güvenliği Sadece Penetration Test'e Bırakmak

Penetration test önemli fakat dönemsel bir kontroldür. Günlük yüzlerce code change test sonrasında yeni risk oluşturabilir. Security requirement, threat model, CI scanning ve monitoring sürekli çalışmalıdır. Penetration test daha derin bağımsız validation katmanı olarak kullanılmalıdır. Bulunan pattern sonraki development lifecycle'a kalıcı kontrol olarak eklenmelidir.

Örnek Güvenlik Ağırlıklı Frontend Workflow

Güvenlik ağırlıklı workflow geliştirmeyi yavaşlatmak yerine hangi noktada hangi kontrolün yapılacağını netleştirir. Feature request geldiğinde security acceptance criteria yazılır. Tasarım threat model ile değerlendirilir, implementasyon secure abstraction kullanır ve pull request otomatik ile manuel kontrollerden geçer. Release gate production configuration'ı doğrular. Monitoring ve feedback döngüsü bir sonraki geliştirme turunu daha güvenli hale getirir.

1. Feature Requirement

Feature'ın hangi kullanıcı görevini çözdüğü tanımlanır. İşlenen veri ve external system'ler listelenir. Authentication gerekip gerekmediği belirlenir. Hassas veri varsa classification yapılır. High-risk trigger bulunuyorsa security owner erken aşamada sürece dahil edilir.

2. Security Acceptance Criteria

Security outcome test edilebilir ifadelerle yazılır. Protected operation backend authorization gerektirir. User content raw HTML olarak render edilmeyecekse bu açıkça belirtilir. Cookie veya cross-origin requirement tanımlanır. Acceptance criteria feature test planına doğrudan dönüşebilmelidir.

3. Threat Modeling

Data flow ve trust boundary çıkarılır. STRIDE veya benzeri checklist olası threat'leri sistematik düşünmeye yardımcı olur. High-risk threat için mitigation seçilir. Kalan risk product owner ile paylaşılır. Model feature PR veya architecture record ile versionlanır.

4. Secure Architecture

Token storage, BFF, API boundary ve third-party isolation gibi temel kararlar alınır. Browser'a gönderilmeyen veri mümkün olduğunca server'da tutulur. CSP ve cookie policy design'e dahil edilir. Raw HTML veya iframe ihtiyacı özel pattern ile çözülür. Architecture review gelecekteki maintenance maliyetini de hesaba katar.

5. Implementation

Developer güvenli shared helper ve framework default'larını kullanır. Static analysis anlık feedback sağlar. New dependency eklenirse review yapılır. Kullanıcı kontrollü content güvenli sink ile işlenir. Security-specific unit test kodla birlikte yazılır.

6. Pull Request Security Review

PR template risk trigger'larını görünür hale getirir. CODEOWNERS gerektiğinde ek reviewer çağırır. Raw HTML, auth veya dependency diff dikkatle incelenir. SAST ve secret scan sonuçları review sırasında görülür. Exception varsa ticket ve expiration zorunludur.

7. Automated Security Tests

SCA dependency vulnerability tarar. Authentication ve XSS regression testleri feature behavior'ını doğrular. Header ve CSP integration testleri environment üzerinde çalışır. Test sonucu machine-readable report olarak saklanabilir. New critical finding build'i durdurur.

8. Release Security Gate

Final artifact vulnerability ve secret açısından yeniden doğrulanır. Production CSP ve header config test edilir. Source map policy kontrol edilir. Third-party script diff incelenir. Yüksek riskli release security sign-off olmadan ilerlemez.

9. Production Monitoring

CSP violation, client security error ve dependency advisory izlenir. Release ID telemetry ile ilişkilendirilir. Sensitive data loglanmaz. Third-party script değişikliği alert üretebilir. Incident threshold gerçek risk ve trafik bazında ayarlanır.

10. Feedback ve İyileştirme

Bulunan her regression root cause üzerinden değerlendirilir. Aynı hata tekrar edebiliyorsa otomatik test eklenir. Security checklist veya helper güncellenir. Ekip içi kısa paylaşım bilgi yayılımını sağlar. Süreç düzenli olarak ölçülen metriklerle iyileştirilir.

Frontend Güvenliği Kontrol Listesi

Kontrol listesi güvenli geliştirme sürecinin her feature'da hatırlanmasını sağlar. Liste design, coding, authentication, dependency, CI/CD, deployment ve monitoring başlıklarına ayrılabilir. Checklist bütün security bilgisini tek sayfada çözmeye çalışmamalıdır. Her madde gerektiğinde daha ayrıntılı standard veya test helper'a bağlanmalıdır. Diyarbakır Yazılım Topluluğu'nun farklı yazılım proje çalışmalarını incelemek için https://www.diyarbakiryazilim.com.tr/projects adresi kullanılabilir.

Tasarım Kontrolleri

Yeni trust boundary ve sensitive data flow belirlenmelidir. Authentication ve authorization modeli backend ile birlikte tasarlanmalıdır. Third-party script veya iframe ihtiyacı gerekçelendirilmelidir. Threat model high-risk feature'larda güncellenmelidir. CSP ve browser security requirement architecture kararlarına dahil edilmelidir.

Kodlama Kontrolleri

User-controlled data safe output API ile render edilmelidir. Raw HTML kullanımında sanitization zorunlu olmalıdır. Dangerous sink'ler lint veya code review ile izlenmelidir. postMessage origin validation uygulanmalıdır. Error ve log mekanizması hassas data taşımamalıdır.

Authentication Kontrolleri

Token browser storage seçimi threat model ile gerekçelendirilmelidir. HttpOnly cookie kullanılıyorsa Secure, SameSite ve CSRF davranışı incelenmelidir. Logout server session'ı geçersiz hale getirmelidir. Protected API authorization backend'de uygulanmalıdır. Session expiration ve refresh regression testleri bulunmalıdır.

Dependency Kontrolleri

Yeni package necessity review'dan geçmelidir. Lockfile repository'ye commit edilmelidir. CI temiz ve deterministic installation kullanmalıdır. SCA ve SBOM release sürecine dahil edilmelidir. Unused ve abandoned dependency düzenli kaldırılmalıdır.

CI/CD Kontrolleri

SAST, SCA ve secret scanning pull request aşamasında çalışmalıdır. High-severity finding security gate'e bağlanmalıdır. Build artifact integrity korunmalıdır. Accepted risk'ler expiration taşımalıdır. CI configuration değişikliği hassas code olarak review edilmelidir.

Deployment Kontrolleri

Production security header'ları gerçek URL üzerinden doğrulanmalıdır. Source map ve debug config policy ile uyumlu olmalıdır. Client environment variable secret içermemelidir. Third-party inventory deployment ile eşleşmelidir. Immutable artifact aynı release ID ile production'a taşınmalıdır.

Monitoring Kontrolleri

CSP violation ve dependency advisory sürekli takip edilmelidir. Security alert owner'ı tanımlanmalıdır. Error monitoring sensitive field'ları scrub etmelidir. Third-party script değişiklikleri görünür olmalıdır. Incident response runbook düzenli olarak test edilmelidir.

Sık Sorulan Sorular

Frontend güvenliği konusunda en sık yapılan yanlış, browser tarafında alınan tek bir önlemin problemi tamamen çözdüğünü düşünmektir. HttpOnly cookie XSS'i bitirmez, CSP güvenli kodlamanın yerine geçmez ve CORS authorization değildir. Gerçek güvenlik farklı kontrollerin birbirini tamamladığı defense-in-depth yaklaşımıyla oluşur. Aşağıdaki sorular ekiplerin architecture ve geliştirme sırasında en sık karşılaştığı karar noktalarını özetliyor. Frontend güvenliği ve güvenli yazılım geliştirme süreçleri hakkında Diyarbakır Yazılım Topluluğu'nu tanımak için https://www.diyarbakiryazilim.com.tr/about adresi incelenebilir.

Frontend uygulaması tamamen güvenli hale getirilebilir mi?

Hiçbir uygulama için sıfır risk garantisi vermek gerçekçi değildir. Güvenlik yeni vulnerability, dependency değişikliği ve yeni saldırı yöntemleri nedeniyle sürekli süreçtir. Amaç attack surface'i azaltmak, yüksek etkili riskleri engellemek ve kalan riskleri hızlı tespit etmektir. Threat modeling, secure coding, CI/CD ve monitoring birlikte çalışmalıdır. Güvenlik olgunluğu “hiç sorun çıkmadı” yerine riskleri ne kadar hızlı önlediğiniz ve yönettiğiniz üzerinden değerlendirilmelidir.

Frontend'de localStorage kullanmak güvenli mi?

localStorage genel uygulama state'i için kullanılabilir ancak JavaScript tarafından okunabildiği unutulmamalıdır. XSS gerçekleştiğinde burada bulunan hassas token veya data saldırgan script tarafından erişilebilir. Bu nedenle uzun ömürlü authentication credential'ı için otomatik varsayılan olmamalıdır. HttpOnly cookie veya BFF farklı threat model avantajları sunabilir. Seçim authentication architecture ve CSRF kontrolleriyle birlikte yapılmalıdır.

React XSS saldırılarını otomatik olarak engeller mi?

React normal JSX text interpolation sırasında escaping uygulayarak birçok klasik XSS pattern'ini azaltır. Buna rağmen dangerouslySetInnerHTML, unsafe URL handling veya third-party DOM manipulation gibi escape hatch'ler risk oluşturabilir. Framework güvenli default sunar fakat uygulama code'u onu aşabilir. Raw HTML gerekiyorsa sanitization uygulanmalıdır. CSP ve Trusted Types ek savunma katmanı olarak değerlendirilebilir.

CSP tek başına XSS'i engellemek için yeterli mi?

Hayır, CSP defense-in-depth katmanıdır. Output encoding, safe DOM API ve sanitization temel savunma olmaya devam eder. Güçlü strict CSP bazı XSS exploit'lerini engelleyebilir veya etkisini azaltabilir. Yanlış yapılandırılmış geniş policy kolayca değer kaybeder. Güvenli frontend kodlama CSP bulunmasa bile doğru olmalıdır.

Frontend'de API key saklanabilir mi?

Gerçek secret olan private API key browser bundle içinde saklanamaz. Kullanıcı bundle, memory ve request'leri inceleyebilir. Bazı platformlar browser'da bulunması tasarlanmış public client key sunabilir. Bu key secret kabul edilmemeli ve origin, quota veya scope gibi server-side kontrollerle sınırlandırılmalıdır. Private credential gerektiren işlem backend üzerinden yapılmalıdır.

CORS bir güvenlik mekanizması mıdır?

CORS browser cross-origin resource sharing davranışını yöneten güvenlik politikasıdır ancak API authorization mekanizması değildir. Saldırgan browser dışındaki client ile endpoint'e request gönderebilir. API authentication ve authorization'ı her request'te ayrıca yapmalıdır. CORS trusted web origin'lerin response'u JavaScript üzerinden okuyabilmesini sınırlar. Bu nedenle CORS'u firewall gibi düşünmek yanlış security model oluşturur.

HttpOnly cookie mi localStorage mı daha güvenlidir?

HttpOnly cookie JavaScript tarafından okunamadığı için token extraction içeren XSS senaryolarına karşı önemli avantaj sunar. Buna karşılık cookie request'lere otomatik eklendiğinden CSRF savunması gerekir. localStorage CSRF'nin aynı biçimine sahip değildir fakat XSS durumunda credential doğrudan okunabilir. Bu nedenle tek kelimelik “daha güvenli” cevabı architecture bağlamı olmadan eksik kalır. Hassas browser session'larında BFF ve HttpOnly cookie modeli güçlü seçeneklerden biri olabilir.

npm audit frontend güvenliği için yeterli mi?

Hayır, npm audit bilinen dependency vulnerability'leri için değerli bir kontroldür fakat bütün frontend security risklerini kapsamaz. Typosquatting, malicious maintainer, secret exposure, XSS ve authorization problemi farklı kontroller gerektirir. npm audit sonucu exploitability açısından ayrıca değerlendirilmelidir. Lockfile, SCA, SBOM ve dependency review birlikte kullanılabilir. Uygulama code'u için SAST ve browser security testleri ayrıca gerekir.

SAST, SCA ve DAST arasındaki fark nedir?

SAST source code veya program representation üzerinde security pattern'leri analiz eder. SCA third-party dependency ve component risklerini değerlendirir. DAST çalışan uygulamayı dışarıdan HTTP veya browser behavior üzerinden test eder. Üç araç aynı problemi çözmez. Güçlü frontend security pipeline bu katmanları risk seviyesine göre birlikte kullanır.

Frontend için threat modeling gerekli mi?

Evet, özellikle authentication, user-generated content, payment, third-party script veya cross-origin interaction bulunan frontend'lerde çok değerlidir. Her küçük değişiklik için büyük workshop gerekmez. Risk trigger olduğunda mevcut model güncellenebilir. Threat modeling security problemini code yazılmadan bulmayı hedefler. Basit data flow diagram bile ekipte önemli güvenlik sorularının daha erken sorulmasını sağlar.

Frontend güvenlik testi CI/CD'ye nasıl eklenir?

İlk aşamada lint, SAST, dependency scan ve secret scanning pull request pipeline'ına eklenebilir. Authentication, XSS ve CSP için seçili regression testleri browser veya integration suite içinde çalıştırılabilir. Critical ve high yeni finding'ler security gate ile merge veya release'i durdurabilir. Release sırasında production header, environment variable, source map ve third-party script kontrolleri eklenir. Güvenlik ağırlıklı frontend geliştirme sürecinizi topluluk deneyimi ve yazılım çalışmalarıyla birlikte değerlendirmek için https://www.diyarbakiryazilim.com.tr adresinden Diyarbakır Yazılım Topluluğu'na ulaşabilirsiniz.