Claude Code güvenlik kontrol listesi — hızlı web uygulaması spot-taramaları için

Hafif bir güvenlik spot-taraması nedir

Hafif bir güvenlik spot-taraması, sevk edilmeden önce bariz, yüksek etkili problemleri yakalamaya yönelik hızlı bir incelemedir (genellikle 30–60 dakika). Tam bir denetim değildir. Bunu bir güvenlik yürüyüşü gibi düşünün: gerçek uygulamalarda en sık sorun çıkaran yolları tararsınız ve tahmin değil kanıt ararsınız.

Bu Claude Code güvenlik kontrol listesi, günlük web uygulamalarında en sık bozulan alanlara odaklanır:

• Kimlik doğrulama varsayımları (kullanıcının kim olduğunu nasıl bildiğiniz)
• Yetkilendirme boşlukları (ne yapmaya izinli oldukları)
• Girdi doğrulama
• Gizlilerin yönetimi
• Yaygın enjeksiyon yüzeyleri (SQL, komut çalıştırma, şablon işleme, yönlendirmeler, yüklemeler)

Bu liste, hataların olmadığını kanıtlamaya, karmaşık tehdit aktörlerini modellemeye veya penetrasyon testinin yerini almaya çalışmaz.

"Somut bulgular" demek, kaydettiğiniz her sorunun geliştiricinin hemen harekete geçebileceği kanıt içermesi demektir. Her bulgu için şunları yakalayın:

• Tam dosya(lar) ve fonksiyon/handler adı
• Riskli davranışı bir cümleyle
• Minimal yeniden üretme adımı (istek, yük, veya tıklama yolu)
• Neden önemli olduğu (etki) ve kimin tetikleyebileceği
• Güvenli bir düzeltme yönü (tam bir yeniden yazım değil)

AI yardımcıdır, otorite değil. Arama, özetleme ve test önermede kullanın. Sonra kodu okuyarak ve mümkünse gerçek bir istekle yeniden üreterek doğrulayın. Model belirli konumları ve adımları gösteremiyorsa, iddiayı kanıtlanmamış sayın.

10 dakikada kapsam belirleyin

Hızlı bir inceleme, hedefi daraltmazsanız çalışmaz. Claude Code'a bir şey göstermeden önce bugün neyi kanıtlamaya çalıştığınızı ve nelerin kontrol edilmediğini kararlaştırın.

İlk olarak hata yapmanın maliyeti yüksek olan 1–3 gerçek kullanıcı yolculuğu seçin. İyi adaylar: giriş, şifre sıfırlama, ödeme ve yönetici düzenleme ekranları.

Sonra korumanız gereken varlıkları adlandırın. Spesifik olun: kullanıcı hesapları, ödeme işlemleri, kişisel veriler, sadece yöneticilere ait işlemler gibi.

Ardından tehdit varsayımlarınızı sade cümlelerle yazın. Karşınızda gezinen meraklı bir kullanıcı mı, script kullanan harici bir saldırgan mı, yoksa belli erişime sahip bir içeriden biri mi? Cevabınız "yeterince iyi"nin ne olduğunu değiştirir.

Son olarak, spot-taramanın bulgularla bitmesini sağlayacak şekilde geçme/kalma koşullarını tanımlayın. Basit kurallar işe yarar:

• Geçiş: her hassas işlem açık bir authn ve authz kontrolü gösterir.
• Hata: herhangi bir endpoint istemciyi kullanıcı kimliği veya rolü için güvenilir sayıyorsa başarısız.
• Geçiş: girdiler sadece UI'da değil, sunucu tarafında validasyondan geçer.
• Hata: gizliler loglarda, konfigürasyonlarda veya istemci kodunda görünüyor.

Başarısızlığın nasıl göründüğünü tarif edemiyorsanız, kapsam hâlâ çok belirsiz demektir.

Claude Code'a vereceğiniz bağlamı hazırlayın

Bir spot-taraması model doğru yerleri inceliyorsa işe yarar. İncelemenin tahmin değil kanıt üretebilmesi için küçük bir kod ve not demeti toplayın.

Önce güvenlik-kritik yolu paylaşın: istek giriş noktaları ve kullanıcının kim olduğunu ve ne yapabileceğini belirleyen kod. Veri akışını gösterecek kadar çevresel kodu da ekleyin.

