API ve Mobil Uygulama İçin Ayrı Sızma Testi Gerekir mi? API/Mobil Pentest Rehberi

Bir mobil uygulama açılıyor, kullanıcı login oluyor ve hesap hareketlerini görüntülüyor. Ekrandaki verinin tamamı backend API’den geliyor. Bu tablo ilk bakışta tek bir test hedefi varmış gibi görünebilir. Sonuçta mobil uygulama API’nin arayüzü değil midir?

Kısmen evet. Güvenlik açısından ise cevap bu kadar basit değildir.

Mobil uygulamanın proxy üzerinden geçen bütün request’lerini inceleyip endpoint’leri test etmek, API hakkında önemli bulgular üretebilir. Fakat bu çalışma cihazda saklanan token’ı, Android’de dışarı açılmış bir component’i, iOS Keychain accessibility seçimini, deep link hijacking riskini, WebView bridge’ini veya production binary içinde unutulmuş debug özelliğini kendiliğinden değerlendirmez.

Tersi de geçerlidir. APK veya IPA üzerinde kapsamlı static ve dynamic analysis yapmak, backend’in aşağıdaki istekte object-level authorization uygulayıp uygulamadığını kanıtlamaz:

GET /api/v2/accounts/874921/transactions HTTP/1.1
Host: api.example.com
Authorization: Bearer eyJ...

Kullanıcı yalnızca accountId değerini değiştirerek başka müşterinin hareketlerini görebiliyorsa problem mobil binary’de değildir. Root cause, API’nin authenticated kullanıcı ile istenen account arasındaki ilişkiyi server-side doğrulamamasıdır.

Bu nedenle kısa cevap şudur:

Bu yazıda “ikisini de test ettirin” şeklinde ticari bir genellemeyle yetinmeyeceğiz. API sızma testinin neyi kanıtladığını, mobil uygulama sızma testinin hangi riskleri gördüğünü, ortak testlerin nerede birleştiğini ve aynı eforun iki kez fiyatlandırılmadan kapsamın nasıl kurulacağını teknik örneklerle inceleyeceğiz. Ayrıca iOS ve Android’in ayrı scope sayılıp sayılmadığını, certificate pinning’in gerçek değerini, biometrics ve device attestation gibi kontrollerin sınırını ve raporlamanın nasıl bir attack chain görünümü üretmesi gerektiğini açıklayacağız.

1. Aynı ürün, farklı attack surface

Modern bir mobil ürün en az iki ayrı güven ortamında çalışır:

1. 1Kurumun kontrol ettiği backend, API gateway, identity service, database ve integration katmanı
2. 2Kullanıcının fiziksel olarak kontrol ettiği ve kurumun tam güvenemeyeceği mobil cihaz

Backend hangi code’un çalıştığını, hangi database query’sinin üretildiğini ve authorization policy’nin nasıl uygulandığını belirleyebilir. Mobil istemci ise son kullanıcının cihazındadır. Binary indirilebilir, incelenebilir, instrument edilebilir, runtime davranışı değiştirilebilir ve network trafiği uygun test ortamında gözlemlenebilir.

Bu gerçek, mobil güvenliğin en önemli tasarım varsayımını doğurur:

Bir butonun UI’dan gizlenmesi, bir limitin Kotlin veya Swift code’unda kontrol edilmesi ya da isPremium=true değerinin local storage’da tutulması kullanıcıya server-side yetki vermez. Hassas karar backend tarafından yeniden doğrulanmalıdır.

Örneğin uygulama para transferi limitini istemci tarafında kontrol ediyor olabilir:

if (amount <= user.dailyTransferLimit) {
    api.createTransfer(targetIban, amount)
}

Bu kontrol kullanıcı deneyimi için yararlıdır. Fakat saldırgan doğrudan API request’i oluşturabildiği için güvenlik kontrolü değildir. Backend de aynı kuralı authoritative veriyle enforce etmelidir:

@Transactional
public Transfer createTransfer(
        AuthenticatedUser actor,
        TransferCommand command) {

    Account source = accountRepository.findOwnedBy(
            command.sourceAccountId(), actor.subjectId()
        )
        .orElseThrow(AccessDeniedException::new);

    transferPolicy.assertAllowed(
        actor,
        source,
        command.targetIban(),
        command.amount()
    );

    return transferService.execute(source, command);
}

API testi bu server-side kararın atlanıp atlanamadığını değerlendirir. Mobil test ise aynı işlemin token’ının cihazda nasıl korunduğunu, app link’in transfer ekranını kontrolsüz parametreyle açıp açmadığını, hassas verinin log’a yazılıp yazılmadığını ve binary’nin production’a doğru configuration ile çıkıp çıkmadığını inceler.

2. API sızma testi ile mobil uygulama sızma testi neyi gösterir?

İki testin ortak noktaları vardır. Authentication flow, session lifecycle, API request’leri, TLS kullanımı ve business process her ikisinde de görünür. Fakat coverage aynı değildir.

Tablodaki en önemli nokta, aynı request’in iki farklı soruya cevap vermesidir. Mobil test “credential bu request’e gelene kadar nasıl korunuyor?” diye sorar. API testi “backend bu credential ile hangi object ve function’a izin veriyor?” sorusunu yanıtlar.

3. API sızma testi hangi risklere odaklanır?

API sızma testi, server-side trust decision’ları endpoint, operation, object, field ve workflow düzeyinde doğrular. Yalnızca OpenAPI dokümanını scanner’a vermek veya endpoint’lere payload göndermek değildir.

Sağlıklı bir testte en az şu alanlar incelenir:

• Authentication ve token issuance
• Access token validation, audience, issuer, scope ve expiration
• Refresh token rotation, revocation ve reuse detection
• Object-level authorization
• Property-level authorization
• Function-level authorization
• Tenant isolation
• Business logic ve workflow state
• Rate limit, quota ve resource consumption
• API inventory, version drift ve shadow endpoint’ler
• Input validation ve injection sınıfları
• SSRF ve outbound request kontrolü
• File upload ve content processing
• GraphQL, gRPC, WebSocket ve webhook yüzeyleri
• Third-party API response’larına duyulan güven
• Error handling ve hassas veri exposure

OWASP API Security Top 10:2023, BOLA, Broken Authentication, BOPLA, Unrestricted Resource Consumption, BFLA, Unrestricted Access to Sensitive Business Flows, SSRF ve Improper Inventory Management gibi API’ye özgü problem alanlarını ortak bir dilde toplar. Bu liste iyi bir başlangıçtır. Kapsamı uygulamanın kendi business rule’larıyla genişletmeden yalnızca listedeki başlıklara bakmak ise yeterli değildir.

API’de “login oluyor” demek authorization doğru demek değildir

Authentication, isteği kimin yaptığını belirler. Authorization ise bu actor’ın istenen resource ve action üzerinde yetkili olup olmadığını belirler.

Şu endpoint yalnızca geçerli JWT arıyor olabilir:

app.get("/api/orders/:orderId", requireJwt, async (req, res) => {
  const order = await orderRepository.findById(req.params.orderId)

  if (!order) {
    return res.sendStatus(404)
  }

  return res.json(order)
})

Token geçerlidir. Fakat orderId ile token subject arasında ilişki kontrol edilmemiştir. Doğru yaklaşım, resource’u actor ve tenant bağlamında sorgulamaktır:

app.get("/api/orders/:orderId", requireJwt, async (req, res) => {
  const order = await orderRepository.findOne({
    id: req.params.orderId,
    customerId: req.auth.subject,
    tenantId: req.auth.tenantId
  })

  if (!order) {
    return res.sendStatus(404)
  }

  return res.json(toCustomerOrderView(order))
})

UUID kullanılması bu kontrolün yerini tutmaz. Tahmin edilmesi zor identifier yalnızca keşfi zorlaştırabilir. Yetkisiz erişimi engelleyen asıl unsur her request’te yapılan object-level authorization kontrolüdür. Bu problemin neden modern uygulamalarda hâlâ yaygın olduğunu IDOR Açığı Neden Hâlâ Bu Kadar Yaygın? yazısında ayrıntılı biçimde inceliyoruz.

