yoklateknik mülakat
GelişimGeçmiş

Güvenlik As Api Security Mülakat Soruları

75 doğrulanmış Güvenlik As Api 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

As Api SecurityZorluk 1
Herkese açık bir API endpoint'inde bir client'ın dakikada gönderebileceği istek sayısına sınır yok. Bu durum en çok hangi güvenlik riskini yaratır?
  • aBir client endpoint'i brute force, scraping ya da kaynak tüketimi için bombalayabilir✓
  • bTLS sertifikaları yüksek yükte daha hızlı süresi dolar
  • cAPI her client'a bayat önbelleklenmiş veri döndürür
  • dVeritabanı şeması hata mesajlarında görünür hale gelir
Açıklama:Rate limiting olmadan tek bir client'ın (ya da botnet'in) sınırsız istek göndermesini engelleyen hiçbir şey yok — bu da kimlik bilgisi brute force'una, içerik kazımaya ya da sunucu/veritabanı kaynaklarını tüketmeye (DoS benzeri etki) kapı açar.
As Api SecurityZorluk 1
Bir rate limiter, istekleri client IP adresine göre sayıyor. Kimliği doğrulanmış API kullanıcıları için sadece IP bazlı rate limiting neden çoğu zaman yetersiz kalır?
  • aIP adresleri her zaman transport katmanında uçtan uca şifrelidir, bu yüzden hiçbir sunucu tarafı rate limiter bileşeni bunları sayım amacıyla inceleyemez ya da anahtarlayamaz.
  • bPaylaşılan IP'ler ilgisiz kullanıcıları gruplar, saldırganlar da IP değiştirerek limiti atlatabilir.✓
  • cHTTP/2, sunucuların client IP adresini okumasını yasaklar
  • dIPv6 adresleri bir rate-limiting sayacında saklanamaz
Açıklama:IP bazlı limitlerin iki başarısızlık modu vardır: paylaşılan IP'ler (ofis NAT'ı, mobil operatör CGNAT'ı) ilgisiz kullanıcıları tek sayaç altında toplar; çok sayıda IP'ye sahip saldırganlar (proxy, botnet) ise istekleri yayarak herhangi bir tek-IP eşiğinin altında kalır. Limiter'ı (IP'ye ek olarak ya da onun yerine) kimliği doğrulanmış kullanıcı/API key'e göre anahtarlamak her iki sorunu da önler.
As Api SecurityZorluk 2
Bir API, client rate limit'i aştığında Retry-After header'ı ile birlikte HTTP 429 döndürüyor. İyi davranan bir client ne yapmalıdır?
  • aGeri çekilip tekrar denemeden önce en az Retry-After içinde verilen süre kadar beklemeli✓
  • bFarklı bir API key'e geçip aynı hızda devam etmeli
  • cHeader'ı görmezden gelip 429'u 500 sunucu hatasıyla aynı şekilde ele almalı
  • dAynı isteği sıkı bir döngüde başarılı olana kadar hemen tekrar denemeli
Açıklama:Retry-After, client'a limitin ne zaman sıfırlanacağını söyler. Buna (backoff ile) uymak rate limiting'in beklediği işbirlikçi davranıştır; görmezden gelmek ya da hemen tekrar denemek limiti yeniden tetikler ve kötüye kullanım trafiği gibi görünebilir.
As Api SecurityZorluk 1
Bir kaynağı güncellemek için JSON body kabul eden bir API bağlamında "mass assignment" nedir?
  • aSunucu, request'teki her alanı sorgusuzca modele bağlar; bu da client'ın kontrol etmemesi gereken alanları ayarlamasına izin verir.✓
  • bAynı isteği birden çok API endpoint'ine aynı anda göndermek
  • cBir load balancer'ın istekleri birçok backend instance'a dağıtması; bu, herhangi bir tek instance'ın request body'yi nasıl parse ettiğiyle ilgisiz, ayrı bir altyapı-katmanı yönlendirme konusudur.
  • dRequest body'yi yedeklilik için birden çok anahtarla şifrelemek
Açıklama:Mass assignment, bir framework'ün gelen tüm JSON alanlarını bir allowlist olmadan otomatik olarak bir nesneye/modele eşlemesiyle olur — modelde is_admin ya da role gibi bir alan varsa, client bunu request body'ye ekleyebilir ve sunucu bunu seve seve ayarlar.
As Api SecurityZorluk 2
PATCH /api/users/42
{ "name": "Ayşe", "role": "admin" }

Handler user.update_from_json(request.body) çağırıyor; update_from_json bulduğu her anahtarı role dahil doğrudan user modeline ayarlıyor. Güvenlik sorunu nedir?
  • aHTTP spesifikasyonuna göre PATCH istekleri JSON body içeremez
  • bİstekte Content-Type: application/json header'ı eksik, ve bu olmadan çoğu framework body'yi hiç parse etmeyi reddeder, bu yüzden handler hiç çalışmaz bile.
  • cKendi profilini düzenleyen herhangi bir kullanıcı role'ü admin yapabilir — mass assignment üzerinden yetki yükseltme.✓
  • dname alanı URL-encode edilmediği için veritabanını bozacaktır
Açıklama:update_from_json gelen her alanı sorgusuzca bağladığı için, client'ın asla kontrol etmemesi gereken role alanı doğrudan yazılır ve normal bir kullanıcı kendini admin'e yükseltebilir. Doğru çözüm, sadece açıkça izin verilen düzenlenebilir alanları (ör. sadece name) bağlamaktır.
As Api SecurityZorluk 2
Bir API'nin update endpoint'inde mass assignment zafiyetlerini en iyi hangi yaklaşım önler?
  • a1 KB'den büyük her request body'yi reddetmek
  • bClient'tan session cookie'ye ek olarak bir API key göndermesini istemek; bu kimlik doğrulamayı güçlendirir ama kimliği doğrulanmış çağıranın hangi alanları yazabileceği hakkında hiçbir şey söylemez.
  • cEndpoint'in yazmasına izin verilen alanları açıkça listelemek, geri kalanını yok saymak/reddetmek (DTO/allowlist).✓
  • dHer request body'yi sonradan manuel inceleme için loglamak
Açıklama:Doğru çözüm yapısaldır: isteği doğrudan tam domain modeline değil, yalnızca kullanıcı tarafından düzenlenebilir alanları içeren özel bir DTO/input nesnesine bağlamak. role ya da balance gibi alanlar o DTO'da hiç yer almadığı için hiçbir client girdisi onlara ulaşamaz.

Uzmanlığa göre

AppSec 450Blue Team / Incident 450Cloud Security 450DevSecOps 450Offensive / Pentest 450

Kıdeme göre

Güvenlik JuniorGüvenlik MidGüvenlik Senior

Diğer alanlar

BackendFrontendFullstackDevOps / CloudAI EngineerVeritabanıMobilQA / Test OtomasyonuData EngineerOyun GeliştirmeML Engineer

2850 soruluk Güvenlik bankasında kendini sına.

Mülakata başla