Pratik bir demet genellikle şunları içerir:

• Auth girişi: oturum/JWT ayrıştırma, cookie ayarları, giriş callback'leri, auth middleware
• Route'lar + handler'lar: controller'lar, RPC metodları, GraphQL resolver'ları, arka plan işleyicileri
• Veri katmanı: ORM sorguları, ham SQL yardımcıları, sorgu oluşturucular, hassas tablolar için migration'lar
• Politika kontrolleri: rol kontrolleri, sahiplik kontrolleri, feature flag'ler, sadece admin endpoint'leri
• Doğrulama: istek şema doğrulayıcıları, dosya yükleme handler'ları, serileştirme kodu

Ayrıca birkaç satır ortam notu ekleyin: oturum mu yoksa JWT mi, token'ların nerede yaşadığı (cookie veya header), reverse proxy veya API gateway davranışı, kuyruk/cron çalışanları ve "sadece dahili" endpoint'ler. Varsayımları açık hale getirir.

Hataları takip etmeden önce bir envanter isteyin: giriş noktaları, ayrıcalıklı endpoint'ler ve dokunulan veri depoları. Bu, gözden kaçan yüzeyleri önler.

Ayrıca somut bulgulara zorlayan bir çıktı formatında anlaşın. Basit bir tablo iyi iş görür: Bulgu, Şiddet, Etkilenen endpoint/dosya, Kanıt (tam snippet veya satır aralığı), İstismar senaryosu, Düzeltme önerisi.

30–60 dakikalık inceleme için adım adım iş akışı

Zaman kutusu koyun:

• 10 dakika oryantasyon
• 15–30 dakika akışları takip etme
• 10 dakika yazma

Amaç mükemmel kapsama değil. Test edilebilir birkaç bulgu üretmek.

Uygulamayı açık tutarak okuyun. UI üzerinde tıklayın ve hangi isteklerin tetiklendiğini izleyin. Notlar belirli endpoint'lere, parametrelere ve veri kaynaklarına işaret etmelidir.

Bir oturuma sığan iş akışı:

1. Giriş noktalarını ve güven sınırlarını tasla. Genel route'ları, giriş gerektiren route'ları, admin route'ları, webhook'ları, yüklemeleri ve üçüncü taraf callback'leri not edin. Verinin kullanıcı kontrolünden sunucu güvencesine nerede geçtiğini işaretleyin.
2. Her önemli endpoint için kimliği kanıtlayan yerin neresi olduğunu yazın. Eğer kontrol "middleware" ise her route'un gerçekten onu kullandığını doğrulayın.
3. Yetkilendirme için de aynı şeyi yapın. Bir riskli işlem seçin (başkalarının verilerini görüntüleme, roller güncelleme, dışa aktarma, silme) ve izin kararını veritabanı sorgusuna kadar takip edin.
4. Kullanıcı girdisini sink'lere kadar izleyin. Bir parametreyi istekten SQL/ORM sorgularına, şablon işleme, komut çalıştırmaya, URL isteğine (SSRF), yönlendirmelere ve dosya yollarına kadar takip edin.
5. İzleme sırasında gizli ve konfigürasyon akışlarını tarayın. Token'ların loglarda, istemci kodunda, hata mesajlarında veya ortam dökümlerinde olup olmadığını kontrol edin.

Faydalı bir alışkanlık: her "tamam gibi" için onu kırmak adına ne yapacağınızı yazın. Kırma denemesini tarif edemiyorsanız, muhtemelen doğrulamadınız.

Authn spot-taramaları: kullanıcının kim olduğunu kanıtlayın

Kimlik doğrulama, uygulamanın "bu istek bu kişiye ait" dediği yerdir. Hızlı bir spot-taraması her satırı okumaktan çok, kimliğin nerede kurulduğunu bulup kestirme ve başarısızlık yollarını kontrol etmektir.

Güven sınırını bulun: kimlik ilk nerede oluşturuluyor veya kabul ediliyor? Bu bir session cookie, bir JWT bearer token, bir API anahtarı veya kenarda mTLS olabilir. Claude Code'dan "anonim"i kullanıcı id'sine çeviren tam dosya ve fonksiyonu işaret etmesini ve aynı işi yapabilecek diğer yolları listelemesini isteyin.