4. BOLA, BOPLA ve BFLA aynı authorization problemi değildir

API testinin önemli bir bölümü, “kullanıcı bu endpoint’e ulaşabiliyor mu?” sorusunu daha küçük güven kararlarına ayırmaktır.

BOLA: Hangi object’e erişebilir?

Broken Object Level Authorization, actor’ın başka kullanıcıya veya tenant’a ait resource’a identifier değiştirerek erişebilmesidir.

GET /api/v1/customers/7c819/documents/INV-2026-1142
Authorization: Bearer <customer-a-token>

Test yalnızca documentId değiştirmekten ibaret değildir. Path, query, request body, GraphQL variable, header, cookie ve nested object referansları ayrı ayrı izlenmelidir.

BOPLA: Hangi property’yi görebilir veya değiştirebilir?

Broken Object Property Level Authorization iki yönde ortaya çıkabilir:

• Response gereğinden fazla property döndürür
• Request body actor’ın değiştirmemesi gereken property’leri kabul eder

Örneğin profil güncelleme endpoint’i request’i doğrudan entity’ye bind ediyorsa role, creditLimit veya tenantId gibi alanlar mass assignment yoluyla değişebilir:

// Riskli yaklaşım
@PutMapping("/users/{id}")
public User update(@PathVariable UUID id, @RequestBody User request) {
    request.setId(id);
    return userRepository.save(request);
}

Allowlist tabanlı request DTO ve açık field mapping daha güvenlidir:

public record UpdateProfileRequest(
    String displayName,
    String locale
) {}

@PutMapping("/users/me")
public ProfileView updateMyProfile(
        AuthenticatedUser actor,
        @Valid @RequestBody UpdateProfileRequest request) {

    return profileService.updateAllowedFields(
        actor.subjectId(),
        request.displayName(),
        request.locale()
    );
}

BFLA: Hangi function’ı çalıştırabilir?

Broken Function Level Authorization, normal kullanıcının privileged operation’a ulaşabilmesidir. Mobil UI’da admin butonu bulunmaması endpoint’i korumaz.

POST /api/v1/admin/refunds/7d11/approve
Authorization: Bearer <standard-user-token>

Route-level role kontrolü faydalıdır. Yine de yalnızca role adı yeterli olmayabilir. Actor’ın tenant’ı, işlem limiti, approval separation ve resource state’i de policy’nin parçası olabilir.

5. API business logic testi neden mobil workflow’dan beslenir?

API dokümanı endpoint’leri gösterir. Mobil uygulama ise bu endpoint’lerin hangi sırayla, hangi görünmez state ile ve hangi kullanıcı niyetiyle çağrıldığını gösterir.

Örneğin mobil kredi başvurusunda normal akış şöyle olabilir:

STARTED → IDENTITY_VERIFIED → OFFERED → ACCEPTED → SIGNED → DISBURSED

Tek tek endpoint’lerin authentication kontrolü doğru olsa da kullanıcı ACCEPTED adımından doğrudan DISBURSED action’ına geçebiliyorsa workflow bypass oluşur. API, istemcinin “önceki ekran tamamlandı” iddiasına değil, authoritative server state’e güvenmelidir.

if (application.state !== "SIGNED") {
  throw new ConflictError("Application is not ready for disbursement")
}

await policy.requireFourEyesApproval(application)
await disbursementService.executeOnce(application.id)

Mobil uygulamanın runtime analizi şu ayrıntıları ortaya çıkarabilir:

• Gizli feature flag’ler
• Alternatif onboarding route’ları
• Client-side limit ve eligibility kuralları
• Uygulamanın çağırdığı eski API version’ı
• Remote configuration ile açılan function’lar
• Backend dokümanında olmayan header ve device identifier’lar
• Offline queue ve request retry davranışı

Bu bilgiler API business logic testini daha gerçekçi kılar. İş akışındaki güven kararlarının kod incelemesinde nasıl takip edildiğini Business Logic Açıkları Nasıl Yakalanır? rehberinde ele alıyoruz.

6. Mobil uygulama sızma testi hangi alanları kapsar?

Mobil uygulama sızma testi yalnızca API request’lerinin izlenmesi değildir. APK veya IPA, platform manifest ve entitlement’ları, local data, operating system interaction, network trust, third-party SDK’ler ve runtime tampering riski birlikte değerlendirilir.

OWASP MASVS mobil güvenlik kontrollerini STORAGE, CRYPTO, AUTH, NETWORK, PLATFORM, CODE, RESILIENCE ve PRIVACY başlıklarında toplar. OWASP MASTG ise Android ve iOS üzerinde bu alanların test yaklaşımını ayrıntılandırır.

Tipik mobil pentest coverage’ı şu başlıklardan oluşur:

• APK veya IPA package analizi
• Manifest, entitlement ve permission incelemesi
• Debug ve release configuration karşılaştırması
• Local storage, database, cache, log ve backup
• Keychain ve Android Keystore kullanımı
• Authentication UX ve local authentication kontrolleri
• Session token’ın cihaz üzerindeki lifecycle’ı
• TLS validation ve client network policy
• Certificate pinning implementation ve failure behavior
• Deep link, app link, universal link ve custom URL scheme
• Android exported component, Intent, ContentProvider ve IPC
• iOS app extension, App Group, URL handling ve pasteboard kullanımı
• WebView, JavaScript bridge ve untrusted content
• File handling ve document provider akışları
• Cryptographic key management
• Hardcoded credential ve environment secret’ları
• Reverse engineering, hooking ve runtime tampering
• Root veya jailbreak durumundaki risk modeli
• Device attestation ve replay koruması
• Screenshot, notification preview ve clipboard exposure
• Privacy permission’ları ve third-party SDK data flow’u

Bu liste her uygulamada aynı ağırlıkla uygulanmaz. Bir kurumsal MFA uygulaması ile halka açık katalog uygulamasının risk modeli aynı değildir. Kapsam, uygulamanın işlevi ve işlediği veri üzerinden seçilmelidir.

7. Mobil trafiği proxy’den geçirmek neden tam mobil pentest değildir?

Bir test uzmanı mobil uygulamayı çalıştırır, cihazı proxy’ye yönlendirir ve API request’lerini incelemeye başlar. Bu adım gereklidir. Ancak çalışma burada kalıyorsa yapılan iş, ağırlıklı olarak mobil istemci üzerinden API testing’dir.

Proxy aşağıdaki riskleri tek başına göstermez:

• Token’ın plaintext SharedPreferences veya plist içinde saklanması
• Android backup’a hassas database’in dahil edilmesi
• Production build’in android:debuggable="true" çıkması
• Exported Activity’nin başka bir uygulama tarafından tetiklenmesi
• ContentProvider’ın başka package’a veri sızdırması
• WebView’de riskli JavaScript bridge bulunması
• Custom URL scheme’in başka uygulama tarafından ele geçirilmesi
• iOS App Group container’ının gereğinden fazla app extension ile paylaşılması
• Keychain item’ının ihtiyaca göre fazla geniş accessibility class kullanması
• Binary içinde private signing key veya kalıcı backend secret bulunması
• Runtime’da local premium check’in değiştirilmesi
• Notification preview’da finansal veya sağlık verisi gösterilmesi

Aynı şekilde yalnızca decompiler çıktısına bakmak da full mobile pentest değildir. Static analysis, runtime data, OS interaction ve backend davranışıyla doğrulanmalıdır.

Sağlıklı test dört bakışı birleştirir:

1. 1Static analysis
2. 2Dynamic analysis
3. 3Network ve API behavior
4. 4Platform interaction

White box scope’ta source code, build configuration ve architecture review bu katmanlara eklenir.

8. Local storage testi yalnızca “şifreli mi?” sorusu değildir

