Siber Güvenlik ve Veri Koruma
Web ve Mobil Uygulamalarda Güvenlik Testi Planlama
Web ve mobil uygulamalarda güvenlik testinin kapsamını belirleyin, uygun yöntemleri seçin ve bulguların düzeltilmesinden yeniden teste kadar uygulanabilir bir plan oluşturun.
Güvenlik testi yalnızca yayın öncesi bir kontrol değildir
Uygulama güvenlik testi, bir tarama aracını çalıştırmakla başlamaz. Önce hangi uygulamanın, hangi riskler açısından ve hangi koşullarda değerlendirileceği belirlenir. Ardından uygun yöntemler seçilir, bulgular iş etkisiyle birlikte ele alınır ve düzeltmeler yeniden sınanır. Planın başarısı, bulunan açık sayısından çok, sonuçların uygulanabilir geliştirme görevlerine dönüştürülmesine bağlıdır.
Web ve mobil uygulamalarda güvenlik değerlendirmesi, proje takviminden ayrı düşünülmemelidir. Kimlik doğrulama, kullanıcı yetkileri, hassas verilerin işlenmesi ve dış sistem bağlantıları tasarım aşamasında konuşulmalıdır. Geliştirme sırasında yapılan kontroller, yayın öncesi sızma testinin yerini tamamen tutmaz; ancak sorunların daha erken fark edilmesine yardımcı olur.
Uygulanabilir bir plan; kapsamı, test yaklaşımını, çalışma kurallarını, raporlamayı ve yeniden testi birbirine bağlar. Ürün sahibi, yazılım ekibi ve testi yürüten taraf aynı hedeflere göre hareket eder. Testin neyi kapsamadığı da açıkça yazılmalıdır. Sonuçlar, yalnızca değerlendirilen sürüm, kapsam ve koşullar için yorumlanabilir; uygulamanın her durumda güvenli olduğunu göstermez.
Öne çıkanlar
Kapsamı varlıklara ve iş akışlarına göre belirleyin
Test kapsamı yalnızca uygulamanın adresi veya mağaza bağlantısıyla tanımlanamaz. Kullanıcı rolleri, API uç noktaları, yönetim ekranları, veri akışları ve entegrasyonlar birlikte ele alınmalıdır. Aynı altyapıyı kullanan web ve mobil istemcilerde ortak servislerin dışarıda bırakılması, değerlendirmede önemli bir boşluk oluşturabilir. Envanteri test ekibinin erişebileceği alanlarla karşılaştırın. Ürün bilgisi, teknik envanterin neden önemli olduğunu açıklar. Müşteri verisi, ödeme akışı veya kuruluşlar arası veri paylaşımı içeren işlevleri ayrıca işaretleyin. Kapsam dışı bileşenleri ve dışarıda bırakılma gerekçelerini kaydedin. Test başlangıcında belgeyi güncel sürümle karşılaştırın; sonradan eklenen bir yönetim ekranı ya da entegrasyon, erişim modelini ve çalışma planını değiştirebilir. Kapsamı belirlerken yalnızca görünür ekranlara bakmayın. Arka planda çalışan görevler, veri dışa aktarma işlemleri ve yönetim araçları da kritik verilere erişebilir. Test hesaplarının bu işlevleri kullanabilmesi gerekir. Erişilemeyen bir alanı sessizce kapsamdan düşürmek yerine kısıtı ve değerlendirmeye etkisini açıkça belirtin. Böylece raporun kapsadığı alanlar doğru anlaşılır.
Uygulama ve servis envanteri
Alan adlarını, API servislerini, yönetim panellerini, mobil paketleri ve sürümlerini kaydedin.
Roller ve erişim sınırları
Standart kullanıcı, yönetici ve farklı kuruluş hesapları arasındaki yetki ayrımını tanımlayın.
Kritik iş akışları
Hesap açma, parola yenileme, ödeme, dosya yükleme ve veri dışa aktarma süreçlerini iş etkisine göre işaretleyin.
Harici bağımlılıklar
Üçüncü taraf servislerde kurumunuzun kontrol ettiği bileşenleri ve izin verilen test sınırlarını ayırın.
Uygulama süreci
Test ortamını ve çalışma kurallarını hazırlayın
Güvenlik testinin kendisi de operasyonel risk oluşturabilir. Yazılı yetkilendirme, izin verilen faaliyetler ve durdurma koşulları başlangıçta netleştirilmelidir. Test ortamı kullanılıyorsa üretimle arasındaki sürüm ve yapılandırma farkları kaydedilmelidir. Güvenli görünen bir test ortamı, gerçek kullanıcıların eriştiği sistemi temsil etmeyebilir. Canlı ortamda yapılacak kontrolleri ayrıca değerlendirin ve ilgili ekiplerle koordine edin. Test hesaplarını, erişim bilgilerini ve teknik belgeleri güvenli kanallardan paylaşın. Erişim sorunları için bir iletişim sorumlusu belirleyin. Canlı ortamı etkileyebilecek faaliyetlerde işlem sahiplerini ve gerektiğinde dış servis sorumlularını bilgilendirin. Amaç testi gereksiz biçimde sınırlamak değil, beklenmeyen bir durumda kimin hangi kararı vereceğini önceden belirlemektir. Test verisinin hazırlanması da bu aşamanın parçasıdır. Mümkün olduğunda gerçek kişisel veri yerine uygun örnek kayıtlar kullanın. Farklı yetki düzeylerini temsil eden hesaplar ve birbirinden ayrılmış kuruluş verileri hazırlayın. Bu düzen, erişim sınırlarının anlaşılmasını kolaylaştırır ve kanıt toplarken gereksiz hassas veri kullanımını azaltır. Ortam hazır değilse eksikleri çalışma başlamadan görünür hâle getirin.
- 01
Yetki ve sınırları yazılılaştırın
Hedef sistemleri, kapsam dışı varlıkları ve hizmeti etkileyebilecek işlemlere ilişkin kısıtları belgeleyin.
- 02
Ortamı kontrol edin
Sürümü, erişim modelini ve yapılandırmaları doğrulayın; mümkün olduğunda gerçek kişisel veri yerine test verisi kullanın.
- 03
Müdahale düzenini belirleyin
Kritik bulgu bildirim kanalını, testi durdurabilecek kişiyi ve çalışma sonrası temizlik sorumlularını netleştirin.
Karşılaştırma
Tarama, kod incelemesi ve sızma testini birlikte düşünün
Bilinen hata örüntülerini ve yapılandırma sorunlarını işaretler.
Manuel doğrulama gerektirir; temiz sonuç, tam güvenlik anlamına gelmez.
Yetki kontrollerinin ve veri işlemenin nasıl uygulandığını inceler.
Kod erişimi ve teknik bağlam gerektirir; çalışma ortamındaki etkiler ayrıca sınanmalıdır.
Yetkisiz erişim ve iş akışı kötüye kullanımı gibi senaryoları değerlendirir.
Tanımlı kapsamla sınırlıdır; bütün olası saldırıların bulunmasını garanti etmez.
Öne çıkanlar
Web ve mobil uygulamaların farklı risklerini değerlendirin
Web uygulamalarında oturum yönetimi, sunucu tarafı yetkilendirme, kullanıcı girdileri ve tarayıcıya gönderilen veriler öne çıkar. Mobil uygulamalarda cihazdaki veri saklama, uygulama izinleri ve istemciye gömülen hassas bilgiler de incelenir. Mobil istemciyi bağlı olduğu API servislerinden bağımsız değerlendirmeyin. Ekranda bir düğmenin gizlenmesi, sunucunun yetkisiz işlemi reddettiğini göstermez. Senaryoları ürünün gerçek kullanımına göre oluşturun. Çevrimdışı çalışan bir saha uygulamasıyla ödeme alan bir web uygulamasının öncelikleri aynı değildir. Ortak altyapıyı kullanan kuruluşlar arasında veri ayrımını özellikle inceleyin. Kullanıcının kendi kaydını okuması, başkasının kaydını okuması ve kayıtları değiştirmesi ayrı yetki sorularıdır. Bunları uygun hesaplar ve örnek kayıtlarla sınayın. Normal kullanım adımlarının yanında rol değişimlerini ve beklenmeyen işlem sıralarını da değerlendirin. İstemciden gelen bir değerin sunucuda yeniden kontrol edilip edilmediği önemlidir. Mobil uygulamada yerel olarak saklanan bilgi, günlük kayıtlarına veya yedeklere taşınabilir. Kanıtları rapora aktarırken bulguyu açıklamaya yetecek bilgiyi koruyun, gereksiz hassas ayrıntıları çıkarın.
Kimlik ve oturum
Giriş, hesap kurtarma, oturum sonlandırma ve erişim belirteçlerinin yaşam döngüsünü değerlendirin.
Yetkilendirme
Hesap, rol ve kuruluş sınırlarının sunucu tarafında uygulandığını sınayın.
Mobil veriler
Yerel depolamayı, günlükleri, yedeklere taşınan içeriği ve uygulama izinlerinin gerekliliğini inceleyin.
API ve iş mantığı
İstemci verisine duyulan güveni, beklenmeyen işlem sıralarını ve entegrasyon yetkilerini değerlendirin.
Uygulama süreci
Kontrolleri geliştirme takvimine yerleştirin
Testi yayın tarihine yakın tek bir görev olarak eklemek, düzeltmelere zaman bırakmayabilir. Tasarım incelemesini geliştirme öncesinde, kod ve bağımlılık kontrollerini geliştirme sırasında, kapsamlı değerlendirmeyi ise test edilebilir sürüm oluştuğunda planlayın. Takvimde bulguların giderilmesi ve yeniden test için de yer ayırın. Bu işleri ürün planında görünür tutun. Her değişiklik aynı derinlikte değerlendirme gerektirmez. Yeni bir kimlik sistemi, dosya yükleme özelliği veya entegrasyon, görsel bir düzenlemeden farklı risk taşır. Otomatik kontrollerin geçmesi, manuel inceleme ihtiyacını kendiliğinden ortadan kaldırmaz. Yayın kararında testin tamamlanmasının yanı sıra açık bulguları değerlendirin; kabul edilen riskleri gerekçesi ve sorumlusuyla kaydedin. Yayın ölçütlerini son aşamaya bırakmayın. Ürün sahibi ve teknik ekip, hangi risklerin yayını engelleyeceğini ve hangi durumlarda geçici önlemle ilerlenebileceğini önceden konuşmalıdır. Ertelenen düzeltmeler için takip sorumlusu ve yeniden değerlendirme koşulu belirleyin. Önceki test sonucunu yeni sürümlere olduğu gibi taşımak yerine, değişikliğin güvenlik etkisini yeniden gözden geçirin.
- 01
Tasarımda başlayın
Veri akışlarını, erişim modelini ve olası kötüye kullanım senaryolarını gözden geçirin.
- 02
Geliştirmede sürdürün
Kod, bağımlılık ve gizli bilgi kontrollerini akışa dahil edin; kritik alanları ayrıca inceleyin.
- 03
Yayın ve değişiklikleri değerlendirin
Açık riskleri yayın kararıyla ilişkilendirin; yeni işlevler için yeniden test ihtiyacını belirleyin.
Kontrol listesi
Bulguları teknik önem ve iş etkisiyle önceliklendirin
Bulgunun önceliğini yalnızca tarama aracının etiketiyle belirlemeyin. Açığın erişilebilirliğini, kötüye kullanım koşullarını, etkilediği veriyi ve mevcut koruyucu kontrolleri birlikte değerlendirin. İnternete açık bir yetkilendirme sorunu ile sınırlı bir yönetim ortamındaki yapılandırma eksikliği farklı öncelikler taşıyabilir. Teknik önem ve düzeltme sırası ilişkili olsa da aynı şey değildir. Doğrulanmış her bulguyu, görev sahibi ve açık kabul ölçütüyle geliştirme sürecine aktarın. Kritik riskleri rutin rapor teslimini beklemeden bildirin. Düzeltme erteleniyorsa gerekçeyi, geçici önlemi ve yeniden değerlendirme koşulunu kaydedin. Bulguların birbirleriyle ilişkisini de inceleyin; tek başına sınırlı görünen bir hata, başka bir açıkla birleştiğinde daha önemli hâle gelebilir. Rapor, geliştiricinin sorunu anlamasını ve düzeltmenin sonucunu sınamasını desteklemelidir. Etkilenen işlevi, gerekli koşulları ve gözlenen davranışı açıkça yazın. Düzeltme önerisini mümkün olduğunda kök nedenle ilişkilendirin. Yalnızca belirtiyi ortadan kaldıran bir değişiklik, benzer işlevlerde aynı sorunun devam etmesine yol açabilir. Bu nedenle ilişkili alanları da değerlendirme gündemine alın.
- ✓
Kanıt tekrarlanabilir mi?
Etkilenen işlevi, gerekli koşulları ve gözlenen sonucu geliştiricinin anlayabileceği biçimde açıklayın.
- ✓
İş etkisi açık mı?
Veri ifşası, yetkisiz işlem veya hizmet aksamasının uygulamanızdaki karşılığını belirtin.
- ✓
Sorumlu ve kapanış koşulu belli mi?
Düzeltmeyi üstlenecek ekibi ve yeniden testte doğrulanacak davranışı görevde yazın.
Kontrol listesi
Hizmet tekliflerini kapsam ve teslimatlar üzerinden karşılaştırın
Güvenlik testi tekliflerini yalnızca fiyat veya araç listesi üzerinden karşılaştırmayın. Varlıklar, kullanıcı rolleri, manuel değerlendirme kapsamı ve rapor içeriği açıkça tanımlanmalıdır. Kod incelemesinin ayrı bir çalışma olup olmadığını ve düzeltme sonrası doğrulamanın teklife dahil edilip edilmediğini sorun. Genel bir güvenlik vaadi yerine değerlendirilecek soruları ve sunulacak çıktıları arayın. Görüşmeye temel mimari, kullanıcı rolleri, kritik iş akışları ve test ortamı bilgileriyle hazırlanın. Kaynak kod erişimini, dış sistem izinlerini ve yayın planını paylaşın. Bu bilgiler, kapsamın geliştirme takvimine uygun kurulmasını kolaylaştırır. Belirsiz noktaları çalışma başlamadan açıklığa kavuşturun; erişilemeyen alanların ve kapsam dışı işlevlerin nasıl raporlanacağını öğrenin. Teklifte raporun kimlerle paylaşılacağı, önemli bulguların nasıl bildirileceği ve teknik soruların nasıl ele alınacağı da yer almalıdır. Test kanıtlarının korunması ve çalışma sonunda erişimlerin kaldırılması, teslimat kadar önemlidir. Yeniden testin kapsamını baştan konuşmak, rapor tesliminden sonra hangi bulguların nasıl doğrulanacağına ilişkin belirsizliği azaltır.
- ✓
Kapsam ve yöntem
Web, mobil, API ve yönetim bileşenlerinin hangilerinin, hangi yöntemlerle değerlendirileceğini sorun.
- ✓
Rapor ve iletişim
Kanıt, iş etkisi, düzeltme önerisi ve kritik bulgu bildirim yaklaşımını netleştirin.
- ✓
Yeniden test ve veri yönetimi
Doğrulama sınırlarını, kanıtların korunmasını ve test erişimlerinin kaldırılmasını değerlendirin.
Uygulanabilir bir çalışma planıyla başlayın
Önce mevcut varlıkları ve kritik iş akışlarını çıkarın. Ardından test hedeflerini, erişim ihtiyaçlarını ve ortam koşullarını belirleyin. Yöntemleri geliştirme takvimine yerleştirin; bulgulara sorumlu atayın ve yeniden testi planın zorunlu bir parçası yapın. Böylece rapor, yalnızca arşivlenen bir belge değil, ürün kalitesini geliştiren bir çalışma çıktısı olur.
Bikare ile ihtiyaçlarınızı değerlendirirken sızma testi, güvenli kod incelemesi ve bulgu doğrulama beklentilerinizi keşif gündemine taşıyabilirsiniz. Bu çalışmaların kapsamı ve uygunluğu ayrıca netleştirilmelidir. [Siber güvenlik ve erişim yönetimi](/siber-guvenlik-ve-erisim-yonetimi) üzerinden ihtiyaçlarınızı ele alabilir; yeni projelerde [web uygulama geliştirme](/web-uygulama-gelistirme) ve [mobil uygulama geliştirme](/mobil-uygulama-gelistirme) süreçleriyle test planının ilişkisini değerlendirebilirsiniz.
İlk görüşmeye güncel envanter, rol listesi, kritik veri akışları ve yayın planıyla gelin. Hedef, belirsiz bir güvenlik vaadi değil; neyin değerlendirileceği, hangi çıktıların alınacağı ve sorunların nasıl kapatılacağı konusunda ortak bir plandır. Uygulama değiştikçe bu planı güncelleyin ve önceki test sonuçlarını yeni sürümlere otomatik olarak taşımayın. Bu yaklaşım, değerlendirmeyi uygulamanın gerçek durumuyla bağlantılı tutar.
Keşfetmeye devam et
İlgili içerik ve hizmetler
Konuyu tamamlayan Bikare içeriklerine göz atın.