Kontrol edilmesi gereken authn noktaları:

• Tüm auth giriş noktalarını belirleyin (web giriş, API token'ları, mobil auth, dahili servis auth) ve bunların tek bir tutarlı kimlik modelinde birleştiğini doğrulayın.
• Giriş ve şifre sıfırlama için hız sınırlamaları, kilitlemeler ve kullanıcı tespiti (var olan ve olmayan hesaplar için farklı hata mesajları veya zamanlama) kontrol edin.
• Oturum ve cookie'leri inceleyin: HttpOnly, Secure, SameSite, süre sonu, girişte veya ayrıcalık değişiminde rotation, ve çıkış invalidasyonu (sadece cookie silme değil, sunucu tarafı invalidasyon).
• MFA ve kurtarma yollarını kontrol edin; kurtarma yolunun MFA'dan daha zayıf olmadığından emin olun (örneğin, MFA'yı atlayan sadece e-posta sıfırlama).
• Auth başarısızlığı loglarını gözden geçirin: işlemler için yararlı olmalı ama saldırganlara yardımcı olacak ayrıntıları sızdırmamalı ("kullanıcı var" ipuçları yok, token dökmeleri yok).

Pratik bir örnek: sıfırlama e-postaları "hesap bulunamadı" diyorsa hızlı bir kullanıcı sayma sorunu vardır. Genel bir mesaj olsa bile zamanlama farkları aynı gerçeği sızdırabilir; cevap zamanlamasını da kontrol edin.

Authz spot-taramaları: kullanıcının yetkili olduğunu kanıtlayın

Yetkilendirme, yanlış olduğunda en büyük zarara yol açan sorudur: "Bu kullanıcı bu belirli kaynafta bu işlemi yapmaya izinli mi?" Hızlı bir spot-taramada bu varsayıma kasıtlı olarak meydan okuyun.

Rolleri ve izinleri sade dilde yazın. İnsan okunur olsun:

• Sahip üye davet edebilir
• Üye kendi profilini düzenleyebilir
• Destek faturalama detaylarını görebilir ama planı değiştiremez
• Admin projeleri silebilir

Sonra her hassas işlemin sunucu tarafında, sadece UI'da değil, yetki kontrolü yaptığını doğrulayın. Düğmeler gizlenebilir ama saldırgan doğrudan API'yi çağırabilir.

Sıkça sorun çıkaran hızlı tarama:

• Oluşturan, silen, dışa veren, rol değiştiren veya faturalamaya erişen endpoint'leri bulun
• Her biri için sunucu tarafı izin kontrolünü (frontend değil) bulun
• Kullanıcı kontrollü ID'leri (projectId, userId, orgId) arayın ve sahiplik kontrollerini doğrulayın
• Admin-only yolların rol eksikse kapandığından emin olun
• Tenant sınırlarını kontrol edin: orgId/accountId oturum bağlamından gelmeli, sadece istek girdisinden değil

Klasik IDOR kokusu basittir: GET /projects/{id} gibi kullanıcı kontrollü {id} ile sunucunun onu mevcut kullanıcıya ait olup olmadığını doğrulamadan yüklemesi.

Gerçek bir cevap zorlayan bir prompt örneği:

"Bu endpoint için erişimi kararlaştıran tam kodu gösterin ve farklı bir orgId'den bir kullanıcının nasıl erişebileceğini sağlayacak spesifik koşulları listeleyin. Yoksa neden yok olduğunu dosya ve fonksiyon adlarıyla açıklayın."

Girdi doğrulama: kötü veriyi erken engelleyin

Hızlı web uygulaması sorunlarının çoğu bir boşluktan başlar: uygulama geliştiricinin beklemediği girdiyi kabul eder. "Girdi"yi, zararsız gibi görünse bile kullanıcı veya başka bir sistemin etkileyebileceği her şey olarak değerlendirin.

İncelediğiniz endpoint için girdileri adlandırarak başlayın:

