Expo uygulamasında gizli API anahtarı: neyi korumalısın?

Bir ortam değişkeni her zaman bir sır değildir

Bir Expo uygulamasında EXPO_PUBLIC_ önekiyle başlayan bir değişken, uygulamanın kodu için tasarlanmıştır. İçinde sunucuya ait bir sır olmamalı. Expo, bu değerlerin derlenmiş JavaScript'e gömüldüğünü ve uygulamanın kullanıcıları tarafından okunabileceğini açıklıyor. Yani bir anahtarı .env dosyasına taşımak onu korumaya yetmez. Kaynak: Expo ortam değişkenleri.

Bir yapay zekâdan "API'yi bağlamasını" istemeden önce ona verdiğin şeyi sınıflandır: bir servis adresi mi, herkese açık olması planlanmış bir anahtar mı, yoksa ayrıcalıklı işlemlere izin veren bir anahtar mı? Bu sınıflandırma, kodun nerede çalışması gerektiğini belirler.

Aşağıdaki tablo bir tasarım çerçevesi, uygulamanın denetimi değil.

Öğe	Nereye koymalı	Yapılacak kontrol
Backend'in herkese açık adresi	Uygulama yapılandırması	Doğru ortamı gösteriyor.
Supabase publishable anahtarı ya da eski anon anahtarı	Yetkiler doğru yapılandırıldıysa uygulamada	Veri kuralları başka bir kullanıcının hesabına erişimi gerçekten engelliyor.
Supabase secret ya da service_role anahtarı	Yalnızca sunucuda	Ne mobil bundle'da ne de istemcinin erişebildiği loglarda görünüyor.
Bir yapay zekâ sağlayıcısının gizli anahtarı	Yalnızca sunucuda	Uygulama senin sunucunu çağırır; sunucu, sağlayıcıya gitmeden önce kullanıcıyı ve limitleri kontrol eder.

Supabase, istemciler için tasarlanmış anahtarları güvenilir ortamlar için olan gizli anahtarlardan ayırıyor. Herkese açık bir anahtar projeyi tanımlar; veriler üzerindeki izinlerin yerini tutmaz. Kaynak: Supabase API anahtarları.

Örnek: hayali bir okuma günlüğü uygulaması

Lea ve Sami'nin kitaplarını ve özel notlarını kaydettiği bir uygulama düşünelim. Bu örnek testleri hazırlamak için; bir Devoria uygulamasında elde edilmiş sonuçları anlatmıyor.

Normal akış doğru görünüyor: Lea giriş yapıyor ve kendi notlarını görüyor. Ama bu, asıl önemli soruyu henüz cevaplamıyor: Lea'nın Sami'ye ait bir notu hedefleyen isteğini sunucu reddediyor mu?

Arayüzdeki "giriş yapmış kullanıcının notlarını göster" gibi bir filtre görüntülemeyi iyileştirir. Yetkilendirmenin veri tarafında da uygulanması gerekir. Supabase'de Row Level Security kuralları, oturuma göre erişilebilen satırları kısıtlamanı sağlar. Supabase, API üzerinden açılan tablolarda bunların etkinleştirilmesini öneriyor ve okuma ile yazma politikalarını açıklıyor. Kaynak: Row Level Security.

Kendi test projende her notu sahibine bağla ve onu kimin okuyabileceğini, oluşturabileceğini, değiştirebileceğini ve silebileceğini ayrı ayrı tanımla. Dosyaları da kontrol et: bir veritabanı satırını korumak, bir görselin özel olduğunu kanıtlamaz.

İki test hesabıyla uygulanacak test senaryosu

Kontrol ettiğin iki hesap hazırla, her birinde farklı bir kitap ve tanınabilir küçük bir not olsun. İzin verilen bir test ortamında hayali veriler kullan.

1. Kendi notunu oku. A hesabı A notunu bulur.
2. A'dan B'nin notunu oku. İstek, notun özel içeriğini açığa çıkarmaz.
3. A'dan B'nin notunu değiştir. Sunucu reddeder; B notu değişmeden kalır.
4. A'dan B adına oluştur. Sunucu bu atamayı reddeder.
5. Oturum olmadan oku. Hiçbir özel içerik dönmez.
6. A'dan B'nin özel dosyasını aç. Dosyaya erişilemez.

Gerçek sonucu, test edilen sürümü ve varsa hatayı kaydet. "Kurallar etkin" bir test sonucu değildir. Bu kanıtları saklamak için kaynaklar bölümündeki test tablosunu temel olarak kullanabilirsin.

Ücretli bir çağrıyı sunucun üzerinden geçir

Bir kitabı bir yapay zekâ API'siyle özetleyen bir özellik için akış şöyle olabilir: uygulama → senin sunucun → sağlayıcı → senin sunucun → uygulama. Gizli anahtar sunucuda kalır. Bu mimari tek başına yetmez: sunucuya erişimin de kontrol edilmesi gerekir.

Hayali örnekte sunucu özellikle şunları yapmalı: oturumu doğrulamak, kitabın o kişiye ait olduğunu kontrol etmek, tekrarlanan istekleri sınırlamak ve sağlayıcı yanıt vermezse anlaşılır bir hata döndürmek. Bir kullanıcının ücretli erişime sahip olduğuna istemci kendi başına karar vermez.

