OWASP M1 (2024): React Native Kimlik Bilgisi Kullanım Güvenliği

React Native ve Expo uygulamalarında OWASP M1 (2024) Improper Credential Usage güvenlik açığını anlamak, mobil uygulamalarınızın kritik savunmasını oluşturur. Bu makalede, kimlik bilgilerinin yanlış kullanım risklerini, gerçek dünya senaryolarını ve bu tehditlere karşı etkili mitigasyon stratejilerini derinlemesine inceleyeceğiz. Uygulama güvenliğinizi en üst düzeye çıkarmak için adım adım rehberimizle hemen başlayın.

Mobil uygulamalar, günümüz dijital dünyasında hayatımızın vazgeçilmez bir parçası haline geldi. Bankacılıktan sosyal medyaya, sağlıktan e-ticarete kadar pek çok alanda, hassas verilere doğrudan erişim sağlıyor ve kullanıcıların kişisel bilgilerini işliyorlar. Ancak bu kolaylık ve erişilebilirlik, beraberinde önemli güvenlik risklerini de getiriyor. İşte tam bu noktada, OWASP (Open Web Application Security Project) Mobil Top 10 listesi devreye giriyor. Bu liste, mobil uygulama geliştiricileri ve güvenlik uzmanları için en kritik mobil güvenlik açıklarını derleyerek bir yol haritası sunuyor.

2024 güncellemesiyle birlikte, OWASP Mobil Top 10 listesinin ilk sırasında yer alan M1: “Improper Credential Usage” (Hatalı Kimlik Bilgisi Kullanımı) maddesi, mobil uygulama güvenliğindeki en büyük tehditlerden birine işaret ediyor. Peki, bu kavram tam olarak ne anlama geliyor ve neden özellikle React Native ve Expo gibi popüler geliştirme ortamlarında bu kadar kritik bir öneme sahip? Kısaca ifade etmek gerekirse, M1, uygulamanızın hassas kimlik bilgilerini (API anahtarları, şifreler, token’lar, sertifikalar vb.) yanlış bir şekilde depolaması, işlemesi veya iletmesi durumunda ortaya çıkan güvenlik zafiyetini kapsar. Bu tür bir hata, yetkisiz erişimden veri sızıntısına, hatta uygulamanın tamamen ele geçirilmesine kadar ciddi sonuçlar doğurabilir.

React Native ve Expo, geliştiricilere hızlı ve verimli bir şekilde platformlar arası mobil uygulamalar oluşturma yeteneği sunar. JavaScript/TypeScript tabanlı olmaları, büyük bir geliştirici topluluğuna sahip olmaları ve geliştirme sürecini basitleştirmeleri bu platformların tercih edilmesinin başlıca nedenleridir. Ancak bu esneklik ve hız, beraberinde belirli güvenlik zorluklarını da getirmektedir. Örneğin, JavaScript kodu tersine mühendisliğe daha açık olabilir ve geliştiriciler, web ortamından gelen alışkanlıklarla hassas bilgileri yanlış yerlerde saklama eğiliminde olabilirler. Bu durum, OWASP M1 ihlallerine davetiye çıkarabilir.

Bu makalenin amacı, React Native ve Expo ile geliştirilen uygulamalarda OWASP M1’in ne anlama geldiğini, hangi senaryolarda ortaya çıktığını ve en önemlisi, bu ciddi güvenlik açığını nasıl etkili bir şekilde önleyebileceğinizi ve azaltabileceğinizi adım adım açıklamaktır. Uygulamanızın güvenliğini sağlamak, sadece kullanıcı güvenini kazanmakla kalmaz, aynı zamanda yasal düzenlemelere uyum sağlamak ve itibarınızı korumak için de hayati önem taşır. Bu nedenle, M1’i doğru bir şekilde anlamak ve mitigasyon stratejilerini uygulamak, her mobil uygulama geliştiricisinin öncelikli görevi olmalıdır.

OWASP M1 (2024) “Improper Credential Usage” Temel Kavramları Nelerdir?