• URL sorgu ve yol değerleri
• İstek gövdesi alanları (iç içe JSON dahil)
• Header'lar (auth header'ları, content-type, forwarded IP)
• Cookie'ler
• Dosya yüklemeleri (isim, boyut, tür, meta)

Validasyon, verinin uygulamaya girdiği yere yakın olmalı, iş mantığının derinliklerinde değil. Temelleri kontrol edin: tip (string vs number), maksimum uzunluk, zorunlu vs opsiyonel ve format (email, UUID, tarih).

Rol, durum alanı veya sıralama gibi bilinen değerler için allowlist tercih edin. Kötü değerleri birkaç örnekle engellemektense izin listesi koymak zor aşılır.

Ayrıca hata işleme kısmını kontrol edin. Uygulama girdiyi reddederken ham değeri yanıt, log veya UI'da geri yansıtmasın. Küçük doğrulama hataları veri sızıntısına veya enjeksiyon yardımcılarına dönüşebilir.

Riskli endpoint'ler (giriş, arama, yükleme, admin işlemleri) için kısa bir "kötü girdi" mini planı:

• Çok uzun stringler (10.000+ karakter)
• Yanlış tipler (string yerine dizi)
• Beklenmeyen enum değerleri
• Anlamı değiştirebilecek özel karakterler
• Zorunlu alanlar için boş değerler

Örnek: herhangi bir string kabul eden bir sıralama parametresi daha sonra SQL parçasına dönüşebilir. "date" veya "price" gibi bir allowlist bu sınıf hataları erken engeller.

Hızlı tarama için yaygın enjeksiyon yüzeyleri

Çoğu hızlı inceleme aynı birkaç yerde sorun bulur: kullanıcı girdisinin kod, sorgu, yol veya URL olarak yorumlandığı her yer. Burada "girdi güven sınırını aşıyor mu" anlarını ararsınız.

Veriyi giriş noktalarından (sorgu parametreleri, header'lar, cookie'ler, yüklemeler, admin formları) nereye gittiğine kadar izleyin.

Hızlı tarama hedefleri

Bu desenleri arayın ve her biri için somut çağrı noktası ve yük örneği isteyin:

• SQL enjeksiyonu: string ile kurulan sorgular, dinamik ORDER BY, ve kullanıcı değerlerini birleştiren IN (...) yapıları
• XSS: HTML render, şablonlar, markdown önizlemeleri, zengin metin editörleri
• Komut enjeksiyonu: görüntü işleme, PDF araçları, yedekleme veya "convert" adımları gibi shell çağrıları ve kullanıcı kontrollü bayraklar
• SSRF: webhook'lar, link önizlemeleri, URL'den içe aktarma özellikleri ve kullanıcı URL'si kabul eden iç durum kontrolleri
• Yol atlama (path traversal): dosya indirme endpoint'leri, zip çıkarma ve daha sonra isimle erişilen yükleme iş akışları

Ayrıca serileştirme ve şablon enjeksiyonuna dikkat edin. Kullanıcı tarafından sağlanan JSON, YAML veya şablonlanmış string'leri ayrıştıran her şey risk taşır, özellikle özel tipleri, ifadeleri veya sunucu tarafı render'ı destekliyorsa.

Bir özellik URL, dosya adı veya biçimlendirilmiş metin kabul ediyorsa, kanıtlayana kadar kötüye kullanılabileceğini varsayın.

Gizli bilgilerin yönetimi: sızıntıları ve zayıf depolamayı bulun

Gizli bilgilerle ilgili problemler genellikle nereden bakılacağını bildikten sonra yüksek sesle ortaya çıkar. Gizlilerin nerede yaşadığını ve nerelere yanlışlıkla kopyalandığını bulun.

Gizlilerin sıkça göründüğü yerler:

• Ortam değişkenleri ve uygulama konfigürasyon dosyaları
• CI çıktı ve build logları (başarısız deploy logları dahil)
• İstemci paketleri ve mobil build'ler (kullanıcılara gönderilen her şey)
• Debug endpoint'leri, sağlık sayfaları ve admin araçları
• Hata sayfaları, stack trace'ler ve analiz olayları

Sonra somut bir cevap isteyin: bugün bir gizli sızıyorsa, sonra ne olur? İyi bir sistem anahtar değişimi (rotation), iptal (revocation) ve hızlı yeniden dağıtım yolu sağlar. Cevap "daha sonra değiştiririz" ise bunu bir bulgu olarak ele alın.