Mobil uygulamalar kullanım kolaylığı ve offline çalışma için cihazda veri bırakır. Her veri aynı korumayı gerektirmez. Kritik soru, verinin ne olduğu, ne kadar süre kaldığı, hangi process ve app’lerin erişebildiği ve cihaz kilidi açıldıktan sonra hangi koşullarda kullanılabildiğidir.

İncelenmesi gereken yerler arasında şunlar bulunur:

• SharedPreferences ve DataStore
• SQLite, Room ve Core Data database’leri
• plist ve application support dosyaları
• Cache directory
• External storage
• Download edilen belge ve media
• WebView cookie, cache ve local storage
• Crash report ve analytics event’leri
• Application log’ları
• Clipboard ve pasteboard
• Notification content
• Screenshot ve recent-apps snapshot
• Auto backup ve device migration

“Database AES ile şifreli” cümlesi tek başına güvence değildir. AES key aynı package içinde hardcoded ise saldırgan binary’den key’i alabilir. Key device-bound değilse backup başka cihaza taşınabilir. Hassas veri logout sonrası kalıyorsa eski oturumun artığı yeni kullanıcı tarafından görülebilir.

Doğru değerlendirme şu soruları birlikte sorar:

• Bu veriyi kalıcı saklamak gerçekten gerekli mi?
• Veri minimization uygulanabilir mi?
• Encryption key nerede üretiliyor ve nerede tutuluyor?
• Key kullanımına user authentication şartı bağlanmış mı?
• Backup ve migration davranışı nedir?
• Logout, account removal ve remote wipe sonrasında veri temizleniyor mu?
• App extension veya başka process aynı container’a erişiyor mu?
• Debug ve analytics pipeline hassas değeri kopyalıyor mu?

9. Android Keystore ve iOS Keychain neyi çözer, neyi çözmez?

Android Keystore ve iOS Keychain, password, token ve cryptographic key gibi değerler için platformun sunduğu korumalı mekanizmalardır. Fakat “Keychain kullanıyoruz” veya “Keystore’a koyduk” ifadesi doğru configuration ve doğru threat model olmadan yeterli değildir.

Android Keystore

Android Keystore, cryptographic key materyalinin uygulama process’ine export edilmeden kullanılabilmesini sağlayabilir. Desteklenen cihazlarda key hardware-backed olabilir. Key üretiminde kullanım amacı, algorithm, user authentication gereksinimi ve invalidation davranışı tanımlanabilir.

Örnek bir key üretimi:

val keyGenerator = KeyGenerator.getInstance(
    KeyProperties.KEY_ALGORITHM_AES,
    "AndroidKeyStore"
)

val spec = KeyGenParameterSpec.Builder(
    "session_data_key",
    KeyProperties.PURPOSE_ENCRYPT or KeyProperties.PURPOSE_DECRYPT
)
    .setBlockModes(KeyProperties.BLOCK_MODE_GCM)
    .setEncryptionPaddings(KeyProperties.ENCRYPTION_PADDING_NONE)
    .setUserAuthenticationRequired(true)
    .setUserAuthenticationParameters(
        300,
        KeyProperties.AUTH_BIOMETRIC_STRONG or
            KeyProperties.AUTH_DEVICE_CREDENTIAL
    )
    .build()

keyGenerator.init(spec)
keyGenerator.generateKey()

Bu örnek her uygulama için kopyalanacak bir reçete değildir. Beş dakikalık authentication window bazı işlemler için fazla uzun, bazı kullanım senaryoları için gereksiz derecede kısıtlayıcı olabilir. Güvenlik kararı, verinin hassasiyeti ve kullanıcı deneyimiyle birlikte verilmelidir.

iOS Keychain

Apple, Keychain’i password, cryptographic key ve login token gibi küçük hassas değerler için konumlandırır. Item’ın ne zaman erişilebilir olduğu kSecAttrAccessible seçimiyle belirlenir.

Örneğin yalnızca cihaz unlock durumundayken ve başka cihaza migrate olmadan saklanması istenen bir token için configuration şu yönde olabilir:

let query: [String: Any] = [
    kSecClass as String: kSecClassGenericPassword,
    kSecAttrService as String: "com.example.mobile.session",
    kSecAttrAccount as String: accountId,
    kSecValueData as String: tokenData,
    kSecAttrAccessible as String:
        kSecAttrAccessibleWhenUnlockedThisDeviceOnly
]

let status = SecItemAdd(query as CFDictionary, nil)
guard status == errSecSuccess else {
    throw KeychainError.unhandled(status)
}

Background processing gerekiyorsa WhenUnlocked seçimi function’ı bozabilir. Daha erişilebilir bir class seçildiğinde ise koruma sınırı değişir. Bu nedenle test, “Keychain kullanılmış mı?” sorusundan sonra accessibility class, access group, synchronizable flag, device migration ve logout temizliğini de inceler.

Keychain veya Keystore API authorization açığını kapatmaz. Cihazdan token çalınmasını zorlaştırır. Backend çalınmış token için doğru expiration, revocation, audience, device risk ve step-up kontrollerine hâlâ ihtiyaç duyar.

10. Android exported component ve IPC neden ayrı bir test alanıdır?

Android uygulaması Activity, Service, BroadcastReceiver ve ContentProvider component’leri üzerinden operating system ve diğer uygulamalarla iletişim kurar. Yanlış export edilen bir component, normalde internal olması gereken function’ın başka bir package tarafından tetiklenmesine yol açabilir.

Riskli bir manifest örneği:

<activity
    android:name=".internal.ApprovalActivity"
    android:exported="true" />

ApprovalActivity yalnızca “kullanıcı login olmuş mu?” diye local state kontrol ediyor ve dışarıdan gelen transaction ID’yi işliyorsa kötü niyetli başka bir uygulama beklenmeyen action başlatabilir.

External erişim gerekmiyorsa niyet açıkça belirtilmelidir:

<activity
    android:name=".internal.ApprovalActivity"
    android:exported="false" />

External communication gerçekten gerekiyorsa şu kontroller ele alınır:

• Explicit target ve dar intent filter
• Caller identity ve signature-level permission
• Incoming URI, extra ve nested Intent validation
• onCreate ile onNewIntent üzerinde aynı validation
• ContentProvider için path ve row-level access kontrolü
• Mutable PendingIntent kullanımının sınırlandırılması
• Sensitive action öncesi server-side authorization ve gerekirse re-authentication

Bu saldırı yüzeyi API scanner’ının görebileceği bir alan değildir. Component yalnızca cihaz içindeki IPC üzerinden çağrılabilir.

11. Deep link, app link ve universal link testinde ne aranır?

Deep link, kullanıcıyı mobil uygulama içindeki belirli bir ekrana götürür. Kampanya, password reset, payment return, e-mail verification ve davet akışları için kullanışlıdır. Aynı zamanda başka bir uygulamadan veya web sayfasından güvenilmeyen input alır.

Örneğin uygulama şu link’i işliyor olabilir:

bankapp://transfer/confirm?transactionId=7a18&returnUrl=https://example.net

Uygulama, link geldiğinde şu varsayımları yapmamalıdır:

• Link’i açan uygulama güvenilirdir
• Kullanıcı daha önce akışın gerekli adımlarını tamamlamıştır
• transactionId mevcut kullanıcıya aittir
• returnUrl güvenilir bir domain’dir
• Link yalnızca bir kez kullanılacaktır
• App açıkken gelen link ile cold start sırasında gelen link aynı kontrollerden geçmek zorunda değildir

Güvenli flow, deep link’i bir navigation signal olarak görür. Hassas action için current session, object ownership, authoritative server state ve gerekiyorsa re-authentication yeniden doğrulanır.

func handlePaymentLink(_ url: URL) async throws {
    guard url.scheme == "https",
          url.host == "pay.example.com",
          url.path == "/mobile/confirm",
          let transactionId = url.queryValue("transactionId") else {
        throw LinkError.invalid
    }

    let transaction = try await api.loadTransaction(transactionId)
    guard transaction.ownerId == session.subjectId,
          transaction.state == .awaitingConfirmation else {
        throw LinkError.notAllowed
    }

    router.showConfirmation(transaction)
}