OWASP M1: “Improper Credential Usage” (Hatalı Kimlik Bilgisi Kullanımı), mobil uygulamaların en yaygın ve tehlikeli güvenlik açıklarından birini temsil eder. Bu açık, uygulamanın kimlik bilgilerini, yani kullanıcıları veya diğer sistemleri doğrulamak için kullanılan her türlü hassas veriyi, yanlış, güvensiz veya standartlara uygun olmayan bir şekilde işlemesi durumunda ortaya çıkar. Kimlik bilgileri sadece kullanıcı adları ve şifrelerle sınırlı değildir; API anahtarları, oturum token’ları, kriptografik anahtarlar, sertifikalar ve hatta uygulamanın dahili yapılandırma parametreleri de bu kategoriye girer.

Bu zafiyetin temelinde yatan sorun, hassas bilgilerin istemci tarafında (yani kullanıcının mobil cihazında) ne kadar güvenli bir şekilde saklandığı, iletildiği ve işlendiği konusundaki eksikliklerdir. Geliştiriciler bazen hız ve kolaylık adına veya güvenlik en iyi uygulamalarını göz ardı ederek, bu tür kritik verileri kolayca erişilebilir konumlara yerleştirebilirler. Bu da bir saldırganın, tersine mühendislik, fiziksel erişim veya diğer tekniklerle bu bilgilere ulaşmasına olanak tanır.

React Native/Expo Ortamında Kimlik Bilgileri Nasıl Risk Altına Girer?

React Native ve Expo’nun doğası gereği, geliştiricilerin JavaScript/TypeScript kodu doğrudan cihazda çalışır. Bu durum, web tabanlı geliştirme alışkanlıklarından gelen bazı riskleri mobil dünyaya taşır. İşte React Native/Expo uygulamalarında M1’in ortaya çıkabileceği bazı yaygın senaryolar:

• Kaynak Kodda Sabit Kodlama (Hardcoding): En temel ve en tehlikeli hatalardan biridir. API anahtarları, veritabanı kimlik bilgileri veya özel servis URL’leri gibi hassas bilgilerin doğrudan JavaScript kodunun içine yazılması durumudur. Uygulama derlendikten sonra, bu bilgiler kolayca tersine mühendislik (reverse engineering) yoluyla elde edilebilir. Bir saldırgan, uygulamanın APK veya IPA dosyasını dekompile ederek kaynak kodu inceleyebilir ve bu sabit kodlanmış sırları bulabilir.

  
                  // Kötü örnek: Kimlik bilgisi doğrudan kod içinde
                  const API_KEY = "sk_live_thisisyoursecretkey_asla_yapmayin"; // Asla yapmayın!
  
                  async function fetchData() {
                      const response = await fetch('https://api.example.com/data', {
                          headers: {
                              'Authorization': Bearer ${API_KEY}
                          }
                      });
                      // ...
                  }
              

• Güvensiz Depolama Mekanizmaları: React Native uygulamaları genellikle yerel depolama için AsyncStorage gibi mekanizmalar kullanır. AsyncStorage, verileri cihazın dosya sisteminde düz metin olarak veya kolayca erişilebilir formatlarda saklayabilir. Bu, kötü niyetli bir uygulamanın veya fiziksel erişimi olan bir saldırganın bu verilere kolayca ulaşabileceği anlamına gelir. Hassas veriler asla AsyncStorage'da tutulmamalıdır.
• Hatalı Çevre Değişkeni Yönetimi: Geliştiriciler genellikle hassas bilgileri çevre değişkenleri (örneğin .env dosyaları) aracılığıyla yönetirler. Ancak React Native veya Expo'da, bu değişkenlerin nasıl kullanıldığı kritik öneme sahiptir. Varsayılan olarak, .env dosyasındaki değişkenler build sürecinde bundle içine gömülür ve bu da yine tersine mühendislik yoluyla erişilebilir hale gelebilir.

  
                  // Kötü örnek: .env dosyasında hassas bilgiyi doğru şekilde kullanmamak
                  // .env dosyasında: REACT_APP_API_KEY=sk_live_thisisyoursecretkey
                  // JS kodunda: process.env.REACT_APP_API_KEY
                  // Bu hala bundle içine girebilir ve güvenli değildir!
              

• Zayıf İletişim Güvenliği: Kimlik bilgilerinin sunucuya iletilirken şifrelenmemesi veya zayıf şifreleme yöntemlerinin kullanılması da M1 ihlaline yol açar. Man-in-the-middle (Ortadaki Adam) saldırılarıyla bu bilgiler kolayca ele geçirilebilir. HTTP yerine HTTPS kullanmak temel bir gerekliliktir, ancak sadece HTTPS kullanmak yeterli olmayabilir; uygun sertifika sabitleme (certificate pinning) gibi ek önlemler gerekebilir.
• Hata Ayıklama (Debugging) Bilgilerinin Kalması: Geliştirme sürecinde kullanılan test kimlik bilgileri, loglar veya hata ayıklama çıktıları gibi bilgiler, üretim ortamına taşındığında unutulabilir. Bu bilgiler de saldırganlar için birer giriş kapısı olabilir.