En az ayrıcalık (least privilege) başka bir hızlı kazanımdır. Anahtarlar aşırı güçlü olduğunda olaylar daha kötü olur. Veritabanı kullanıcılarının tabloları düşürme yetkisi, üçüncü taraf token'ların hesapları yönetme yetkisi veya anahtarların ortamlar arasında paylaşılması gibi durumlara bakın. Hizmet başına, ortam başına en küçük izin kümesiyle tek bir anahtar tercih edin.

Hızlı spot-taramada Claude Code'a yapıştırabileceğiniz promptlar:

• "Sabit kodlanmış token, parola ve özel anahtarları ara. Eşleşen tam dosya yollarını ve dize kalıplarını listele."
• "İstek header'larını, cookie'leri, env var'ları veya tam hata objelerini loglayan herhangi bir kodu bul. Log satırlarını göster ve hangi hassas alanların görünebileceğini belirt."
• "Gizlilerin snapshot'lara, export'lara veya build artefaktlarına düşüp düşmediğini kontrol et. Nelerin yakalandığını ve nerede saklandığını belirt."

Son olarak guardrail'ları doğrulayın: kaynak kontrolden gizlileri engelleyen (pre-commit/CI kontrolleri), yedekler veya snapshot'ların açık metin kimlik bilgisi içermediği. Platform snapshot ve rollback destekliyorsa, gizlilerin çalışma zamanında enjekte edildiğini, kaydedilmiş imajlara gömülmediğini doğrulayın.

Somut bulgu zorlayan promptlar (kopyala-yapıştır şablonları)

Belirsiz promptlar belirsiz cevaplar üretir. Modeli kanıt göstermeye zorlayın: tam konumlar, izleyebileceğiniz bir iz, çalıştırabileceğiniz bir yeniden üretme ve iddianın yanlış olduğunu gösteren ne olur.

Bir seferde tek desen kullanın, sonra siz onaylayıp/geri çevirdikten sonra revize etmesini isteyin.

• Dosya seviyesi kanıt: "Repoyu auth, oturumlar, token'lar ve middleware için ara. İlgili dosyaları, fonksiyonları ve satır aralıklarını adlandır. İlgili snippet'leri alıntıla. Kod gösteremiyorsan 'kanıt bulunamadı' de."
• Girdiden sink'e izleme: "Bir kullanıcı kontrollü girdi seç (header, sorgu, gövde, cookie). Veriyi giriş noktasından kullanıldığı yere (SQL, HTML, shell, şablon, yönlendirme, dosya yolu) adım adım göster. Zincirdeki her fonksiyonu listele."
• Yeniden üretme adımları: "curl ile minimal bir yeniden üretme ver: metod, URL yapısı, header'lar, gövde. Beklenen durum kodunu ve başarılı/başarısız cevap örneğini ekle. Varsayımları belirt (roller, auth durumu)."
• Yanlış pozitif kontrolü: "Bu bulguyu çürütecek ne olur? 2–3 kontrol listesi ver: konfigürasyon bayrakları, middleware sırası, allowlist validasyonu, parametreli sorgular, framework kaçırmaları. Eğer herhangi biri varsa, riskin neden değiştiğini açıkla."
• En küçük güvenli düzeltme + test: "Sorunu engelleyen en küçük değişikliği öner ve geçerli vakaları bozmadan bunu sun. Sonra eklenecek bir testi yaz (isim, amaç, girdiler, beklenen sonuç). Varsa takasları açıkla."

Çıktı hâlâ belirsizse, somutlaştırın:

"Sadece şu şekilde cevap ver: dosya yolu, fonksiyon adı, riskli satır ve bir cümlelik etki."

Gerçekçi bir örnek: bir sezgiyi doğrulanmış bir soruna dönüştürmek

Profil güncelleme endpoint'leri genellikle erişim kontrolü hatalarını gizler. Aşağıda bu kontrol listesini izleyebileceğiniz küçük bir vaka var.

Senaryo: bir API endpoint kullanıcı profilini güncelliyor:

PATCH /api/profile?accountId=123 JSON gövdesi { "displayName": "Sam" } gibi.