Bu örnekte client-side owner kontrolü yalnızca UI defense’tır. API, loadTransaction ve daha sonra yapılacak confirmation isteğinde ownership’i server-side enforce etmelidir.

Verified link neden custom URL scheme’den daha güvenlidir?

iOS’ta custom URL scheme benzersiz olarak sahiplenilemez. Başka bir uygulama aynı scheme’i kaydedebilir ve link’i yakalayabilir. Apple bu nedenle web domain’i ile application arasında doğrulanmış ilişki kuran universal link kullanımını önerir.

Android App Links de domain ile application package arasındaki ilişkiyi assetlinks.json üzerinden doğrular. Yine de verified link kullanılması input’un güvenilir olduğu anlamına gelmez. Path, query ve action server-side kurallara göre doğrulanmalıdır.

Test sırasında şu noktalar incelenir:

• iOS associated domains entitlement
• apple-app-site-association kapsamı
• Android intent filter ve android:autoVerify
• assetlinks.json içindeki package ve signing certificate fingerprint
• Custom scheme collision
• Open redirect ve untrusted return URL
• Authentication callback’te state, PKCE ve one-time code kullanımı
• Link replay
• Cold start ve existing activity lifecycle farkı
• Link’in başka tenant veya kullanıcı resource’una bağlanabilmesi

12. WebView ve native bridge riski yalnızca XSS değildir

Mobil uygulamalar ödeme, destek, kampanya, içerik ve hybrid ekranlar için WebView kullanabilir. WebView’deki risk, yalnızca web sayfasında XSS bulunması değildir. Web content native capability’ye açılan bir bridge ile birleştiğinde etki büyür.

Android’de aşağıdaki gibi bir interface expose edildiğini düşünelim:

webView.settings.javaScriptEnabled = true
webView.addJavascriptInterface(NativeBridge(), "Native")
webView.loadUrl(intent.getStringExtra("url")!!)

Eğer url dışarıdan kontrol edilebiliyor ve NativeBridge token, dosya veya cihaz işlevine erişebiliyorsa untrusted JavaScript application context’inde etkili olabilir.

Risk bazlı kontrol listesi şunları içerir:

• JavaScript gerçekten gerekli mi?
• WebView yalnız allowlist’teki HTTPS origin’leri mi yüklüyor?
• Redirect sonrası final origin yeniden doğrulanıyor mu?
• file://, content:// ve local file access gerekli mi?
• JavaScript bridge yalnız gerekli method’ları mı sunuyor?
• Bridge çağrılarında origin veya navigation context kontrol ediliyor mu?
• Download ve file chooser akışı güvenli mi?
• Mixed content ve cleartext load kapalı mı?
• Debugging production build’de açık mı?
• Cookie ve session native client ile beklenmeyen biçimde paylaşılıyor mu?
• External browser’a çıkışta URL doğrulanıyor mu?

JavaScript gerekmiyorsa kapatmak en net çözümdür:

webView.settings.javaScriptEnabled = false

Gerekiyorsa güvenli tasarım, yalnızca trusted content yüklemeye ve bridge yüzeyini mümkün olduğunca dar tutmaya dayanır. “Sayfa bizim domain’den geliyor” varsayımı tek başına yeterli değildir. Redirect, subdomain takeover, compromised third-party script veya XSS, trusted başlangıç URL’sini riskli content’e çevirebilir.

13. TLS validation ile certificate pinning aynı kontrol değildir

TLS validation, client’ın bağlandığı server certificate zincirinin güvenilir olup olmadığını ve hostname ile eşleşip eşleşmediğini doğrular. Certificate pinning ise kabul edilen certificate veya public key kümesini daha da daraltır.

Öncelik sırası önemlidir:

1. 1Cleartext traffic kapatılmalı
2. 2Default certificate ve hostname validation bozulmamalı
3. 3Test CA’ları yalnız debug build’de kabul edilmeli
4. 4Risk modeli gerektiriyorsa pinning tasarlanmalı
5. 5Rotation ve backup pin operasyonu önceden planlanmalı

Android Network Security Configuration ile production ve debug trust ayrılabilir:

<?xml version="1.0" encoding="utf-8"?>
<network-security-config>
    <base-config cleartextTrafficPermitted="false">
        <trust-anchors>
            <certificates src="system" />
        </trust-anchors>
    </base-config>

    <debug-overrides>
        <trust-anchors>
            <certificates src="user" />
        </trust-anchors>
    </debug-overrides>
</network-security-config>

debug-overrides, uygulama android:debuggable="false" olduğunda uygulanmaz. Bu yaklaşım, test cihazında interception ihtiyacını production trust store’a taşımamayı sağlar.

iOS tarafında App Transport Security, URLSession üzerinden yapılan bağlantılar için HTTPS ve ek güvenlik gereksinimleri uygular. NSAllowsArbitraryLoads=true gibi geniş istisnalar, gerekçe ve domain bazlı tasarım olmadan kullanılmamalıdır.

Pinning API authorization sağlamaz

Certificate pinning’in bulunması, BOLA veya business logic açığını engellemez. Saldırgan kendi hesabı ve kendi cihazı üzerinden uygulamanın oluşturduğu geçerli request’i değiştirmeye çalışabilir. Kontrollü test cihazında runtime instrumentation ile pinning aşılabilir. Server’ın güven kararı yine doğru olmalıdır.

Pinning şu risklere karşı ek zorlaştırma sağlayabilir:

• Device trust store’a eklenen kötü niyetli CA
• Bazı enterprise interception veya local network saldırı senaryoları
• Yanlış certificate issuance etkisinin daraltılması

Fakat operasyonel maliyeti vardır. Certificate rotation sırasında backup pin bulunmaması uygulamanın bütün API bağlantısını kesebilir. Bu nedenle pinning’in varlığı otomatik olarak “güvenli”, yokluğu da her uygulamada otomatik olarak “kritik” sayılmamalıdır.

14. Hardcoded API key bulmak her zaman aynı severity değildir

Mobil binary kullanıcıya dağıtılır. Binary içindeki string, resource ve configuration değerlerinin uzun süre gizli kalacağı varsayılamaz. Buna rağmen “API key bulundu” bulgusu bağlamdan koparıldığında hem gereksiz alarm hem de kritik bir riskin küçümsenmesi mümkündür.

Önce key’in ne olduğu anlaşılmalıdır:

Bir mobil uygulama, backend’e kendisini kanıtlamak için içine gömülen kalıcı shared secret’a güvenemez. Her kullanıcı aynı secret’ı alır ve cihaz sahibi binary’yi inceleyebilir.

Daha sağlam tasarım, kullanım senaryosuna göre şu bileşenleri birleştirebilir:

• User authentication
• Authorization code flow ve PKCE
• Kısa ömürlü access token
• Refresh token rotation
• Device-bound cryptographic key
• Server-validated app veya device attestation
• Request nonce ve replay koruması
• Backend-side authorization
• Key rotation ve revocation

Hiçbiri tek başına bütün güven problemini çözmez.

15. Biometrics local kolaylık mı, gerçek güvenlik kontrolü mü?

Face ID, Touch ID veya Android biometric prompt kullanıcı deneyimini ve local secret kullanımını koruyabilir. Fakat “biometric doğrulandı” bilgisini yalnızca local boolean olarak tutmak backend authorization değildir.

Riskli bir örnek:

if (preferences.getBoolean("biometric_verified", false)) {
    api.approveHighValueTransaction(transactionId)
}

Runtime tampering ile local branch değiştirilebilir. Backend, high-value transaction için yalnızca bu client kararına güveniyorsa kontrol atlanabilir.

Daha güçlü modelde biometric başarı, Keystore veya Secure Enclave ile korunan key’in kullanımını açar. Client işlem detaylarını veya server nonce’unu key ile imzalar. Backend signature, nonce, işlem binding’i, session ve authorization policy’yi doğrular.