Bu riskleri anlamak, mitigasyon stratejilerini doğru bir şekilde uygulamanın ilk adımıdır. Unutmayın, bir mobil uygulamanın güvenliği, en zayıf halkası kadar güçlüdür ve kimlik bilgileri genellikle bu zayıf halkalardan biri olmaya adaydır.

Gerçek Dünya Senaryoları ve Vaka Analizleri: Hatalı Kimlik Bilgisi Kullanımı Nasıl Zarar Verir?

Hatalı kimlik bilgisi kullanımı (OWASP M1), sadece teorik bir risk değil, dünya genelinde birçok veri ihlaline ve güvenlik zafiyetine yol açmış somut bir tehdittir. Bu bölümde, React Native/Expo bağlamında ortaya çıkabilecek veya mobil uygulamaları etkileyen bazı gerçek dünya senaryolarını ve vaka analizlerini inceleyerek, M1'in ne kadar yıkıcı olabileceğini daha iyi anlayacağız.

• Vaka 1: Kaynak Kod Analizi ile Sızan API Anahtarları (Hardcoding Faciası)

  Bir e-ticaret uygulaması, ürün listelerini ve ödeme işlemlerini yönetmek için üçüncü taraf bir API kullanıyordu. Geliştirici, API anahtarını uygulamanın JavaScript kodunda sabit olarak tanımlamıştı (const API_KEY = "prod_api_key_12345";). Uygulama mağazasına yüklendikten kısa bir süre sonra, kötü niyetli bir aktör, uygulamanın APK dosyasını indirdi ve basit bir dekompilasyon aracı kullanarak JavaScript kaynak koduna ulaştı. Kod içinde yer alan API anahtarını kolayca tespit etti. Bu anahtar, uygulamanın arka ucuna yetkili erişim sağlayabiliyordu. Saldırgan, bu anahtarı kullanarak sahte siparişler oluşturdu, indirim kuponları üretti ve hatta müşteri bilgilerini görüntüleyebildi. Şirket, bu durumu fark ettiğinde milyonlarca dolarlık zarar ve büyük bir itibar kaybıyla karşı karşıya kaldı.

  Uzman İpucu: Herhangi bir hassas bilginin (API anahtarı, sır vb.) doğrudan kaynak kodunuzda veya uygulamanın nihai paketinde yer almadığından emin olmak için düzenli güvenlik denetimleri yapın. Statik kod analizi araçları bu tür sorunları otomatik olarak tespit edebilir.
• Vaka 2: Geliştirme Ortamı Hataları ve Üretime Sızan Veriler

  Büyük bir finansal hizmetler şirketi, müşterileri için bir mobil bankacılık uygulaması geliştiriyordu. Geliştirme ekibi, test ortamında canlı müşteri verilerini taklit etmek için gerçekçi, ancak sahte kimlik bilgileri ve test API anahtarları kullanıyordu. Ancak, test ortamındaki bir yapılandırma hatası veya birim testlerinde kullanılan sabit kodlanmış test kimlik bilgileri, yanlışlıkla üretim sürümüne dahil edildi. Uygulama yayınlandıktan sonra, bir güvenlik araştırmacısı bu test kimlik bilgilerini keşfetti. Bu bilgiler, uygulamanın dahili test API'lerine erişim sağlayarak, teorik olarak sistemde zafiyet oluşturabilecek bir potansiyel barındırıyordu. Şirket, bu zafiyeti hızla yamalamak zorunda kaldı ve güvenlik protokollerini gözden geçirdi. Bu durum, "geliştirme sırlarının" bile potansiyel bir risk taşıdığını ve üretim ortamına asla sızmaması gerektiğini gösterdi.