Claude Code'dan handler'ı bulmasını, accountIdin nasıl kullanıldığını takip etmesini ve sunucunun sahipliği zorunlu kılıp kılmadığını kanıtlamasını istersiniz.

Sık görülen durumlar:

• Authn: istek bir oturum veya token gerektiriyor, bu yüzden korunmuş gibi görünür.
• Authz: handler sorgu stringinden gelen accountIde güveniyor ve bunun oturumdaki kullanıcıyla eşleşip eşleşmediğini kontrol etmeden hesabı güncelliyor.
• Girdi doğrulama: displayName kırpılıyor, ama accountId tamsayı olarak doğrulanmıyor.
• Enjeksiyon yüzeyi: SQL "... WHERE account_id=" + accountId gibi string birleştirmeyle oluşturuluyor.

İyi bir yazım somut olmalı:

• Şiddet: Yüksek (IDOR + olası SQL enjeksiyonu)
• Kanıt: Geçerli bir oturumla başka bir hesabın accountIdsi ile bir istek gönderildiğinde değişiklik oluyor; SQL güvensiz girdiyle oluşturuluyor
• Düzeltme: istemci tarafındaki accountIdi yok say, sunucuda doğrulanmış kullanıcının account id'sini kullan; sorguyu parametreleştir
• Test: başka bir hesabı güncelleme denemesi 403 dönmeli; sayısal olmayan accountId reddedilmeli

Düzeltme sonrası hızlı tekrar kontrol:

• Aynı istek farklı accountId ile başarısız olmalı.
• Loglarda sunucunun sorgu parametresi olarak doğrulanmış id'yi kullandığı görülmeli, istek parametresi değil.
• Sorgunun placeholder/parametre ile yapıldığı doğrulanmalı, string birleştirme olmamalı.
• Kötü giriş için bir negatif test (harfler, çok büyük sayı) çalıştırılmalı.

Spot-taramaların gerçek sorunları kaçırmasına neden olan yaygın tuzaklar

Hızlıca bir zafiyeti kaçırmanın en hızlı yolu UI'nın uyguladığı kısıtlamalara güvenmektir. Bir düğme gizlenmiş veya devre dışı bırakılmış olabilir; bu bir izin kontrolü değildir. Sunucu isteği yine kabul ediyorsa, herhangi biri farklı bir kullanıcı kimliği, farklı bir rol veya doğrudan API çağrısıyla bunu tekrar oynatabilir.