challenge = random nonce + transactionId + amount + expiresAt
signature = deviceKey.sign(challenge)

Backend şu kontrolleri yapmalıdır:

• Challenge server tarafından üretildi mi?
• Tek kullanımlık mı?
• Kısa süreli mi?
• Doğru kullanıcı, device ve transaction ile bağlı mı?
• Amount ve beneficiary signature kapsamına dahil mi?
• Public key hâlâ aktif ve bu hesaba bağlı mı?
• Transaction server-side state açısından işlenebilir mi?
• Aynı action ikinci kez uygulanabiliyor mu?

Bu yapı bile object-level authorization ve fraud kontrollerinin yerine geçmez. Güçlü bir local authentication sinyalini backend’deki iş kararıyla bağlar.

16. Root, jailbreak ve tampering kontrolleri nasıl yorumlanmalı?

Root veya jailbreak detection, uygulamanın riskli device state’ini fark etmesine yardımcı olabilir. Obfuscation, anti-debugging, integrity check ve hook detection de reverse engineering maliyetini artırabilir. OWASP MASVS bu alanı RESILIENCE altında ele alır.

Bu kontrollerin değeri uygulamanın risk profiline göre değişir:

• Finansal işlem veya high-value credential barındıran uygulamada önemlidir
• Kurumsal secret ve managed access sunan uygulamada önemlidir
• Halka açık içerik gösteren düşük riskli uygulamada daha düşük öncelikli olabilir
• Backend authorization’ın yerine hiçbir durumda geçmez

“Root detection yok” bulgusuna otomatik critical severity vermek doğru değildir. Etki kanıtlanmalıdır. Aynı şekilde root detection bulunduğu için cihaz güvenilir kabul edilmemelidir. Detection bypass edilebilir ve false positive üretebilir.

Sağlıklı tasarım şu yaklaşımı kullanır:

• Device integrity bir risk signal’dır
• Signal server-side değerlendirilir
• Karar action riskine göre step-up, limit, izleme veya engelleme olabilir
• Kullanıcıya anlaşılır recovery yolu sunulur
• Accessibility, enterprise device ve custom ROM senaryoları düşünülür
• Kritik authorization backend’de her durumda enforce edilir

17. Device attestation tek başına güven kanıtı değildir

Android Play Integrity, hardware-backed key attestation veya Apple App Attest gibi mekanizmalar backend’e uygulama ve device environment hakkında imzalı sinyal sağlayabilir. Yanlış entegrasyonda ise yalnızca “attestation API çağrılıyor” görünümü oluşur.

Test şu sorulara cevap arar:

• Attestation sonucu backend tarafından mı doğrulanıyor?
• Certificate chain ve trust anchor doğru mu kontrol ediliyor?
• Nonce server tarafından mı üretiliyor?
• Nonce yeterli entropy’ye sahip ve tek kullanımlık mı?
• Attestation belirli session, request veya action ile bağlı mı?
• Eski başarılı response replay edilebiliyor mu?
• Failure durumunda uygulama fail-open mı davranıyor?
• Verdict policy hangi riskte hangi kararı veriyor?
• Cache süresi hassas action için uygun mu?
• Attestation unavailable olduğunda kontrollü fallback var mı?

Örnek riskli model:

{
  "deviceTrusted": true
}

Client’ın gönderdiği bu boolean’ın güven değeri yoktur. Backend, provider-signed attestation token’ını doğrulamalı ve sonucu server-side policy’ye dönüştürmelidir.

Attestation, abuse ve tampering maliyetini artırabilir. Ele geçirilmiş kullanıcı hesabının başka kullanıcı resource’una erişmesini engelleyen object authorization değildir.

18. Notification, screenshot ve clipboard neden pentest kapsamındadır?

Mobil veri exposure çoğu zaman sofistike bir cryptographic attack gerektirmez. Hassas bilgi operating system’in normal UX özellikleri üzerinden görünür olabilir.

Notification

Push notification body’sinde tam kart numarası, sağlık sonucu, OTP, para transferi detayı veya kişisel mesaj göstermek locked screen’de exposure yaratabilir. Notification mümkün olduğunca genel olmalı, hassas içerik uygulama açıldıktan ve session doğrulandıktan sonra API’den alınmalıdır.

{
  "title": "Yeni bir hesap hareketiniz var",
  "body": "Ayrıntıları görmek için uygulamayı açın",
  "data": {
    "eventId": "evt_72cd"
  }
}

eventId de yetkisiz resource erişimi sağlamamalıdır. Push payload bir navigation hint’tir.

Screenshot ve app switcher snapshot

Sensitive screen background’a geçtiğinde recent-apps görünümünde kalabilir. Test, finansal veri, authentication seed, kimlik belgesi ve sağlık verisi gibi ekranlarda platforma uygun masking uygulanıp uygulanmadığını kontrol eder.

Clipboard

Clipboard’a kopyalanan token, password veya kişisel veri başka uygulamalar ve senkronizasyon mekanizmaları tarafından görülebilir. Kopyalama gerçekten gerekliyse veri türü, expiration ve kullanıcıya verilen görünürlük değerlendirilmelidir.

Bu kontroller API testinde görünmez. API doğru response verse bile client veriyi yanlış yaşam döngüsünde açığa çıkarabilir.

19. API token güvenliği iki katmanda birlikte test edilmelidir

Token güvenliği yalnızca JWT algorithm kontrolü değildir. Token’ın nasıl üretildiği, nerede saklandığı, hangi request’te kullanıldığı ve ne zaman iptal edildiği uçtan uca değerlendirilir.

Refresh token rotation yarış durumu

Mobil uygulama network retry nedeniyle aynı refresh token’ı iki parallel request’te kullanabilir. Backend’in rotation tasarımı hem token theft detection hem de normal retry davranışını doğru yönetmelidir.

Örnek bir server-side model:

family_id: 4c8f...
token_id: 91de...
parent_id: 77ab...
status: ACTIVE | USED | REVOKED
issued_at
expires_at
device_id

Kullanılmış refresh token yeniden görülürse yalnızca o token’ın değil, risk modeline göre token family’nin iptali düşünülebilir. Mobil client ise rotation response’unu güvenli ve atomic biçimde saklamalıdır. Crash sırasında eski ve yeni token state’i belirsiz kalırsa kullanıcı lockout veya false theft detection oluşabilir.

Oturumun login’den logout’a kadar nasıl güvence altına alınması gerektiğini Oturum Yönetiminde En Sık Yapılan Hatalar yazısında daha ayrıntılı ele alıyoruz.

20. iOS ve Android için ayrı sızma testi gerekir mi?

Çoğu kurumsal uygulamada evet. iOS ve Android aynı backend’i ve büyük ölçüde aynı business flow’u kullanabilir. Bu ortaklık API test eforunu azaltır. Fakat platforma özgü binary, storage, permission, IPC ve link handling yüzeyi nedeniyle iki mobil build birbirinin yerine test edilmiş sayılmaz.

Ortak codebase de bu gerçeği değiştirmez. Flutter, React Native, Kotlin Multiplatform veya başka cross-platform framework kullanıldığında shared business code bulunabilir. Yine de native bridge, package configuration, secure storage adapter, WebView, signing ve OS permission davranışı platforma özgüdür.

Her iki platform için efor tam olarak iki katına çıkar mı?

Genellikle hayır. Şu alanlar paylaşılabilir:

• Discovery ve threat model
• API inventory
• Test persona ve account seti
• Business workflow analizi
• Backend authorization testleri
• Integration ve webhook kontrolleri
• Root cause analizi

Şu alanlar ayrı çalışılır:

• Binary static analysis
• Platform configuration
• Local storage implementation
• IPC ve link handling
• Native WebView bridge
• Platform permission’ları
• Runtime instrumentation
• Platform-specific remediation doğrulaması

Doğru teklif bu ortak ve ayrı eforu görünür kılar. “İki platform var, fiyat otomatik iki kat” veya “aynı backend’i kullanıyor, tek platform yeter” yaklaşımlarının ikisi de teknik kapsamı doğru ifade etmez.