• Vaka 3: Zayıf Cihaz İçi Depolama Uygulamaları ve Kullanıcı Verisi İhlali

  Bir sosyal medya uygulaması, kullanıcıların oturum token'larını ve bazı kişisel profil bilgilerini (örneğin kullanıcı adı, e-posta) cihazda yerel olarak kaydetmek için AsyncStorage kullanıyordu. Amaç, kullanıcı deneyimini iyileştirmek ve her seferinde tekrar giriş yapma zorunluluğunu ortadan kaldırmaktı. Ancak, cihazın dosya sistemine doğrudan erişimi olan kötü niyetli bir uygulama veya cihazı fiziksel olarak ele geçiren bir saldırgan, AsyncStorage veritabanına erişebildi. Token'lar ve profil bilgileri düz metin olarak depolandığı için, saldırgan bu bilgilere ulaşarak kullanıcının oturumunu devralabildi. Bu durum, kullanıcıların hesaplarının ele geçirilmesine, özel mesajların okunmasına ve kişisel verilerin çalınmasına yol açtı. Bu vaka, istemci tarafında depolanan her verinin, özellikle hassas verilerin, mümkün olan en yüksek güvenlik standartlarında korunması gerektiğinin bir göstergesiydi.

Bu senaryolar, OWASP M1'in sadece küçük bir kodlama hatasından ibaret olmadığını, aksine uygulamanın bütünlüğünü, kullanıcı verilerini ve şirket itibarını ciddi şekilde tehdit edebilecek sonuçlar doğurabileceğini açıkça ortaya koymaktadır. Bu nedenle, React Native/Expo geliştiricilerinin bu risklere karşı proaktif bir duruş sergilemesi ve en iyi güvenlik uygulamalarını benimsemesi kaçınılmazdır.

React Native/Expo Uygulamalarında OWASP M1 Nasıl Önlenir ve Mitige Edilir?

OWASP M1: "Improper Credential Usage" güvenlik açığını önlemek ve azaltmak için proaktif adımlar atmak, React Native ve Expo uygulamalarının güvenliği için hayati önem taşır. Bu bölümde, uygulamalarınızı bu tür risklere karşı korumak için uygulayabileceğiniz en iyi yöntemleri ve adım adım stratejileri ele alacağız. Başarılı bir mitigasyon, birden fazla güvenlik katmanının bir araya getirilmesini gerektirir.

Güvenli Kimlik Bilgisi Depolama Yöntemleri Nelerdir?

