yoklateknik mülakat
GelişimGeçmiş

Frontend Web Security Mülakat Soruları

75 doğrulanmış Frontend Web Security mülakat sorusu — cevaplarıyla çöz, açıklamalarıyla öğren, gerçek simülasyonda kendini test et.

Gerçek simülasyonu dene →

Örnek sorular

Web SecurityZorluk 1
Cross-site scripting (XSS) açığı nedir?
  • aBir sayfanın aynı anda çok fazla istek göndermesi yüzünden sunucunun çökmesi
  • bBir ziyaretçinin siteyi, bir sayfanın eski cache'lenmiş kopyasını sunmaya kandırması
  • cSaldırganın, kurbanın tarayıcısına bir sayfadan gelen zararlı script'i çalıştırtması✓
  • dYavaş bir ağ bağlantısının, sayfanın kendi script'lerini yanlış sırada yükletip başarısız etmesi
Açıklama:XSS, saldırganın kontrol ettiği script'in güvenilen bir sitenin context'inde kurbanın tarayıcısında çalışmasıdır; böylece cookie/token çalabilir, DOM'u okuyabilir veya kullanıcı adına işlem yapabilir. Bu bir client-side kod çalıştırma açığıdır; sunucu çökmesi (a) veya cache sorunu (b) değildir.
Web SecurityZorluk 2
const comment = getUserComment();   // herhangi bir ziyaretçinin yazdığı metin
document.getElementById("box").innerHTML = comment;

Bir yorum alanı her ziyaretçinin metnini yukarıdaki kodla basıyor. Bu neden tehlikeli?
  • a<img src=x onerror=...> gibi markup içeren bir yorum parse edilip çalıştırılır✓
  • binnerHTML yalnızca düz metin gösterir, yani yorumdaki her HTML tag'i sayfayı çökertir
  • cinnerHTML'e atama modern tarayıcılarda desteklenmez ve sessizce başarısız olur
  • dBu şekilde basılan metni arama motorları indeksleyemez ama bunun dışında gerçek bir güvenlik sorunu yok
Açıklama:Güvenilmeyen metni innerHTML'e atamak, tarayıcının onu HTML olarak parse etmesine yol açar; saldırgan onerror handler'lı bir image (veya başka markup) enjekte ederek script çalıştırabilir — stored XSS. innerHTML metni göstermek yerine HTML olarak render eder (b), tehlike de tam burada. Düz metin için textContent kullan; HTML gerçekten şartsa sanitize et.
Web SecurityZorluk 2
Stored XSS ile reflected XSS arasındaki fark nedir?
  • aStored XSS yalnızca düz HTTP'de çalışır, reflected XSS ise HTTPS bağlantısı gerektirir
  • bReflected XSS cookie ve token okuyabilir, stored XSS ise onlara hiç dokunamaz
  • cStored XSS sunucu tarafında çalışır, reflected XSS ise yalnızca tarayıcıda çalışır
  • dStored XSS sunucuda saklanıp sonraki ziyaretçilere gösterilir; reflected XSS ise hazırlanmış bir isteğin cevabında geri yansır✓
Açıklama:Stored (kalıcı) XSS uygulamanın verisinde yaşar — bir yorum, bir profil alanı — ve onu yükleyen herkeste tetiklenir; reflected XSS saklanmaz, tek bir hazırlanmış istek ya da link'in cevabında doğrudan geri yansır. İkisi de tarayıcıda çalışır (c) ve ikisi de cookie okuyabilir (b); ayrım payload'ın nerede durduğudur, ne yapabildiği değil.
Web SecurityZorluk 2
const name = getQueryParam("name");   // URL'i saldırgan kontrol ediyor
// Seçenek A:
box.innerHTML = "Hello " + name;
// Seçenek B:
box.textContent = "Hello " + name;

İki satır da ziyaretçinin adını gösteriyor. Güvenilmeyen girdi için hangisi güvenli, neden?
  • aSeçenek A, çünkü innerHTML tehlikeli karakterleri kendi başına otomatik olarak escape eder
  • bSeçenek B, çünkü textContent değeri HTML olarak değil düz metin olarak ekler✓
  • cİkisi de olur, çünkü bir URL query parametresi gerçek HTML tag'i içeremez
  • dHiçbiri; tek güvenli yol tüm sayfada JavaScript'i devre dışı bırakmaktır
Açıklama:textContent düğümün metnini set eder ve markup'ı asla parse etmez; böylece <script> çalışmak yerine görünür karakterlere dönüşür. innerHTML string'i HTML olarak parse eder, yani saldırganın kontrol ettiği name script enjekte edebilir; otomatik escape yapmaz (a). URL parametreleri pekâlâ HTML/JS payload taşıyabilir (c).
Web SecurityZorluk 1
Kullanıcıdan gelen değerler bir sayfanın HTML'ine yerleştirilmeden önce neden escape (output-encode) edilmelidir?
  • a< ve > gibi karakterler HTML tag'i olarak okunmak yerine metin olarak gösterilsin diye✓
  • bTarayıcının parse edeceği HTML azaldığı için sayfa daha hızlı yüklensin diye
  • cDeğerler sıkıştırılıp HTTP cevabında daha az yer kaplasın diye
  • dEkran okuyucular özel karakterleri daha doğru telaffuz edebilsin diye
Açıklama:Escaping, HTML açısından anlamlı karakterleri (<, >, &, tırnaklar) zararsız entity'lere çevirir; böylece tarayıcı onları metin olarak render eder ve enjekte edilmiş markup'ı gerçek tag sanmaya kandırılamaz — XSS'e karşı temel savunma. Mesele güvenliktir; performans (b) veya boyut (c) değil.
Web SecurityZorluk 2
Çoğu UI framework'ü, DOM'a ham bir HTML string'i eklemek için özel bir yol sunar (örneğin bir "ham HTML bas" binding'i). Böyle bir özelliği kullanıcıdan gelen veriyle kullanırken temel güvenlik endişesi nedir?
  • aHam HTML ekranda kaldığı sürece tarayıcının geri butonunu devre dışı bırakır
  • bComponent'i her zaman normal binding'lerden belirgin şekilde daha yavaş re-render ettirir
  • cGelen HTML'i düz metne çevirir, böylece amaçlanan formatlama kaybolur
  • dFramework'ün otomatik escaping'ini baypas eder, yani veri içindeki her script çalışabilir✓
Açıklama:Framework'ler interpolate edilen değerleri varsayılan olarak escape eder; ham-HTML binding'i bunu bilerek kapatır ve string'i markup olarak enjekte eder, dolayısıyla kullanıcı verisini önce sanitize etmeden vermek XSS'i geri getirir. HTML'i metne çevirmez (c) — o zaten güvenli, varsayılan davranış olurdu.

Uzmanlığa göre

Angular 450JavaScript 450React 450TypeScript 450Vue 450

Kıdeme göre

Frontend JuniorFrontend MidFrontend Senior

Diğer alanlar

BackendFullstackDevOps / CloudAI EngineerVeritabanıMobilGüvenlikQA / Test OtomasyonuData EngineerOyun GeliştirmeML Engineer

2925 soruluk Frontend bankasında kendini sına.

Mülakata başla