Mobil Uygulama Güvenliği: Nelere Dikkat Edilmeli?

Kısa cevap: mobil uygulama güvenliği büyük ölçüde telefonda değil sunucuda sağlanır. Uygulama paketi kullanıcının cihazındadır; açılabilir, incelenebilir, değiştirilebilir. Bu yüzden kural basittir: uygulamaya güvenme, her isteği sunucuda doğrula. Telefonda yapılacak iş ise sınırlı ama kritiktir: oturum anahtarlarını güvenli depoda saklamak, trafiği şifrelemek ve pakete hiçbir sır koymamak.

Mobil uygulama güvenliği neden web güvenliğinden farklı?

Web sitesinde kodun büyük kısmı sizin sunucunuzda çalışır. Mobil uygulamada ise derlenmiş paket App Store ya da Google Play üzerinden herkese dağıtılır. Bir APK dosyasını açıp içindeki metinleri, API adreslerini ve varsa gömülü anahtarları okumak birkaç dakikalık iştir. Ayrıca kullanıcılar eski sürümleri aylarca güncellemeden kullanır; bulduğunuz bir açığı yayınladığınız gün herkeste kapatamazsınız.

Sunucu tarafındaki genel saldırı yüzeyini (SQL enjeksiyonu, kaba kuvvet, güncel olmayan bileşenler) web sitesi güvenliği yazımızda ele aldık. Bu yazı yalnızca mobil uygulamaya özgü riskleri ve bir uygulama yaptırırken sormanız gerekenleri kapsıyor.

Uygulama paketine koyduğunuz her şeyi herkese açık kabul edin. Paket içinde gizli kalan anahtar yoktur; yalnızca henüz bulunmamış anahtar vardır.

En sık görülen 6 mobil güvenlik hatası

• Ödeme, SMS ya da harita servisinin gizli API anahtarını uygulamanın içine gömmek.
• Oturum token'ını şifresiz depoda (AsyncStorage, SharedPreferences) saklamak.
• Yetki kontrolünü yalnızca arayüzde yapmak: buton gizli ama API ucu herkese açık.
• Başka kullanıcının kaydına yalnızca ID değiştirerek erişilebilmesi (IDOR).
• Canlı sürümde telefon, e-posta ya da token içeren ayrıntılı loglar bırakmak.
• Zorunlu güncelleme mekanizması olmadan yayına çıkmak; açığı kapatan sürüme kullanıcıyı geçirememek.

Listedeki hataların dördü sunucu tarafında çözülür. Mobil güvenlik çalışmasının neden çoğunlukla API tasarımı olduğu buradan anlaşılıyor; API tarafının genel mantığını API entegrasyonu nedir yazısında anlattık.

Token ve hassas veri telefonda nasıl saklanmalı?

Oturum bilgisi iOS'ta Keychain'de, Android'de Keystore destekli şifreli depoda tutulmalıdır. AsyncStorage gibi düz depolar, cihaz yedeğinden ya da root'lu bir telefondan okunabilir. React Native projelerinde bunun için hazır ve olgun kütüphaneler var:

import * as Keychain from 'react-native-keychain';

// Yanlış: düz metin, yedekten okunabilir
// await AsyncStorage.setItem('refreshToken', token);

// Doğru: iOS Keychain / Android Keystore
export async function saveRefreshToken(token: string) {
  await Keychain.setGenericPassword('session', token, {
    accessible: Keychain.ACCESSIBLE.WHEN_UNLOCKED_THIS_DEVICE_ONLY,
  });
}

export async function readRefreshToken(): Promise<string | null> {
  const creds = await Keychain.getGenericPassword();
  return creds ? creds.password : null;
}

Erişim token'ı kısa ömürlü (örneğin 15 dakika) olmalı, uzun ömürlü yenileme token'ı ise sunucuda iptal edilebilmelidir. Kullanıcı şifresini değiştirdiğinde ya da telefonunu kaybettiğinde tüm oturumları tek hamlede kapatabilmek gerekir. Giriş adımına ikinci bir doğrulama eklemek isterseniz SMS OTP doğrulama entegrasyonu yazımızdaki kurallar mobilde de aynen geçerli.

API tarafında yapılması gerekenler

• Her istekte kimlik ve yetki sunucuda kontrol edilir; "bu kullanıcı bu kaydı görebilir mi" sorusu her uçta sorulur.
• Gizli anahtar gerektiren işlemler (ödeme, SMS, e-posta) uygulamadan değil sunucudan yapılır; uygulama yalnızca sunucunuzu çağırır.
• Giriş, şifre sıfırlama ve kod gönderme uçlarında hız sınırı vardır.
• Yanıtlar yalnızca ekranın ihtiyaç duyduğu alanları döner; tüm kullanıcı nesnesi gönderilmez.
• Uygulamanın sahte bir kopyadan gelmediğini doğrulamak için Play Integrity ve App Attest değerlendirilir.

Sertifika sabitleme (certificate pinning) şart mı?

HTTPS her uygulamada zorunludur. Sertifika sabitleme ise uygulamanın yalnızca sizin sertifikanızla konuşmasını sağlar ve araya girme saldırılarını zorlaştırır. Bankacılık, sağlık ve ödeme uygulamalarında önerilir. Bedeli şudur: sertifikayı yenilediğinizde eski sürümler bağlanamaz hâle gelebilir. Bu yüzden yedek anahtar tanımlamadan ve yenileme takvimini planlamadan sabitleme yapılmamalıdır.

KVKK ve mağaza gereklilikleri

Uygulama kişisel veri topluyorsa aydınlatma metni, açık rıza ve veri silme talebinin karşılanması gerekir. Apple ve Google da mağaza listesinde hangi verinin neden toplandığını beyan etmenizi ister; beyanla uygulamanın davranışı uyuşmazsa uygulama reddedilebilir. KVKK tarafının ayrıntıları için KVKK uyumlu web sitesi yazımız mobil uygulamalar için de iyi bir başlangıç.

Yayın öncesi güvenlik kontrol listesi

• Paket içinde gizli anahtar, test hesabı ya da iç sunucu adresi kalmadı.
• Token'lar Keychain / Keystore'da, kısa ömürlü ve iptal edilebilir.
• Başka kullanıcının ID'siyle yapılan istekler 403 dönüyor.
• Canlı sürümde hata ayıklama logları kapalı, hata raporlarında kişisel veri maskeleniyor.
• Android'de kod küçültme ve karartma (R8) açık.
• Zorunlu güncelleme mekanizması çalışıyor; minimum desteklenen sürüm sunucudan yönetiliyor.

Güvenlik tek seferlik bir iş değildir: bağımlılıklar güncellenmeli, işletim sistemi değişiklikleri takip edilmeli, yeni özellikler aynı kontrollerden geçmelidir. Bu sürekli işin bütçeye etkisini mobil uygulama bakım maliyeti yazısında bulabilirsiniz.

Sonuç

Mobil uygulama güvenliğinin özeti üç cümledir: pakete sır koyma, token'ı güvenli depoda sakla, her isteği sunucuda doğrula. Geri kalan her şey bu üç kuralın ayrıntısıdır. Mobil uygulama geliştirme projelerimizde bu kontrolleri baştan tasarıma dâhil ediyoruz. Mevcut uygulamanızın güvenlik incelemesini ya da yeni bir proje planlıyorsanız teklif alın, birlikte değerlendirelim.