Bir mobil uygulama; telefon numarası, konum, cihaz bilgisi, ödeme hareketi, mesaj içeriği, profil fotoğrafı, sağlık verisi veya alışveriş geçmişi gibi birçok kullanıcı verisine temas edebilir. Kullanıcı uygulamayı açtığında yalnızca arayüzü görür; arka tarafta ise cihaz, API, veritabanı, üçüncü parti servisler, bildirim altyapısı ve yönetim paneli arasında sürekli veri akışı vardır.
Mobil uygulamalarda kullanıcı verisi korunacaksa mesele tek bir “güvenlik eklentisi” ile çözülmez. Koruma; ürün fikrinin ilk keşif toplantısından App Store / Google Play yayın sürecine, oradan da bakım dönemine kadar tasarlanmalıdır.
Atalay Tech’te mobil uygulama, web platformu, yönetim paneli ve AI entegrasyonu projelerinde en kritik gördüğümüz nokta şudur: Güvenlik sonradan eklenen bir katman değil, mimarinin kendisidir. Özellikle üyelik, ödeme, mesajlaşma, dosya yükleme, konum, bildirim ve yönetim paneli içeren projelerde kullanıcı verisinin nasıl toplandığı, nerede saklandığı, kimlerin eriştiği ve ne zaman silindiği netleşmeden sağlıklı bir ürün geliştirme süreci kurulamaz.
Bu rehber, mobil uygulama geliştirme sürecinde kullanıcı verisinin teknik, yasal ve operasyonel olarak nasıl korunması gerektiğini anlatır. Amaç satış sayfası gibi konuşmak değil; mobil uygulama fikri olan kurucu, ürün yöneticisi veya teknik ekip için uygulanabilir bir güvenlik çerçevesi sunmaktır.
Kullanıcı verisi yalnızca “ad, soyad, e-posta” değildir. Mobil uygulama tarafında veri; kullanıcının kim olduğunu, nasıl davrandığını, ne satın aldığını, nerede bulunduğunu veya hangi cihazdan eriştiğini gösteren her parçayı kapsayabilir.
Örneğin bir pazar yeri uygulamasında kullanıcı verisi; alıcı profili, satıcı bilgisi, ürün favorileri, ödeme geçmişi, teslimat adresi, destek talepleri ve cihaz bildirimi token’larından oluşur. Bir sosyal ağ uygulamasında ise mesaj içerikleri, bağlantılar, gönderiler, beğeniler, profil fotoğrafları ve şikayet kayıtları veri kapsamına girer.
Mobil uygulamalarda veri türleri genellikle şu şekilde ayrılır:
| Veri Türü | Örnek | Risk Seviyesi | Koruma Yaklaşımı |
|---|---|---|---|
| Kimlik verisi | Ad, soyad, e-posta, telefon | Yüksek | Minimum toplama, doğrulama, erişim kısıtı |
| Finansal veri | Ödeme kaydı, fatura bilgisi, işlem geçmişi | Çok yüksek | PCI uyumlu ödeme sağlayıcı, tokenizasyon |
| Konum verisi | Anlık konum, teslimat adresi | Yüksek | Açık izin, süreli erişim, hassas log engeli |
| Cihaz verisi | Device ID, push token, işletim sistemi | Orta | Pseudonymization, güvenli saklama |
| İçerik verisi | Mesaj, yorum, dosya, fotoğraf | Yüksek | Yetkilendirme, moderasyon, erişim denetimi |
| Analitik verisi | Ekran görüntüleme, tıklama, oturum süresi | Orta | Anonimleştirme, açık beyan, veri minimizasyonu |
Buradaki kritik ayrım şudur: Her veri aynı hassasiyette değildir. Kullanıcının profil rengi tercihi ile kimlik numarası aynı güvenlik sınıfına konulamaz. Sağlam mimari, veriyi önem derecesine göre sınıflandırır ve her sınıfa farklı koruma uygular.
Türkiye’de kullanıcı verisi denildiğinde akla doğal olarak KVKK uyumluluğu gelir. Kişisel Verileri Koruma Kurumu’nun resmi kaynaklarında da veri işleme, aydınlatma, ihlal bildirimi ve kurul kararları gibi başlıklar düzenli olarak ele alınır: KVKK resmi sitesi.
Fakat mobil uygulama güvenliği yalnızca metin onayı almakla tamamlanmaz. Kullanıcıya “aydınlatma metnini kabul ediyorum” kutusu göstermek, veri akışınız güvensizse tek başına yeterli değildir.
Bir örnek düşünelim:
Ayşe, 28 yaşında freelance tasarımcı. Bir görev yönetimi uygulamasına üye oluyor, profil fotoğrafı yüklüyor, ekip arkadaşlarını davet ediyor ve dosya paylaşımı yapıyor. Uygulama KVKK metni gösteriyor ama dosyalar tahmin edilebilir URL’lerle herkese açık tutuluyor. Bu durumda hukuki metin var gibi görünür; fakat teknik veri koruma zayıftır.
Gerçek koruma için üç katman birlikte çalışmalıdır:
Kullanıcı verisini güçlü biçimde koruyan ekipler, bu üç katmanı birbirinden koparmaz. KVKK metni ürünün dış yüzü ise güvenli mimari ürünün omurgasıdır.
Mobil uygulamalarda veri sızıntısı çoğu zaman “çok gelişmiş saldırı” nedeniyle değil, basit ihmal zinciri nedeniyle oluşur. Özellikle hızlı MVP çıkarma baskısı altında bazı ekipler güvenlik kararlarını sonraya bırakır. Bu yaklaşım, ürün büyüdükçe teknik borcu ve hukuki riski artırır.
Aşağıdaki tablo, mobil uygulamalarda sık görülen veri güvenliği hatalarını ve doğru yaklaşımı özetler:
| Hata | Gerçekçi Senaryo | Olası Sonuç | Doğru Yaklaşım |
|---|---|---|---|
| Gereksiz izin istemek | Not uygulaması konum izni ister | Kullanıcı güveni düşer | İzinleri özellik bazlı istemek |
| Token’ı düz saklamak | Access token AsyncStorage içinde korunmasız tutulur | Oturum ele geçirilebilir | Secure storage / keychain kullanmak |
| API yetkisini eksik yapmak | Kullanıcı başka kullanıcının siparişini ID değiştirerek görür | Kişisel veri ihlali | Backend tarafında ownership kontrolü |
| Loglarda veri tutmak | Hata loguna telefon, adres, token yazılır | İç ekip veya servis sızıntısı | Hassas log maskeleme |
| Dosyaları açık URL ile sunmak | Profil evrakları public bucket’ta durur | Yetkisiz erişim | Signed URL ve süreli erişim |
| Üçüncü parti SDK’yı kontrol etmemek | Analitik SDK fazla veri toplar | Yanlış beyan / veri paylaşımı | SDK veri envanteri çıkarmak |
| Testi yalnızca fonksiyonel yapmak | “Buton çalışıyor mu?” test edilir, yetki testi yapılmaz | Güvenlik açığı yayına çıkar | Güvenlik test senaryosu yazmak |
Atalay Tech projelerinde özellikle API yetkilendirme, dosya erişimi, yönetim paneli rol sistemi ve bildirim token yönetimi gibi noktalar erken aşamada netleştirilir. Çünkü bu alanlar ürün büyüdüğünde değiştirilmesi en maliyetli alanlardır.
Mobil uygulamalarda kullanıcı verisini korumanın en güçlü yolu, gereksiz veriyi hiç toplamamaktır. Buna veri minimizasyonu denir.
Bir spor salonu rezervasyon uygulaması düşünelim. Kullanıcıdan ad, telefon, üyelik tipi ve rezervasyon saati alınması yeterliyken T.C. kimlik numarası, açık adres ve doğum tarihi isteniyorsa gereksiz risk üretilir. Ürün ekibi “ileride lazım olabilir” diye veri topladığında, aslında ileride korunması, açıklanması ve silinmesi gereken ek yük oluşturur.
Veri minimizasyonu için pratik kontrol listesi:
Örneğin bir teslimat uygulamasında konum verisi operasyon için kritik olabilir. Fakat her 5 saniyede arka planda konum almak yerine, yalnızca teslimat aşamasında ve kullanıcıya açık şekilde konum erişimi almak daha sağlıklı bir yaklaşımdır.
Google Play tarafında geliştiriciler, uygulamanın hangi kullanıcı verilerini topladığını ve paylaştığını Data safety form üzerinden beyan eder. Google’ın resmi açıklamasına göre bu form, kullanıcılara uygulamanın hangi veri türlerini topladığını ve paylaştığını göstermek için kullanılır: Android Developers Data Safety.
Apple tarafında da App Privacy Details, uygulamanın hangi verileri topladığını ve bu verilerin nasıl kullanıldığını kullanıcılara açıklamayı hedefler: Apple App Privacy Details.
Mobil uygulamalarda izin yönetimi hem güvenlik hem dönüşüm oranı açısından kritiktir. Kullanıcı uygulamayı ilk açtığında kamera, mikrofon, konum, bildirim ve rehber izni aynı anda istenirse güven düşer. Daha kötüsü, kullanıcı izni reddeder ve uygulamanın temel akışı bozulur.
Doğru yaklaşım, izni bağlam içinde istemektir.
Örneğin:
Aşağıdaki tablo, izinlerin nasıl ele alınması gerektiğini gösterir:
| İzin | Yanlış Kullanım | Doğru Kullanım | Kullanıcıya Açıklama |
|---|---|---|---|
| Konum | İlk açılışta zorunlu istemek | Harita veya teslimat anında istemek | “Yakındaki seçenekleri göstermek için” |
| Kamera | Üyelik ekranında istemek | Profil fotoğrafı veya belge yükleme anında istemek | “Fotoğraf çekebilmek için” |
| Mikrofon | Uygulama açılışında istemek | Sesli görüşme başlarken istemek | “Görüşme başlatmak için” |
| Bildirim | Onboarding başında zorlamak | Kullanıcı değer gördükten sonra istemek | “Sipariş ve mesaj bildirimleri için” |
| Rehber | Tüm rehberi almak | Davet akışında opsiyonel istemek | “Arkadaş daveti için” |
İzin ekranı yalnızca teknik bir popup değildir. Kullanıcının uygulamaya duyduğu güvenin ilk temas noktalarından biridir. Kısa, anlaşılır ve bağlama uygun açıklama dönüşüm oranını yükseltirken veri gizliliği algısını da güçlendirir.
Mobil uygulama cihazda çalışır; ama kullanıcı verisinin büyük kısmı backend ve API tarafında korunur. Bu yüzden API entegrasyonu yalnızca “mobil uygulama backend’e bağlansın” işi değildir. Doğru kimlik doğrulama, yetkilendirme, rate limit, loglama, hata yönetimi ve veri doğrulama birlikte tasarlanmalıdır.
En yaygın risklerden biri, mobil uygulamada görünen ID değerlerine fazla güvenmektir. Örneğin kullanıcı /orders/125 isteğini gönderdiğinde backend yalnızca “125 numaralı sipariş var mı?” diye bakarsa hata yapar. Backend ayrıca “bu sipariş bu kullanıcıya mı ait?” kontrolünü de yapmalıdır.
Güvenli API için temel ilkeler:
OWASP Mobile Application Security Verification Standard, mobil yazılım mimarları, geliştiriciler ve güvenlik test ekipleri için mobil uygulama güvenliğini değerlendirmeye yönelik sektör standardı olarak konumlanır: OWASP MASVS.
Bu standart, özellikle kimlik doğrulama, veri saklama, kriptografi, ağ iletişimi, platform etkileşimi ve kod kalitesi gibi alanlarda referans çerçeve sunar. Mobil uygulama büyüdükçe bu tip standartlara göre kontrol yapmak, “gözden kaçan küçük açıkların” büyük veri riskine dönüşmesini engeller.
Mobil uygulamalarda bazı veriler cihaz üzerinde saklanır. Bu, kullanıcı deneyimi için gereklidir: Kullanıcı her açılışta tekrar giriş yapmak istemez, bazı ekranlar hızlı açılmalı, internet yokken belirli bilgiler görüntülenebilmelidir. Fakat cihaz tarafında saklanan her veri güvenlik riski taşır.
Özellikle şu alanlara dikkat edilmelidir:
React Native gibi cross-platform yapılarda token saklama konusu ayrıca önemlidir. Token’ı kolay erişilebilir düz metin depolama alanlarında tutmak yerine iOS Keychain ve Android Keystore tabanlı güvenli saklama çözümleri tercih edilmelidir. Native tarafta da platformun sunduğu güvenli depolama mekanizmaları kullanılmalıdır.
Offline kullanım gerekiyorsa, cache verisinin kapsamı net belirlenmelidir. Örneğin e-ticaret uygulamasında ürün listesi cache’lenebilir; fakat kullanıcının fatura adresi veya ödeme geçmişi cihazda uzun süre düz biçimde tutulmamalıdır.
Cihaz tarafında pratik koruma yaklaşımı:
| Veri | Cihazda Saklanır mı? | Saklama Yöntemi | Not |
|---|---|---|---|
| Access token | Evet, kısa süreli | Secure storage | Kısa ömürlü olmalı |
| Refresh token | Sınırlı | Keychain / Keystore | Cihaz değişiminde kontrol edilmeli |
| Ürün listesi | Evet | Cache | Hassas değilse uygun |
| Mesaj içeriği | Duruma göre | Şifreli local storage | Uçtan uca ihtiyaç ayrıca analiz edilmeli |
| Ödeme bilgisi | Hayır | Ödeme sağlayıcı token’ı | Kart verisi uygulamada tutulmamalı |
| Kimlik belgesi | Hayır / sınırlı | Sunucu + signed URL | Public URL kullanılmamalı |
Buradaki amaç uygulamayı kullanılmaz hale getirmek değildir. Amaç, kullanıcı deneyimi ile veri güvenliği arasında doğru dengeyi kurmaktır.
Şifreleme, mobil veri güvenliğinin en bilinen ama en yanlış anlaşılan konularından biridir. “Veritabanını şifreledik” demek tek başına yeterli değildir. Veri hareket halindeyken, saklanırken ve yedeklenirken farklı risklere sahiptir.
Temel ayrım şu şekildedir:
Örneğin bir sağlık randevu uygulamasında kullanıcının doktor notları, reçete dosyaları ve randevu geçmişi hassas veri sınıfına girer. Bu veriler yalnızca HTTPS ile gönderilmemeli; backend erişim izinleri, dosya erişim süreleri, log maskeleme ve yedekleme politikalarıyla da korunmalıdır.
Şifreleme kararları ürün tipine göre değişir:
| Uygulama Tipi | Hassas Veri | Kritik Koruma | Ek Önlem |
|---|---|---|---|
| E-ticaret | Adres, ödeme hareketi | HTTPS, ödeme tokenizasyonu | Sipariş ownership kontrolü |
| Sosyal ağ | Mesaj, profil, fotoğraf | Yetkilendirme, dosya erişimi | Şikayet ve moderasyon kaydı |
| Sağlık / randevu | Sağlık notu, belge | Güçlü erişim kontrolü | Hassas log engeli |
| Finans / cüzdan | Bakiye, işlem geçmişi | MFA, cihaz güveni | Risk skorlama |
| B2B saha uygulaması | Müşteri listesi, konum | Rol bazlı erişim | Cihaz kaybı senaryosu |
Şifreleme tasarımında önemli olan, kriptografiyi uygulamanın tek savunması gibi görmemektir. Zayıf yetkilendirme varsa şifreli veritabanı bile kullanıcı bazlı veri sızıntısını engelleyemez.
Mobil uygulamalar genellikle tek başına çalışmaz. Analitik, crash reporting, push notification, ödeme, harita, sosyal giriş, reklam ve müşteri destek SDK’ları ürüne dahil edilir. Bu servislerin her biri veri akışına yeni bir kapı ekler.
Örneğin bir mobil uygulama şu servisleri kullanabilir:
Her SDK için şu sorular sorulmalıdır:
Google Play Data safety ve Apple App Privacy beyanlarının doğru yapılması için yalnızca kendi kodunuzu değil, kullandığınız üçüncü taraf servisleri de bilmeniz gerekir. Akademik çalışmalarda da geliştiricilerin veri toplama beyanlarında zorlandığı, özellikle üçüncü taraf kod ve veri sınıflandırması nedeniyle hatalı raporlama riskleri oluştuğu gösterilmiştir: Android veri beyanı çalışması.
Bu yüzden mobil uygulama geliştirme sürecinde “SDK envanteri” çıkarılmalıdır. Hangi SDK neden kullanılıyor, hangi veriye erişiyor, hangi ekranda devreye giriyor ve hangi beyana konu oluyor netleştirilmelidir.
Kullanıcı verisi yalnızca mobil uygulamadan sızmaz. Yönetim paneli, müşteri temsilcisi ekranı, operasyon paneli veya destek ekibi erişimi de risk oluşturur.
Bir pazaryeri uygulamasında destek personeli sipariş detaylarını görebilir. Bir eğitim uygulamasında eğitmen öğrenci listesini görüntüleyebilir. Bir sağlık randevu sisteminde klinik personeli randevu notlarına erişebilir. Bu erişimler gerekli olabilir; ancak sınırsız olmamalıdır.
Rol bazlı erişim kontrolü burada devreye girer.
| Rol | Görmesi Gereken Veri | Görmemesi Gereken Veri | Ek Kontrol |
|---|---|---|---|
| Destek personeli | Sipariş durumu, destek talebi | Ödeme kartı, tam token | Erişim logu |
| Operasyon ekibi | Teslimat ve stok durumu | Kullanıcı özel mesajları | Rol bazlı panel |
| İçerik moderatörü | Şikayet edilen içerik | Finansal bilgiler | Kısıtlı görünüm |
| Yönetici | Raporlar, kullanıcı yönetimi | Gereksiz ham veri | MFA ve audit log |
| Geliştirici | Teknik hata logu | Açık kişisel veri | Maskelenmiş log |
Veri koruma mimarisinde yönetim paneli çoğu zaman mobil uygulama kadar önemlidir. Kullanıcı cihazındaki token güvenliyken admin paneli zayıf şifreyle korunuyorsa sistem yine risk altındadır.
Atalay Tech’in mobil uygulama ve web platformu projelerinde yönetim paneli genellikle ürünün kontrol merkezi olarak ele alınır. Kullanıcı, içerik, ödeme, bildirim, dosya, rapor ve destek süreçleri aynı panelden yönetildiğinde rol bazlı yetkilendirme erken aşamada tasarlanmalıdır.
Mobil uygulama testinde yalnızca ekranların çalışması yeterli değildir. Kullanıcı verisi korunacaksa güvenlik ve yetki senaryoları ayrıca test edilmelidir.
Geliştirme süreci şu adımlarla ilerlediğinde veri koruma daha kontrollü olur:
Test senaryoları gerçek kullanıcı davranışına göre yazılmalıdır. Örneğin:
Bu testler, ürünü yayına hazırlarken “güvenli çalışıyor mu?” sorusuna daha gerçekçi cevap verir.
Mobil uygulama yayınlandıktan sonra veri güvenliği bitmez. İşletim sistemi güncellemeleri, SDK değişiklikleri, yeni cihaz davranışları, API versiyonları ve kullanıcı sayısındaki artış güvenlik risklerini sürekli değiştirir.
Bu nedenle teknik destek ve bakım süreci, yalnızca hata düzeltme paketi olarak görülmemelidir. Bakım; güvenlik güncellemesi, performans takibi, log inceleme, veri tabanı yedekleme, üçüncü parti servis kontrolü ve mağaza uyumluluğunu da kapsamalıdır.
Yayın sonrası düzenli kontrol edilmesi gereken başlıklar:
| Kontrol Alanı | Sıklık | Neden Önemli? |
|---|---|---|
| SDK güncellemeleri | Aylık / kritik durumda anlık | Eski SDK güvenlik açığı oluşturabilir |
| API log inceleme | Haftalık | Anormal istek ve brute force fark edilir |
| Yetki matrisi | Her yeni özellikte | Yeni roller veri sızıntısı oluşturabilir |
| Store beyanları | Her veri akışı değişiminde | App Store / Google Play uyumu korunur |
| Yedekleme testi | Aylık | Veri kaybı senaryosu önlenir |
| Kullanıcı silme talepleri | Sürekli | KVKK ve kullanıcı güveni için kritik |
| Güvenlik testi | Büyük sürüm öncesi | Yeni açıklar yayına çıkmadan görülür |
Bir uygulama 500 kullanıcıdayken tolere edilebilen küçük bir hata, 50.000 kullanıcıda ciddi veri krizine dönüşebilir. Bu yüzden güvenlik ve bakım, uygulama büyüdükçe daha sistematik hale gelmelidir.
Veri koruma maliyeti, uygulamanın kapsamına göre değişir. Basit bir MVP’de temel güvenlik katmanları yeterli olabilir. Finans, sağlık, kurumsal operasyon veya yüksek hacimli pazaryeri uygulamalarında ise güvenlik, test ve bakım bütçesi daha yüksek planlanmalıdır.
Aşağıdaki maliyet aralıkları Türkiye piyasası ve Atalay Tech’in proje değerlendirme yaklaşımı için tahmini referans niteliğindedir. Kapsam, entegrasyon sayısı, kullanıcı rolleri, veri hassasiyeti ve yayın sonrası destek beklentisi fiyatı doğrudan etkiler.
| Seviye | Kapsam | Veri Koruma Gereksinimi | Tahmini Maliyet Aralığı |
|---|---|---|---|
| MVP | Üyelik, profil, temel API, basit panel | HTTPS, token, temel KVKK, sınırlı log | 200.000 TL - 450.000 TL + KDV |
| Orta ölçek | Ödeme, bildirim, dosya, rol yönetimi | Yetkilendirme, signed URL, store beyanı, test | 450.000 TL - 1.200.000 TL + KDV |
| Kurumsal | Çok rol, yüksek trafik, entegrasyon, raporlama | Gelişmiş audit log, MFA, güvenlik testleri | 1.200.000 TL - 3.500.000 TL + KDV |
| Regüle alan | Sağlık, finans, hassas veri, B2B operasyon | Ek uyum analizi, sıkı erişim, özel raporlama | 3.500.000 TL+ + KDV |
Burada önemli nokta, güvenliği “ekstra maliyet” gibi görmemektir. Zayıf veri mimarisiyle yayına çıkan bir uygulamada sonradan yapılacak düzeltmeler çoğu zaman ilk geliştirme maliyetinden daha pahalı olabilir.
mobil uygulama fiyatları tarafında maliyet hesaplanırken yalnızca ekran sayısı değil; veri hassasiyeti, API sayısı, entegrasyonlar, panel yetkileri, test gereksinimi ve bakım kapsamı da değerlendirilmelidir.
mobil uygulama yaptırmak isteyen bir kurucu veya işletme, teklif alırken yalnızca “kaç ekran olacak?” sorusuna odaklanmamalıdır. Kullanıcı verisinin korunması için teknik ekibe net sorular yöneltilmelidir.
Sorulması gereken pratik sorular:
Bu sorular, proje başlamadan önce belirsizlikleri azaltır. Aynı zamanda geliştirici ekibin yalnızca arayüz değil, veri mimarisi konusunda da ne kadar hazırlıklı olduğunu gösterir.
Mobil uygulamalarda kullanıcı verisi; kullanıcının kimliğini, davranışını, cihazını, konumunu, ödeme geçmişini veya uygulama içi etkileşimini gösteren her türlü bilgidir. Ad, soyad, telefon, e-posta gibi doğrudan kimlik verileri buna dahildir. Bunun yanında push token, cihaz modeli, IP adresi, konum, favoriler, mesajlar, sipariş geçmişi, yüklenen dosyalar ve analitik kayıtları da kullanıcı verisi kapsamına girebilir. Bu nedenle veri koruma planı yalnızca üyelik formuyla sınırlı düşünülmemelidir. Mobil uygulama, backend, yönetim paneli, üçüncü parti SDK’lar ve bildirim altyapısı birlikte değerlendirilmelidir.
Hayır, KVKK metni göstermek tek başına yeterli değildir. Aydınlatma metni ve açık rıza süreçleri hukuki katmanın önemli parçalarıdır; fakat teknik güvenlik zayıfsa kullanıcı verisi yine risk altındadır. Örneğin uygulamada KVKK metni bulunsa bile API yetkilendirmesi hatalıysa bir kullanıcı başka kullanıcının siparişlerini görebilir. Bu durumda metin gösterilmiş olsa da veri koruma mimarisi başarısızdır. Sağlıklı yaklaşım; KVKK metni, veri minimizasyonu, güvenli API, rol bazlı erişim, log maskeleme, dosya güvenliği ve yayın sonrası bakım sürecini birlikte ele almaktır.
Bazı veriler kullanıcı deneyimi için cihazda saklanabilir; ancak her veri cihazda tutulmamalıdır. Örneğin kısa süreli access token, tema tercihi veya ürün listesi cache’i saklanabilir. Buna karşılık ödeme kartı bilgisi, kimlik belgesi, hassas sağlık verisi veya uzun süreli kişisel dosyaların cihazda düz biçimde saklanması risklidir. Token ve oturum bilgileri iOS Keychain veya Android Keystore gibi güvenli saklama mekanizmalarıyla korunmalıdır. Offline kullanım gerekiyorsa hangi verinin ne kadar süreyle ve hangi formatta tutulacağı proje başında netleştirilmelidir.
Çünkü mobil uygulama çoğu zaman yalnızca arayüzdür; asıl veri backend ve API tarafında işlenir. API güvenliği zayıfsa kullanıcı cihazındaki arayüz düzgün görünse bile veri sızıntısı yaşanabilir. En yaygın hatalardan biri, backend’in yalnızca gönderilen ID’ye güvenmesidir. Örneğin kullanıcı sipariş ID’sini değiştirerek başka bir kullanıcının siparişine erişebiliyorsa sorun mobil tasarımda değil, API yetkilendirmesindedir. Bu yüzden her istek kullanıcı kimliği, rol, kaynak sahipliği, rate limit ve hata yönetimi açısından kontrol edilmelidir.
App Store ve Google Play, uygulamaların hangi verileri topladığını ve nasıl kullandığını kullanıcılara açıklamasını ister. Bu beyanlar yalnızca mağaza formalitesi değildir; kullanıcının uygulamaya güvenip güvenmeyeceğini etkiler. Yanlış veya eksik beyan, mağaza incelemesinde sorun çıkarabilir ve kullanıcı güvenini zedeleyebilir. Ayrıca üçüncü parti SDK’lar da bu beyanlara dahil edilmelidir. Analitik, crash reporting, reklam, harita veya ödeme servisleri veri topluyorsa bunların hangi veri kategorisine girdiği doğru analiz edilmelidir.
Üçüncü parti SDK kullanmak tek başına yanlış değildir; ancak kontrolsüz SDK kullanımı risklidir. Analitik, bildirim, ödeme, harita veya hata takip servisleri uygulama içindeki bazı verilere erişebilir. Bu servislerin hangi verileri topladığı, veriyi nerede işlediği, kullanıcıyla ilişkilendirip ilişkilendirmediği ve silme taleplerine nasıl yanıt verdiği bilinmelidir. Güvenli yaklaşım, her SDK için veri envanteri tutmak ve gereksiz SDK’ları projeden çıkarmaktır. Ayrıca SDK güncellemeleri düzenli takip edilmelidir; eski sürümler güvenlik açığı oluşturabilir.
Kullanıcı hesabını silmek istediğinde yalnızca uygulamadan çıkış yaptırmak yeterli değildir. Hesap silme talebi; kullanıcı profili, oturum token’ları, push notification token’ı, ilişkili dosyalar, destek kayıtları ve üçüncü parti servislerdeki kayıtlar açısından değerlendirilmelidir. Bazı veriler yasal veya finansal saklama yükümlülükleri nedeniyle belirli süre tutulabilir; ancak bu durum kullanıcıya açık şekilde anlatılmalıdır. Teknik tarafta ise silme süreci backend’de izlenebilir, loglanabilir ve tekrar edilebilir bir akışa bağlanmalıdır. Mobil uygulamada kullanıcıya bu sürecin sonucu net biçimde gösterilmelidir.
Veri koruma, kapsamına göre bütçeyi artırabilir; fakat baştan planlandığında maliyeti yönetilebilir hale getirir. Asıl pahalı olan, güvenlik düşünülmeden geliştirilen uygulamanın sonradan düzeltilmesidir. Basit bir MVP’de temel KVKK akışı, güvenli token saklama, HTTPS, temel yetkilendirme ve store beyanları yeterli olabilir. Kurumsal uygulamalarda ise rol bazlı panel, audit log, MFA, gelişmiş test ve düzenli bakım gerekir. Bu nedenle bütçe konuşulurken ekran sayısı kadar veri hassasiyeti, entegrasyonlar ve kullanıcı rol yapısı da değerlendirilmelidir.
Mobil uygulamada teknik borç; hızlı teslim, eksik test, zayıf mimari ve plansız bakım yüzünden uygulamanın zamanla pahalı, kırılgan ve yavaş geliştirilir hale gelmesidir. Bu rehber; teknik borcu önlemek için mimari, test, sürümleme, bakım ve maliyet kararlarını somut örneklerle açıklar.
Mobil uygulama güncelleme süreci yalnızca yeni sürüm yüklemek değildir. Kapsam analizi, sürüm notu, test, mağaza onayı, kademeli dağıtım, hata takibi ve bakım planı birlikte yönetildiğinde uygulama daha stabil, güvenli ve sürdürülebilir olur.
Mobil uygulama bakım ve destek süreci; yayındaki bir uygulamanın güvenli, hızlı, güncel ve kullanıcı beklentilerine uygun kalmasını sağlar. Bu rehberde bakım kapsamını, destek seviyelerini, maliyet aralıklarını, mağaza uyumluluğunu, güvenlik kontrollerini ve Atalay Tech'in proje sonrası yaklaşımını pratik örneklerle in