21. Black box, gray box ve white box API/mobil pentestte neyi değiştirir?

Test yaklaşımı yalnızca uzmana ne kadar bilgi verildiğini değil, ayrılan sürede hangi güvenlik sorularına güvenilir cevap üretilebileceğini belirler.

Black box

Test ekibine store’dan indirilen uygulama ve dışarıdan erişilebilen sistem verilir. API dokümanı, source code veya özel test hesabı sağlanmaz.

Bu model dış saldırgan perspektifini gösterir. Fakat şu sınırlara sahiptir:

• MFA, onboarding veya bölgesel erişim nedeniyle function coverage düşük kalabilir
• Birden fazla role ve tenant olmadan authorization matrisi kurulamaz
• Pinning, test trafiğinin gözlemlenmesini yavaşlatabilir
• Backend inventory yalnız runtime keşfine dayanır
• Nadir çalışan code path’ler görünmeyebilir
• Third-party integration ile kurum varlığı ayrıştırılamayabilir

Black box değerli bir perspektiftir. Fakat kapsamlı kurumsal güvence iddiası için çoğu mobil/API ürününde tek başına yeterli değildir.

Gray box

Gray box, çoğu kurumsal API/mobil pentest için dengeli seçenektir. Genellikle şu girdiler sağlanır:

• Release veya release’e yakın APK/IPA
• En az iki normal kullanıcı hesabı
• Farklı role ve tenant hesapları
• API host ve version envanteri
• OpenAPI, Postman collection veya GraphQL schema
• Test environment ve güvenli test verisi
• MFA veya OTP test akışı
• Kritik business workflow açıklaması
• Pinning bulunan build için test seçeneği

Bu model, uzmanı gerçek saldırgan davranışından uzaklaştırmaz. Keşfe ayrılan zamanı azaltarak authorization, business logic ve platform davranışına daha fazla efor bırakır.

White box

White box çalışmada source code, build file’ları, architecture dokümanı, threat model, CI/CD configuration ve ilgili cloud/IAM bağlamı da incelenebilir.

Özellikle şu durumlarda anlamlıdır:

• High assurance gereken finans, sağlık veya kritik altyapı uygulaması
• Complex cryptographic protocol
• Custom authentication veya device binding
• Büyük ve version’lı API yüzeyi
• Native code ve dynamic code loading
• Çok sayıda third-party SDK
• Önceki pentestte root cause’u netleşmeyen kritik bulgu
• Release öncesi security gate

Black box, gray box ve white box perspektiflerinin coverage’a etkisini Black Box, Gray Box, White Box Sızma Testi yazısında ayrıntılı karşılaştırıyoruz.

22. Ayrı test mi, ayrı sözleşme mi?

“API ve mobil uygulama için ayrı sızma testi gerekir” cümlesi mutlaka iki bağımsız satın alma, iki ayrı başlangıç toplantısı ve birbiriyle konuşmayan iki rapor anlamına gelmez.

En verimli model çoğu zaman şudur:

• Tek yetkilendirme ve Rules of Engagement
• Ortak architecture ve scope discovery
• Ortak test takvimi
• Mobil ve API için ayrı coverage listesi
• Aynı test persona ve verisinin kontrollü paylaşımı
• Bulgular için ortak root cause analizi
• Tek yönetici özeti
• Component bazında ayrılmış teknik bulgular
• Cross-layer attack chain’lerin ayrıca gösterilmesi
• Koordine retest

Bu yapı hem mükerrer eforu azaltır hem de katmanlar arasındaki ilişkiyi kaybetmez.

Örneğin iOS ve Android aynı /api/v2/ backend’ini kullanıyorsa API authorization testi bir kez, yeterli role ve endpoint coverage ile yürütülebilir. Android ve iOS local storage, link handling ve platform configuration kontrolleri ayrı yapılır.

23. Hangi durumda hangi kapsam gerekir?

Tek doğru cevap, uygulamanın mimarisine ve riskine bağlıdır. Aşağıdaki karar matrisi teklif hazırlarken başlangıç noktası olarak kullanılabilir.

API’siz uygulama gerçekten var mı?

Bir uygulamanın ana function’ı offline olabilir. Yine de analytics, crash reporting, feature flag, license, update, push notification veya content download endpoint’leri bulunabilir. Scope kararı runtime traffic ve package analizi sonrasında kesinleştirilmelidir.

Third-party API’yi izinsiz test etmeyin

Mobil uygulamada görülen her host kuruma ait değildir. Payment provider, analytics, map, identity provider ve messaging service üçüncü taraf olabilir. Kurumun sözleşmesi bu varlıkların aktif testine izin vermiyorsa endpoint kapsam dışı bırakılır veya ilgili sağlayıcıdan yazılı yetki alınır.

Scope formu tek başına sınırsız test yetkisi oluşturmaz. Hedefler, izin verilen teknikler, zaman aralığı, veri işleme ve yasaklı action’lar imzalı teklif, sözleşme veya Statement of Work ve Rules of Engagement içinde açıkça bağlanmalıdır.

24. API/mobil pentest kapsamı nasıl yazılmalı?

“Bir adet mobil uygulama ve API” ifadesi fiyat almak için bile çoğu zaman yetersizdir. Eforu belirleyen gerçek değişkenler görünür olmalıdır.

Mobil scope bilgileri

• Platformlar: Android, iOS veya ikisi
• Package ID ve bundle ID
• Test edilecek version ve build number
• Distribution channel
• Production, staging veya özel test build’i
• Native, hybrid veya cross-platform teknoloji
• Release ve debug configuration farkı
• Obfuscation ve pinning durumu
• Rooted veya jailbroken device test izni
• TestFlight, enterprise veya APK teslim yöntemi
• Deep link, app link ve universal link listesi
• WebView kullanılan ekranlar
• Push notification ve background task akışları
• Local/offline data ve backup davranışı
• App extension, App Group ve Android component envanteri
• Third-party SDK listesi
• Kaynak kod dahil olup olmadığı

API scope bilgileri

• Base URL ve environment
• API version’ları
• REST, GraphQL, gRPC, WebSocket ve webhook yüzeyleri
• Endpoint veya operation sayısı
• OpenAPI, Postman collection ve schema durumu
• Authentication ve OAuth flow’ları
• User, role ve tenant sayısı
• Critical business workflow’lar
• Rate limit ve test kısıtları
• File upload/download ve report export
• Third-party integration host’ları
• Destructive action ve financial transaction kısıtları
• Test verisi ve data reset yöntemi

Test account matrisi

Authorization testi için yalnızca account sayısı değil, actor ilişkisi önemlidir.

Tek kullanıcı hesabıyla “authorization test edildi” denmesi coverage iddiasını zayıflatır.

Web ve API scope’unu role, asset ve integration düzeyinde kurmanın ayrıntılarını Web Uygulaması Sızma Testinde Kapsam Nasıl Belirlenir? yazısında bulabilirsiniz.

25. Sağlıklı bir API/mobil pentest nasıl yürütülür?

Koordineli çalışma, iki ekibin aynı anda rastgele test yapması değildir. Güven sınırları ve coverage baştan tasarlanır.

Aşama 1: Yetkilendirme ve Rules of Engagement

Hedef package’lar, API host’ları, third-party exclusions, izin verilen test teknikleri, çalışma saatleri, emergency contact ve test verisi netleştirilir.

Özellikle şu durumlar açıkça kararlaştırılmalıdır:

• Production üzerinde test yapılıp yapılmayacağı
• Account lockout ve MFA abuse limitleri
• Gerçek ödeme veya transfer oluşturulup oluşturulmayacağı
• Root/jailbreak ve runtime instrumentation izni
• Social engineering kapsamı
• DoS ve resource consumption test sınırı
• Third-party service’lere request gönderim sınırı
• Kişisel veriyle karşılaşılması hâlinde işleme yöntemi
• Kritik bulgunun anlık bildirim kanalı

Aşama 2: Architecture ve trust-boundary mapping