Hassas kimlik bilgilerini istemci tarafında saklamaktan kaçınmak idealdir, ancak bazı durumlarda bu kaçınılmaz olabilir (örneğin oturum token'ları). Bu durumda, verileri güvensiz depolama mekanizmalarında tutmak yerine, platformun sunduğu güvenli depolama çözümlerini kullanmalısınız:

• iOS Keychain ve Android Keystore: Bunlar, işletim sistemlerinin hassas verileri güvenli bir şekilde saklamak için tasarlanmış, donanım destekli ve şifreli depolama alanlarıdır.
  • react-native-keychain: React Native uygulamaları için bu yerel depolama mekanizmalarına erişim sağlayan popüler bir kütüphanedir. Bu kütüphane, API anahtarları, şifreler veya oturum token'ları gibi hassas bilgileri güvenli bir şekilde depolamanıza ve almanıza olanak tanır.
  • expo-secure-store: Expo projeleri için benzer bir işlevsellik sunar. Veriler iOS'ta Keychain, Android'de ise Keystore veya uygun şifreleme mekanizmaları kullanılarak depolanır. Bu, özellikle Expo Go veya yönetilen iş akışı kullanıyorsanız kritik bir araçtır.

    
                            // Doğru kullanım: expo-secure-store ile güvenli depolama
                            import * as SecureStore from 'expo-secure-store';
    
                            async function saveSecret(key, value) {
                                // Cihazın SecureStore'u destekleyip desteklemediğini kontrol edin
                                let isAvailable = await SecureStore.isAvailableAsync();
                                if (isAvailable) {
                                    await SecureStore.setItemAsync(key, value);
                                    console.log('${key}' başarıyla güvenli bir şekilde depolandı.);
                                } else {
                                    console.warn("SecureStore cihazda mevcut değil. Güvenli depolama yapılamadı.");
                                    // Alternatif (ancak daha az güvenli) bir depolama stratejisi uygulayabilirsiniz.
                                    // VEYA kullanıcıyı bilgilendirip uygulamayı kullanamayacağını belirtebilirsiniz.
                                }
                            }
    
                            async function getSecret(key) {
                                let isAvailable = await SecureStore.isAvailableAsync();
                                if (isAvailable) {
                                    const result = await SecureStore.getItemAsync(key);
                                    if (result) {
                                        console.log('${key}' için depolanan değer: ${result});
                                        return result;
                                    } else {
                                        console.log('${key}' için depolanmış bir değer bulunamadı.);
                                        return null;
                                    }
                                } else {
                                    console.warn("SecureStore cihazda mevcut değil. Güvenli depolama yapılamadı.");
                                    return null;
                                }
                            }
    
                            // Örnek kullanım:
                            // saveSecret('api_token', 'your_secure_jwt_token_here');
                            // const token = await getSecret('api_token');
                            // if (token) {
                            //     console.log('Alınan token:', token);
                            // }
                        

• Çevre Değişkenlerinin Doğru Kullanımı: Geliştirme sırasında hassas verileri yönetmek için çevre değişkenleri idealdir. Ancak, üretim sürümüne bu değişkenlerin nasıl dahil edildiğine dikkat etmelisiniz. API anahtarlarınızı doğrudan uygulama bundle'ına dahil etmek yerine, build sürecinde sunucudan çekilmesini veya sadece çok spesifik, kamuya açık anahtarları kullanmayı düşünün. Asla gizli anahtarları client-side kodunuzda barındırmayın.

Sunucu Tarafında Kimlik Doğrulama ve Yetkilendirme Nasıl Yapılır?

Mümkün olan her durumda, hassas bilgileri istemci tarafında tutmaktan kaçının. Bunun yerine, kimlik doğrulama ve yetkilendirme süreçlerini sunucu tarafında yönetin:

• OAuth2 ve JWT (JSON Web Tokens): Bu standartlar, kullanıcı kimlik bilgilerini doğrudan uygulamada saklamadan güvenli bir şekilde yetkilendirme sağlamak için kullanılır. Kullanıcı, sunucu tarafında kimlik doğrulaması yapar ve uygulama, bu doğrulama sonucunda aldığı bir JWT ile yetkili isteklere devam eder. JWT'nin kendisi de hassas olmadığı, ancak imza doğrulamasını içeren güvenli bir token olduğu için istemcide güvenle saklanabilir (expo-secure-store gibi yerlerde).
• Merkezi Kimlik Yönetimi: Okta, Auth0 veya Firebase Authentication gibi hizmetler, kimlik doğrulama sürecini sizin adınıza yönetir. Bu, geliştiricinin hassas kullanıcı şifrelerini veya diğer kimlik bilgilerini kendi sunucularında veya uygulamasında işlemek zorunda kalmamasını sağlar.
• Hassas Verilerin İstemcide Tutulmaması Prensibi: Kullanıcı şifreleri, özel kriptografik anahtarlar veya gizli API anahtarları gibi veriler asla mobil uygulamada tutulmamalıdır. Uygulama, bu verilere ihtiyacı olduğunda sunucu aracılığıyla güvenli bir API çağrısı yapmalı ve sunucu bu işlemleri kendi güvenli ortamında gerçekleştirmelidir.

Uygulama İçi Gizli Bilgilerin Yönetimi İçin En İyi Uygulamalar Nelerdir?

• Derleme Zamanı Yapılandırması: Farklı ortamlar (geliştirme, test, üretim) için farklı yapılandırma dosyaları veya çevre değişkenleri kullanın. Üretim build'lerinde hata ayıklama bilgilerinin ve test kimlik bilgilerinin olmadığından emin olun.
• Kod Karartma (Obfuscation) ve Küçültme (Minification): React Native uygulamanızın JavaScript kodunu karartmak ve küçültmek, tersine mühendisliği zorlaştırabilir. Bu, bir saldırganın kodu anlamasını ve hassas bilgileri bulmasını daha zahmetli hale getirir. ProGuard (Android için) veya diğer JavaScript obfuscation araçları kullanılabilir. Ancak, obfuscation bir güvenlik çözümü değil, sadece ek bir savunma katmanıdır.
• Runtime Application Self-Protection (RASP) Kavramı: RASP araçları, uygulamanın çalışma zamanında saldırıları tespit edip engelleyerek ek bir güvenlik katmanı sağlar. Bu, özellikle uygulamanın değiştirilmesini (tampering) veya tersine mühendislik girişimlerini tespit etmekte faydalı olabilir. React Native için ticari RASP çözümleri mevcuttur.
• Sertifika Sabitleme (Certificate Pinning): HTTPS bağlantılarının Man-in-the-middle saldırılarına karşı daha dirençli hale getirilmesi için kullanılır. Uygulama, bağlantı kuracağı sunucunun sertifikasını veya genel anahtarını önceden bilir ve yalnızca bu sabitlenmiş sertifika ile eşleşen bağlantılara güvenir. Bu, hatalı veya sahte sertifikalarla yapılan saldırıları engeller.

Bu mitigasyon stratejilerini bir arada uygulamak, React Native ve Expo uygulamalarınızın OWASP M1'e karşı direncini önemli ölçüde artıracaktır. Güvenlik, tek seferlik bir işlem değil, sürekli bir süreçtir ve geliştirme yaşam döngüsünün her aşamasında düşünülmelidir.

Mobil Güvenlikte İleri Düzey Taktikler ve Sürekli İyileştirme

Mobil uygulama güvenliği, sadece temel önlemleri almakla bitmez; sürekli gelişen tehdit ortamına karşı adaptasyon ve iyileştirme gerektiren dinamik bir alandır. Özellikle OWASP M1 gibi yaygın zafiyetlere karşı güçlü bir savunma oluşturmak, ileri düzey taktikleri ve sürekli güvenlik pratiklerini uygulamayı zorunlu kılar. Bu bölümde, React Native/Expo uygulamalarınızın güvenliğini bir sonraki seviyeye taşıyacak ipuçlarını ve sürdürülebilir güvenlik yaklaşımlarını inceleyeceğiz.

Uygulamanızın Güvenliğini Nasıl Test Edebilirsiniz?

Hiçbir uygulama, titiz güvenlik testlerinden geçirilmeden gerçekten güvenli sayılamaz. Düzenli ve kapsamlı testler, olası zafiyetleri erkenden tespit etmenin ve düzeltmenin en etkili yoludur:

• Statik Kod Analizi (SAST - Static Application Security Testing): SAST araçları, uygulamanın kaynak kodunu veya derlenmiş halini çalıştıra çalıştırmadan analiz eder. Hardcoding, güvensiz API kullanımı veya diğer OWASP M1 ihlalleri gibi kod tabanındaki potansiyel güvenlik açıklarını otomatik olarak tespit edebilirler. React Native için ESLint eklentileri veya SonarQube gibi platformlar bu amaçla kullanılabilir.
• Dinamik Uygulama Güvenlik Testi (DAST - Dynamic Application Security Testing): DAST araçları, çalışan uygulamayı gerçek zamanlı olarak test eder. Uygulamaya dışarıdan saldırılar simüle ederek, çalışma zamanı zafiyetlerini (örneğin, kimlik doğrulama bypass'ları veya oturum yönetimi sorunları) ortaya çıkarır.
• Mobil Penetrasyon Testleri: Güvenlik uzmanları tarafından manuel olarak gerçekleştirilen bu testler, uygulamanın, API'lerinin ve arka uç sistemlerinin derinlemesine incelenmesini içerir. Bir saldırganın bakış açısından hareket ederek, zafiyetleri tespit etmeye ve sistemlere sızmaya çalışırlar. OWASP M1 gibi zafiyetler genellikle penetrasyon testleri sırasında ortaya çıkar.
• Manuel Kod İncelemeleri: Özellikle hassas modüller veya yeni eklenen özellikler için manuel kod incelemeleri, otomatik araçların gözünden kaçabilecek ince mantık hatalarını veya güvenlik zafiyetlerini tespit etmede kritik rol oynar.
• Bağımlılık Güvenliği Taraması: React Native projeleri çok sayıda üçüncü taraf kütüphane ve bağımlılık kullanır. Bu bağımlılıkların bilinen güvenlik açıklarını (CVE'ler) taramak için npm audit veya Snyk gibi araçlar kullanılmalıdır. Eski veya güvenlik açığı bulunan bir kütüphane, uygulamanızın genel güvenliğini tehlikeye atabilir.

Ayrıca, geliştirme ve dağıtım süreçlerinize güvenlik entegrasyonu (DevSecOps) sağlamak, güvenlik açıklarının erken aşamada tespit edilip giderilmesini kolaylaştırır. CI/CD (Sürekli Entegrasyon/Sürekli Dağıtım) boru hattınıza otomatik güvenlik testlerini ve taramalarını dahil etmek, güvenliği bir "sonradan ekleme" olmaktan çıkarıp, sürecin doğal bir parçası haline getirir.

Mobil Uyumluluk ve Responsive Tasarım için HTML ve CSS İpuçları: Makale içeriğinde mobil uyumluluk vurgusu yaparken, kullanılan HTML ve CSS'in kendisinin de responsive olması önemlidir. Aşağıdaki CSS kodu, makale içeriğinin farklı ekran boyutlarına uyum sağlaması için temel bir yapı sunar. Bu, içerik tüketimi açısından mobil kullanıcı deneyimini artırır ve SEO sıralamalarını olumlu etkiler.

        /* Mobile-first tasarım yaklaşımı için temel ayarlar */
        body {
            font-family: 'Segoe UI', Tahoma, Geneva, Verdana, sans-serif;
            line-height: 1.6;
            color: #333;
            margin: 0;
            padding: 15px; /* Küçük ekranlarda kenar boşluğu */
            box-sizing: border-box;
        }

        h2, h3 {
            color: #2c3e50;
            margin-top: 1.5em;
            margin-bottom: 0.8em;
        }

        p {
            margin-bottom: 1em;
        }

        .expert-tip {
            background-color: #fff3cd;
            border-left: 5px solid #ffc107;
            padding: 15px;
            margin: 20px 0;
            color: #856404;
            border-radius: 4px;
        }

        pre {
            background-color: #f8f8f8;
            border: 1px solid #ddd;
            padding: 10px;
            border-radius: 4px;
            overflow-x: auto;
            white-space: pre-wrap; /* Uzun kod satırlarını sarar */
            word-wrap: break-word; /* Kelimeleri böler */
        }

        code {
            font-family: 'Consolas', 'Monaco', monospace;
            font-size: 0.9em;
        }

        /* Küçük ekranlar (mobil cihazlar) için özelleştirmeler */
        @media only screen and (max-width: 768px) {
            body {
                padding: 10px;
                font-size: 15px;
            }
            h2 {
                font-size: 22px;
            }
            h3 {
                font-size: 18px;
            }
            .expert-tip {
                padding: 10px;
                font-size: 14px;
            }
        }

        /* Orta ekranlar (tabletler) için özelleştirmeler */
        @media only screen and (min-width: 769px) and (max-width: 1024px) {
            body {
                padding: 20px;
                font-size: 16px;
            }
            h2 {
                font-size: 26px;
            }
            h3 {
                font-size: 20px;
            }
        }

        /* Büyük ekranlar (masaüstü) için özelleştirmeler */
        @media only screen and (min-width: 1025px) {
            body {
                max-width: 900px;
                margin: 0 auto;
                padding: 25px;
                font-size: 17px;
            }
            h2 {
                font-size: 28px;
            }
            h3 {
                font-size: 22px;
            }
        }
    

Sonuç ve Sıkça Sorulan Sorular

React Native ve Expo ile modern mobil uygulamalar geliştirmek, şüphesiz birçok avantaj sunar. Ancak, bu avantajların beraberinde getirdiği güvenlik sorumluluklarını da göz ardı etmemek gerekir. OWASP M1 (2024) Improper Credential Usage, kimlik bilgilerinin yanlış kullanımından kaynaklanan ciddi riskleri vurgulayan kritik bir güvenlik açığıdır. Bu makale boyunca, bu zafiyetin temel kavramlarını, React Native/Expo ortamındaki tezahürlerini, gerçek dünya senaryolarını ve en önemlisi, uygulamalarınızı bu tehdide karşı nasıl güçlendirebileceğinizi detaylıca inceledik. Güvenli depolama mekanizmalarını kullanmaktan, sunucu tarafı kimlik doğrulamasına ve ileri düzey güvenlik testlerine kadar birçok katmanlı yaklaşımın, mobil uygulama güvenliğinizin temelini oluşturduğunu gördük.

Unutmayın, güvenlik bir varış noktası değil, sürekli bir yolculuktur. Uygulama geliştirme süreçlerinizin her aşamasında güvenliği bir öncelik olarak benimsemek, düzenli denetimler yapmak ve güncel tehditler hakkında bilgi sahibi olmak, kullanıcılarınızın verilerini korumanın ve markanızın itibarını sürdürmenin anahtarıdır. Bu rehberdeki prensipleri uygulayarak, React Native/Expo uygulamalarınızda OWASP M1 riskini önemli ölçüde azaltabilir ve daha güvenli bir mobil ekosistem inşa edebilirsiniz.

Sıkça Sorulan Sorular (SSS)

1. Soru: OWASP M1 sadece API anahtarları için mi geçerlidir?

   Cevap: Hayır, OWASP M1 "Improper Credential Usage" genel olarak her türlü kimlik bilgisi için geçerlidir. Buna kullanıcı adları, şifreler, API anahtarları, sertifikalar, oturum token'ları ve diğer hassas veriler dahildir. Sorun, bu bilgilerin yanlış depolanması, işlenmesi veya iletilmesinden kaynaklanır. Saldırganın bu bilgilere erişimi, uygulamanın yetkili işlevlerini kötüye kullanmasına olanak tanır.

2. Soru: Expo kullanmak React Native uygulamamı otomatik olarak daha güvenli hale getirir mi?

   Cevap: Expo, geliştirme sürecini basitleştirir ve bazı güvenlik standartlarını uygulamanıza yardımcı olabilir, ancak doğrudan OWASP M1 gibi güvenlik açıklarını otomatik olarak kapatmaz. Örneğin, expo-secure-store gibi modüller güvenli depolama için araçlar sunsa da, bu araçları doğru şekilde kullanmak geliştiricinin sorumluluğundadır. Expo'nun managed workflow'unda bazı yerel kod erişimi kısıtlamaları bulunsa da, genel uygulama mantığı ve hassas veri yönetimi geliştiricinin kontrolündedir. Geliştirme sürecinde güvenlik bilinci ve en iyi uygulamaların titizlikle takibi esastır.

3. Soru: Uygulamamdaki tüm hassas bilgileri sunucu tarafında mı tutmalıyım?

   Cevap: Mümkün olduğunca evet. Kullanıcı kimlik bilgileri (şifreler), özel API anahtarları ve diğer çok hassas veriler istemci tarafında tutulmamalı, bunun yerine sunucu tarafında güvenli bir şekilde saklanmalı ve erişim gerektiğinde güvenli API çağrıları aracılığıyla doğrulanmalıdır. İstemci tarafında yalnızca oturum token'ları gibi geçici ve sınırlı yetkiye sahip bilgiler tutulabilir, o da güvenli depolama mekanizmalarıyla (Keychain/Keystore) şifrelenmiş olarak. Temel prensip, istemcide sadece kesinlikle gerekli olanı tutmaktır.

4. Soru: Mobil uygulamalarda kod obfuscation gerçekten işe yarıyor mu?

   Cevap: Kod obfuscation (kod karartma), tersine mühendisliği zorlaştıran bir savunma katmanıdır, ancak tek başına bir güvenlik çözümü değildir. Kodu tamamen kırılamaz hale getirmez, ancak bir saldırganın kodu anlamasını ve hassas bilgileri bulmasını daha zahmetli ve zaman alıcı hale getirir. Bu nedenle, obfuscation, diğer güçlü güvenlik önlemleri (güvenli depolama, sunucu tarafı doğrulama, sertifika sabitleme vb.) ile birlikte kapsamlı bir güvenlik stratejisinin bir parçası olarak kullanılmalıdır. Tek başına bir çözüm olarak güvenilmemelidir.

5. Soru: React Native uygulamam için sertifika sabitleme nasıl yapabilirim?

   Cevap: React Native uygulamalarında sertifika sabitleme (Certificate Pinning) için genellikle üçüncü taraf kütüphaneler kullanılır. Örneğin, iOS için react-native-keychain gibi kütüphaneler veya react-native-ssl-public-key-pinning gibi sadece sabitleme üzerine odaklanan kütüphaneler mevcuttur. Bu kütüphaneler, uygulamanın belirli sunucuların sertifikalarını veya açık anahtarlarını önceden bilmesini ve yalnızca bu önceden tanımlanmış sertifikalarla eşleşen bağlantılara güvenmesini sağlar. Bu, Man-in-the-Middle (MitM) saldırılarına karşı önemli bir koruma katmanı ekler. Her iki platform (iOS ve Android) için de yerel modüller gerektirebileceğinden, Expo'nun yönetilen iş akışında bu tür derinlemesine yerel modül entegrasyonları için bazen Expo Development Client (EAS Build) kullanmanız gerekebilir.