Dört deneme hazırla: giriş yapmamış kullanıcı, başka bir hesabın kitabı, limite ulaşılmış durum ve erişilemeyen sağlayıcı. Sonuncusu, uygulamanın girilen veriyi kaybetmeden yükleme durumundan çıktığını doğrulamanı sağlar.

Kod asistanından neler isteyebilirsin

İşte kendi deposuna uyarlayabileceğin bir inceleme talimatı. Gizli değerlerini içine yapıştırma:

Mobil kodun ve sunucunun kullandığı değişkenleri yalnızca adlarını göstererek listele. İstemci tarafındaki ayrıcalıklı çağrıları belirle. Özel veriler için okuma ve yazma kontrollerini açıkla, ardından iki test hesabıyla bir test senaryosu öner. Onay olmadan hiçbir anahtar rotasyonu ya da production değişikliği yapma.

Yanıtı ilgili kodla birlikte oku. Bir asistan bir tutarsızlığı fark edebilir; ama yanıtı testleri çalıştırmanın yerini tutmaz. Claude Code ile uygulama geliştirme rehberi bu işi nasıl parçalara böleceğini anlatıyor.

Uygulamana devam etmeden önce

Üç şeyi basitçe açıklayabilmelisin: hangi değerler herkese açık, hangi işlemler sunucudan geçiyor ve hangi testler bir hesabın başka bir hesabın verilerini görmediğini gösteriyor. Bu noktalardan biri belirsizse, yeni özellik eklemeden önce netleştir.

iPhone uygulaması geliştirme sayfası bu adımı projenin bütünü içinde konumlandırıyor. Sırayla ilerlemek için iOS Kit dört adımlı bir yol ve hesapları ile yapay zekâyı zaten içeren bir başlangıç kodu sunuyor. Hangi adımdan devam edeceğini bilmiyorsan, ücretsiz teşhis projeni sıraya koyar ve sana Apple retlerine karşı kontrol listemi gönderir.

Sık sorulan sorular

Expo uygulamasında gizli API anahtarı nereye konur?

Sunucuna, asla uygulamaya değil. Supabase secret ya da service_role anahtarı, tıpkı bir yapay zekâ sağlayıcısının gizli anahtarı gibi, yalnızca sunucu tarafında kalmalı. Uygulama senin sunucunu çağırır; sunucu, sağlayıcıyı çağırmadan önce kullanıcıyı ve limitleri kontrol eder. Bu anahtarların hiçbirinin mobil bundle'da ya da istemcinin erişebildiği loglarda görünmediğini kontrol et.

Bir .env dosyası Expo'da API anahtarımı korur mu?

Tek başına korumaz. EXPO_PUBLIC_ önekiyle başlayan bir değişken uygulamanın kodu için tasarlanmıştır ve sunucuya ait bir sır içermemelidir. Expo, bu değerlerin derlenmiş JavaScript'e gömüldüğünü ve uygulamanın kullanıcıları tarafından okunabileceğini açıklıyor. Yani bir anahtarı .env dosyasına taşımak onu korumaya yetmez.

Herkese açık API anahtarı ile gizli anahtar arasındaki fark ne?

Herkese açık anahtar uygulamayla birlikte dağıtılmak için tasarlanmıştır: projeyi tanımlar ama veriler üzerindeki izinlerin yerini tutmaz. Gizli anahtar ayrıcalıklı işlemlere izin verir ve yalnızca güvenilir ortamlarda kalır. Supabase'de publishable anahtarı ya da eski anon anahtarı, yetkiler doğru yapılandırıldıysa uygulamada kalabilir. Secret ve service_role anahtarları sunucuda kalır.

Expo uygulamasından bir yapay zekâ API'sini anahtarı açığa çıkarmadan nasıl çağırırım?

Çağrıyı sunucun üzerinden geçir: uygulama sunucuyu çağırır, sunucu sağlayıcıyı çağırır ve yanıtı uygulamaya geri gönderir. Gizli anahtar sunucuda kalır. Sunucu ayrıca oturumu doğrulamalı, tekrarlanan istekleri sınırlamalı ve sağlayıcı yanıt vermezse anlaşılır bir hata döndürmeli. Bir kullanıcının ücretli erişime sahip olduğuna istemci kendi başına karar vermez.

Her kullanıcının yalnızca kendi verilerini gördüğünü nasıl doğrularım?

Kontrol ettiğin iki test hesabı hazırla, her birinde tanınabilir bir not olsun. A hesabından B hesabının notunu okumayı, değiştirmeyi ve B adına oluşturmayı dene, ardından B'nin özel dosyasını açmayı dene. Denemeleri oturum olmadan da yap: her istek reddedilmeli ya da hiçbir şey açığa çıkarmamalı. Gerçek sonucu kaydet, çünkü "kurallar etkin" bir test sonucu değildir.

Bir yapay zekâdan uygulamamın anahtarlarını kontrol etmesini nasıl isterim?

Mobil kodun ve sunucunun değişkenlerini yalnızca adlarını göstererek listelemesini iste; gizli değerlerini yapıştırma. İstemci tarafındaki ayrıcalıklı çağrıları belirlemesini ve iki test hesabıyla bir test senaryosu önermesini de iste. Onay olmadan her türlü anahtar rotasyonunu ya da production değişikliğini yasakla. Yanıtı testleri çalıştırmanın yerini tutmaz.