Uygulamanın yalnız ekran haritası değil, veri ve yetki akışı çıkarılır:

Mobile App
   │
   ├── Identity Provider
   │       └── MFA / OAuth / PKCE
   │
   ├── API Gateway
   │       ├── BFF
   │       ├── Account Service
   │       ├── Payment Service
   │       └── Notification Service
   │
   ├── Push Provider
   ├── Analytics SDK
   └── Deep Link Domains

Her sınırda şu sorular sorulur:

• Kim kime güveniyor?
• Kim hangi identifier’ı belirliyor?
• Authorization hangi component’te enforce ediliyor?
• Sensitive data nerede kalıcılaşıyor?
• Credential hangi katmanlardan geçiyor?
• Third-party response’u authoritative kabul eden yer var mı?

Aşama 3: Mobil static analysis

APK veya IPA üzerinde şu alanlar incelenir:

• Package structure ve native library’ler
• Manifest, Info.plist ve entitlement
• Exported surface
• URL scheme ve associated domain
• Network security configuration ve ATS exception
• Hardcoded host, key ve environment değerleri
• Logging ve debug flag’leri
• Backup configuration
• Third-party SDK ve dependency’ler
• WebView ve native bridge code’u
• Cryptographic API kullanımı
• Feature flag ve hidden route’lar

Aşama 4: Mobil dynamic analysis

Uygulama gerçek runtime’da gözlemlenir:

• Login, logout, token refresh ve account change
• Local file ve database değişimi
• Clipboard, notification ve screenshot davranışı
• Deep link’in cold ve warm start davranışı
• IPC ve exported component çağrıları
• WebView navigation
• TLS failure ve offline behavior
• Runtime tampering karşısındaki risk
• Background ve foreground lifecycle
• App update ve migration

Aşama 5: API inventory ve authorization matrisi

Doküman, runtime traffic ve binary string’leri karşılaştırılır. Her operation için en az şu bilgiler tutulur:

operation: GET /api/v2/accounts/{accountId}/transactions
authentication: user_access_token
roles:
  - customer
  - support_readonly
object_owner: account.customer_id
tenant_boundary: account.tenant_id
sensitive_fields:
  - counterparty
  - amount
  - description
negative_tests:
  - same_tenant_non_owner
  - cross_tenant
  - suspended_user
  - expired_token

Bu yaklaşım, birkaç ID değiştirip “IDOR yok” sonucuna varmaktan daha ölçülebilir coverage sağlar.

Aşama 6: Cross-layer attack chain doğrulaması

Mobil ve API bulguları birlikte zincirlenir. Örneğin:

Hassas refresh token backup'a dahil
        ↓
Token başka test cihazında geri yüklenebiliyor
        ↓
Backend token'ı device binding olmadan kabul ediyor
        ↓
High-risk action için re-authentication yok
        ↓
Hesap üzerinde yetkili işlem yapılabiliyor

Tek tek bulgular orta seviyede görünebilir. Birleştiğinde account takeover veya transaction etkisi yaratabilir.

Aşama 7: Raporlama ve retest

Bulgu, yalnızca ekran görüntüsü ve genel öneriden oluşmamalıdır. Root cause, etkilenen katman, precondition, reproducible PoC, veri veya işlem etkisi, remediation owner ve retest sonucu bulunmalıdır.

26. API ve mobil bulgular nasıl raporlanmalı?

Tek rapor içinde her bulgunun kaynağı görünür olmalıdır:

• MOB- ile mobile client bulgusu
• API- ile backend veya API bulgusu
• CHAIN- ile birden fazla katmanı birleştiren attack path

Bu prefix zorunlu değildir. Ama remediation sorumluluğunu ve retest scope’unu anlaşılır kılar.

İyi bir teknik bulgu neleri içerir?

• Başlık
• Severity ve risk gerekçesi
• Etkilenen platform, version ve environment
• Etkilenen endpoint, component veya file
• Preconditions
• Adım adım doğrulama
• Request ve response evidence
• Mobile runtime veya static evidence
• Gerçek iş etkisi
• Root cause
• Teknik remediation
• Compensating control
• Retest kriteri
• İlgili OWASP MASVS, MASWE, API Security veya ASVS referansı

Örnek bulgu özeti:

Bulgu: Android backup üzerinden refresh token'ın geri yüklenebilmesi

Katman: Android client + API session lifecycle

Precondition:
- Test kullanıcısına ait device backup'a erişim
- Uygulamanın başka test cihazına kurulabilmesi

Gözlem:
- Refresh token backup'a dahil edilen application data içinde bulunuyor
- Restore sonrasında API token'ı aynı device bağlamı aranmadan kabul ediyor
- Password değişimi token family'yi iptal etmiyor

Etki:
- Geçerli token ömrü boyunca account access
- Hassas action'larda re-authentication yoksa işlem etkisi

Remediation:
- Token'ı backup dışında tutmak
- Platform secure storage ve uygun device migration policy kullanmak
- Refresh token rotation ve reuse detection uygulamak
- Password/MFA değişiminde risk bazlı session revocation
- Hassas action için step-up authentication

Bu yaklaşım “token şifrelenmeli” şeklindeki tek satırlık öneriden daha uygulanabilirdir. Çünkü client ve backend ekiplerinin sorumluluklarını ayırır.

27. Severity nasıl belirlenmeli?

CVSS teknik ortak dil sağlar. Fakat mobile/API finding severity yalnızca zafiyet sınıfının adına göre verilmemelidir.

Şu faktörler birlikte değerlendirilir:

• Saldırganın cihazı fiziksel olarak kontrol etmesi gerekiyor mu?
• Kötü niyetli uygulama kurdurma gerekiyor mu?
• Authentication gerekiyor mu?
• Başka kullanıcı veya tenant etkileniyor mu?
• Token kısa mı uzun ömürlü mü?
• İşlem için re-authentication var mı?
• Veri yalnız cache’de mi, yoksa kalıcı ve backup’a dahil mi?
• Exploit user interaction gerektiriyor mu?
• Backend exploitation’ı sınırlıyor mu?
• Etki confidentiality, integrity, availability veya finansal işlem mi?
• Aynı root cause kaç endpoint veya platformu etkiliyor?

Örnekler:

• Public map identifier’ın binary’de görünmesi, sıkı provider restriction varsa informational olabilir
• Backend service account private key’i APK içindeyse critical etki doğurabilir
• Root detection bulunmaması public katalog app’inde zafiyet olmayabilir
• Root detection bulunmaması, server’ın yüksek tutarlı işlemleri yalnız local kontrole bağladığı durumda büyük attack chain’in parçası olabilir
• Custom URL scheme kullanımı tek başına yeterli olmayabilir, password reset token’ı hijack edilebiliyorsa account takeover etkisi doğurabilir

Risk puanı, remediation sırasını açıklamalıdır. Pazarlama etkisi yaratmak için severity büyütmek güvenliği iyileştirmez.

28. Retest neden iki katmanda yapılmalıdır?

Bir API BOLA bulgusu backend’de düzeltildiğinde Android ve iOS binary’nin yeniden build edilmesi gerekmeyebilir. Bir Android backup bulgusu düzeltildiğinde API değişmeyebilir. Fakat cross-layer attack chain söz konusuysa yalnızca bir patch’in varlığı zincirin kapandığını kanıtlamaz.

Retest şu üç düzeyde yapılmalıdır:

1. 1Bulgunun doğrudan tekrar testi
2. 2Aynı root cause’a sahip benzer endpoint veya component regression testi
3. 3Varsa attack chain’in uçtan uca yeniden yürütülmesi

Örneğin token local storage’dan Keychain’e taşındıysa şu kontroller de yapılır:

• Eski version’dan update sırasında plaintext token kalıyor mu?
• Logout sonrası yeni storage temizleniyor mu?
• Backup ve migration policy doğru mu?
• Crash log veya analytics’e token gidiyor mu?
• Backend stolen token için hâlâ sınırsız ömür sunuyor mu?