Bir diğer yaygın kaçırma nedeni ise belirsiz istek. "Bir güvenlik incelemesi yap" genellikle genel bir rapor üretir. Spot-taraması sıkı bir kapsam (hangi endpoint'ler, hangi roller, hangi veri) ve katı bir çıktı formatı (dosya adı, fonksiyon, riskli satır, minimal repro) gerektirir.

Aynı kural AI çıktısına da uygulanır: iddia somut kod konumu ve tetikleme adımlarını içermiyorsa, kanıtlanmamış sayın.

Spot-taramaların sapmasına neden olan hızlı yollar

Bu tuzaklar tekrar tekrar ortaya çıkar:

• Bir sayfayı "sadece admin" diye varsaymak, sunucunun bunu zorunlu kıldığı anlamına gelmez
• Geniş kapsamlı sonuçlar istemek yerine "X'i atlatan tam isteği göster" demek
• "Olası SQL enjeksiyonu" demek ama sorgunun nasıl oluşturulduğu ve girdinin yolunu belirtmemek
• Webhook'lar, zamanlanmış işler, içe aktarma araçları ve dahili admin eylemleri gibi daha az belirgin giriş noktalarını atlamak
• Her yeni kenar durumu için filtreler ekleyerek semptomları yamalamak; kök neden genelde daha erken ve basit bir validasyon veya yetkilendirme eksikliğidir

Eğer her yeni kenar için daha fazla filtre ekliyorsanız, durun. Düzeltme genellikle daha erkendir: sınırda girdileri doğrulayın ve yetkilendirme kontrollerini açık ve merkezi yapın ki her yol onları kullansın.

Sevk etmeden önce çalıştırabileceğiniz hızlı kontroller

Bunlar tam bir incemenin yerine geçmez, ama herkes yorgunken kaçan hataları yakalar. Kanıtlanabilir olana odaklanın: gönderebileceğiniz bir istek, yükleyebileceğiniz bir sayfa, bulabileceğiniz bir log satırı.

Genelde işe yarayan beş hızlı kontrol:

• Authn sürtüşmesi: Ardışık 10 kötü giriş deneyin. Hız sınırlaması, kilitleme veya en azından bir yavaşlama görüyor musunuz? Bir e-postanın var olup olmadığını hata mesajlarından veya zamanlamadan anlayabiliyor musunuz?
• ID değiş tokuşuyla yetkilendirme testi: Gerçek bir kaynak seçin (sipariş, fatura, profil). URL'deki, JSON gövdesindeki veya GraphQL değişkenlerindeki ID'yi değiştirin. Size ait olmayan verileri alıyor musunuz, hatta sadece "metadata" bile olsa?
• Girdi korumaları: Temel alanlar (email, isim, arama, dosya yükleme) için çok uzun stringler, garip Unicode ve beklenmeyen tipler deneyin (sayı yerine string). Uzunluk sınırları ve gerekli olan yerlerde allowlist var mı?
• Gizli sızıntısı: Son loglar ve istemci paketlerinde token, API anahtarı, JWT veya "Authorization: Bearer" arayın. Hata sayfalarını da kontrol edin. "Sadece staging'deydi" genelde "gönderdik" olur.
• Enjeksiyon yüzeyleri: SQL, filtreleme, şablon render, shell komutları veya yönlendirme URL'lerine string birleştirme yapan kodları arayın. Girdi bu noktalara güçlü validasyon olmadan ulaşırsa risk varsayın.

Bu hafta sevk edilebilecek en iyi 3 düzeltmeyi yazın, hayal listesi değil. Örnek: (1) giriş ve şifre sıfırlama için hız sınırlaması ekle, (2) "id ile getir" endpoint'inde sunucu tarafı sahiplik kontrollerini zorunlu kıl, (3) arama alanı için giriş uzunluğunu sınırla ve beklenmeyen karakterleri reddet.

Sonraki adımlar: bu kontrol listesini yapım sürecinizin bir parçası yapın

Bir spot-taraması, sonuçlar gönderdiğiniz şeyi değiştirmiyorsa işe yaramaz. Bu kontrol listesini küçük, tekrarlanabilir bir yapım adımı olarak değil, tek seferlik kurtarma görevinden ziyade ele alın.

Her bulguyu anlaşılır bir backlog öğesine dönüştürün:

• Düzeltme: kod veya konfigürasyonda ne değişecek
• Test: bunun düzeldiğini kanıtlayacak bir istek, bir unit testi veya bir QA adımı
• Sahip: sorumlu tek bir kişi
• Hedef tarih: bir sonraki sürüm veya belirli bir gün
• Kanıt: dosya/endpoint ve sorunu gösteren tam istek veya yük

Risk ve takım büyüklüğüne göre bir ritim seçin. Birçok ekip için her sürüm en iyisidir. Eğer sürümler sık ise, aylık 30–60 dakikalık bir inceleme ve sevk öncesi daha kısa bir kontrol yapın.

Tekrar etmeyi kolaylaştırmak için yeniden kullanılabilir bir prompt paketi ve kontrol listesi şablonu oluşturun. Promptları somut çıktılara odaklı tutun: route'u göster, korumayı göster, başarısız isteği göster ve beklentiyi yaz. Paketi ekibin zaten çalıştığı yerde saklayın ki atlanmasın.

Eğer sohbet üzerinden uygulama inşa ediyorsanız, planlamaya kontrol listesini ekleyin. Authn/authz, girdiler ve gizliler için kısa bir "güvenlik varsayımları" notu ekleyin ve ilk çalışan sürümden hemen sonra spot-taramayı çalıştırın.

Koder.ai (koder.ai) gibi platformlar bu alışkanlığa iyi uyabilir çünkü hızlı yineleme ve inceleme noktaları sağlar. Snapshot ve rollback kullanmak, bir güvenlik düzeltmesi davranışı bozduğunda düzeltmeyi göndermeyi kolaylaştırır.