Retest yalnızca “ilgili file’da artık string görünmüyor” kontrolü değildir.

29. API/mobil pentest teklifinde hangi teslimatlar istenmeli?

Teklifte yalnızca “OWASP standardına göre test” yazılması coverage’ı açıklamaz. Aşağıdaki maddeler açıkça görülmelidir:

1. 1Android, iOS ve API scope’unun ayrı listesi
2. 2API protocol ve version kapsamı
3. 3Test role ve tenant sayısı
4. 4Black box, gray box veya white box yaklaşımı
5. 5OWASP MASVS/MASTG ve API Security referansları
6. 6Automated araç ile manuel test ayrımı
7. 7Business logic ve authorization test yaklaşımı
8. 8Static, dynamic, network ve platform interaction coverage’ı
9. 9Third-party varlık ve test kısıtları
10. 10Rules of Engagement ve kritik bildirim yöntemi
11. 11Yönetici özeti ve teknik rapor ayrımı
12. 12PoC ve remediation beklentisi
13. 13Retest kapsamı ve süresi
14. 14Verinin saklanması, şifrelenmesi ve imha yöntemi
15. 15Tester yetkinliği ve benzer uygulama deneyimi

İyi teklif, kaç scanner çalıştırılacağını değil hangi güven kararlarının doğrulanacağını anlatır. Sızma testi teklifinde teknik maddelerin nasıl okunacağını Sızma Testi Teklifinde Hangi Teknik Maddeler Olmalı? yazısında inceleyebilirsiniz.

30. Geliştirme ekipleri için API ve mobil güvenlik kontrol listesi

Backend ve API

• [ ] Authorization her request’te server-side enforce ediliyor
• [ ] Resource, actor ve tenant ilişkisi policy içinde doğrulanıyor
• [ ] Request DTO allowlist ile tasarlanıyor
• [ ] Response DTO gereksiz hassas field döndürmüyor
• [ ] Access token issuer, audience, expiration ve scope doğrulanıyor
• [ ] Refresh token rotation ve reuse detection var
• [ ] Password, MFA ve riskli account değişiklikleri session lifecycle’ı etkiliyor
• [ ] Critical workflow server-side state machine ile korunuyor
• [ ] Financial ve sensitive action idempotent tasarlanıyor
• [ ] Rate limit account, device, IP ve business action bağlamında uygulanıyor
• [ ] Eski API version ve shadow endpoint envanteri tutuluyor
• [ ] Webhook signature, timestamp ve replay kontrolü var
• [ ] Third-party API response’u validation olmadan authoritative kabul edilmiyor
• [ ] Error response hassas internal ayrıntı sızdırmıyor
• [ ] Audit log security decision için yeterli bağlam taşıyor

Android ve iOS client

• [ ] Token ve key için uygun Keychain/Keystore policy kullanılıyor
• [ ] Hassas veri cache, log, notification ve analytics’e yazılmıyor
• [ ] Backup ve migration davranışı veri sınıfına göre belirleniyor
• [ ] Logout ve account removal local veriyi temizliyor
• [ ] Cleartext traffic kapalı
• [ ] Certificate ve hostname validation override edilmiyor
• [ ] Test CA yalnız debug build’de kabul ediliyor
• [ ] Pinning varsa backup pin ve rotation planı var
• [ ] Deep link input’u güvenilmeyen input olarak doğrulanıyor
• [ ] OAuth callback state ve PKCE kullanıyor
• [ ] WebView yalnız gerekli capability’leri açıyor
• [ ] Android component’ler explicit exported policy kullanıyor
• [ ] Sensitive screen snapshot davranışı kontrol ediliyor
• [ ] Clipboard kullanımı minimize ediliyor
• [ ] Production build debug feature ve verbose log içermiyor
• [ ] Binary içine server secret veya private key konulmuyor
• [ ] Third-party SDK permission ve data flow’u envanterli
• [ ] Biometrics yalnız local boolean’a dönüşmüyor
• [ ] Attestation server-side, nonce ve replay korumasıyla doğrulanıyor
• [ ] Root/jailbreak sinyali tek authorization kontrolü olarak kullanılmıyor

Test ve release süreci

• [ ] API contract ve role matrisi güncel
• [ ] Android ve iOS release candidate ayrı doğrulanıyor
• [ ] SAST, SCA ve secrets scanning CI/CD içinde çalışıyor
• [ ] API negative authorization testleri regression suite’te bulunuyor
• [ ] Mobil security unit ve integration testleri var
• [ ] Production signing ve entitlement change’i gözden geçiriliyor
• [ ] Yeni SDK ve permission security review tetikliyor
• [ ] Major release ve kritik backend değişimi pentest scope’unu güncelliyor
• [ ] Kritik bulgular için retest release öncesi tamamlanıyor

32. Sonuç: Ayrı yüzeyleri tek attack chain üzerinde ölçün

Mobil uygulama ve API aynı ürün deneyimini oluşturur. Güvenlik bakımından ise farklı sorumlulukları ve farklı failure mode’ları vardır.

API’nin görevi, client’tan gelen hiçbir authorization iddiasına koşulsuz güvenmeden actor, resource, tenant, function ve workflow state ilişkisini server-side enforce etmektir. Mobil uygulamanın görevi, kullanıcının cihazındaki credential ve veriyi platforma uygun mekanizmalarla korumak, operating system ve diğer uygulamalarla etkileşimi daraltmak ve backend’e güvenilir olmayan input taşımamaktır.

Bu nedenle yalnız API testi yaptırıp mobil binary’yi kapsam dışında bırakmak client attack surface’ini görünmez kılar. Yalnız mobil uygulamayı inceleyip API’yi birkaç proxy request’iyle sınırlamak ise server-side authorization, version inventory ve business logic coverage’ını belirsiz bırakır.

Doğru model şudur:

1. 1API ve mobil için ayrı test hedefleri
2. 2Ortak architecture ve threat model
3. 3Ortak test persona ve workflow
4. 4Platforma özgü Android ve iOS coverage’ı
5. 5API için ölçülebilir operation, role ve tenant matrisi
6. 6Cross-layer attack chain analizi
7. 7Root cause odaklı raporlama
8. 8Her iki katmanı kapsayan retest

SECNODEX Sızma Testi hizmeti kapsamında web, API, Android ve iOS attack surface’lerini uygulamanın mimarisine göre ayrı coverage ölçütleriyle değerlendirir. Manuel doğrulama, yeniden üretilebilir PoC, iş etkisi, remediation adımları ve retest ile yalnızca bulgu listesi değil, hangi güven kararının nerede bozulduğunu gösteren teknik bir çıktı sunar.

Mobil uygulamanızın yalnız binary’sini ya da yalnız API host’unu değil, gerçek veri ve işlem akışını kapsayan bir scope oluşturmak için SECNODEX ile iletişime geçebilirsiniz.

Kaynaklar

• OWASP Mobile Application Security Verification Standard
• OWASP Mobile Application Security Testing Guide
• OWASP API Security Top 10:2023
• OWASP API Security Project
• OWASP Application Security Verification Standard
• Android Developers: Network Security Configuration
• Android Developers: Mitigate Security Risks in Your App
• Android Developers: Cross-App Scripting in WebView
• Android Developers: Key Attestation
• Apple Platform Security: Keychain Data Protection
• Apple Developer: Allowing Apps and Websites to Link to Your Content
• Apple Developer: App Transport Security

---

Editoryal iç link notu: Yayından sonra bu yazıya /blog/sizma-testi-nedir-kapsamli-rehber, /blog/web-uygulamasi-sizma-testinde-kapsam-nasil-belirlenir, /blog/black-box-gray-box-white-box-sizma-testi, /blog/idor-acigi-neden-hala-bu-kadar-yaygin, /blog/oturum-yonetiminde-en-sik-yapilan-hatalar ve /blog/kod-incelemesinde-business-logic-aciklari-nasil-yakalanir sayfalarından bağlamsal geri bağlantı verilmesi cluster ilişkisini çift yönlü güçlendirir.