Bir exchange API key, API Key ve API Secret çiftinden oluşur. Bu key ile programlar ve servisler API üzerinden hesapla çalışır: bakiyeyi okur, trade açıp kapatır ve bu key için izin verilen diğer işlemleri web paneline giriş yapmadan yürütür.
Materyalin amacı: bir exchange’in API isteklerine uyguladığı kısıtlamaları açıklamak: API Secret ile imza doğrulaması, key hakları (permissions), istek kaynağının IP whitelist’e bağlanması, adres whitelist üzerinden çekim kısıtları ve bakiyenin sub-accounts ile izole edilmesi. Bu kısıtlamalar, API Key + API Secret çiftinin leak olması durumunda varlık çekimi veya zarar eden trade’lere yol açma riskini azaltır.
🧭 Kripto exchange’lerde API erişim kontrolü nasıl çalışır
API keys trading botlar, terminaller, raporlama servisleri ve iç entegrasyonlar tarafından kullanılır. Bir exchange, API isteğini yalnızca imzayı (API Secret), işlem haklarını (permissions), kaynak IP adresini (IP whitelist) ve istek zamanını (timestamp ve recvWindow) kontrol ettikten sonra yürütür. Zaman kontrolü, istek ele geçirilmiş olsa bile isteğin daha sonra tekrar edilmesini engeller.
API riski key ayarlarıyla azaltılır. IP whitelist yalnızca belirtilen IP adreslerinden gelen istekleri kabul eder. Permissions, exchange’in key ile yürüteceği işlem kümesini sınırlar. Çekim adresi whitelist’i alıcı listesini sınırlar. Sub-accounts, bakiye ve keys’i sub-accounts arasında ayırarak tek bir key’in hesaptaki tüm varlıklara erişmesini engeller.
🔍 Exchange API isteğini nasıl doğrular: imza, haklar, IP ve zaman
API key, API Key’den (key tanımlayıcısı) ve API Secret’tan (imza için secret) oluşur. İmza, isteğin API Secret kullanılarak oluşturulduğunu ve iletim sırasında değiştirilmediğini exchange’e doğrular.
- Exchange API endpoint’i için istek parametrelerinin oluşturulması (belirli bir işlemi kabul eden API adresi)
- İstek işlemi tanımlar: emir açmak veya iptal etmek, bakiye almak, transfer yapmak ya da para çekimini başlatmak.
- İstek bir zaman damgası (timestamp) ve bazen izin verilen zaman penceresi (recvWindow) içerir. Exchange bu değerleri kendi zamanı ile karşılaştırır ve istek izin verilen aralığın dışına çıkarsa isteği reddeder.
- İstek parametrelerinin HMAC ile imzalanması
- HMAC, secret key ile oluşturulan hash tabanlı bir imzadır. Parametre dizesi API Secret ile imzalanır.
- Exchange aynı parametrelerle HMAC’i yeniden hesaplar ve imzayı karşılaştırır. Eşleşmeme, gönderenin API Secret’a sahip olmadığını veya parametrelerin değiştirildiğini gösterir.
- Key kısıtlarının kontrolü ve yürütme kararı
- Permissions, key için hangi işlemlerin izinli olduğunu belirler (çoğu merkezi exchange’de, CEX, read/trade/transfer/withdraw).
- IP whitelist istek kaynaklarını sınırlar. Exchange, gönderen IP key’in whitelist’inde değilse isteği reddeder.
- İşlemin yürütülmesi ve sonucun döndürülmesi
- Haklar yetersizse exchange ret döndürür ve imza doğru olsa bile işlemi yürütmez.
- IP eşleşmiyorsa exchange yetkilendirme aşamasında ret döndürür ve trading veya çekim işlemine geçmez.
Exchange tarafından kontrol edilen API erişim bileşenleri
Exchange, her istekte üç kontrolle API riskini azaltır: API Secret üzerinden imza, işlemler için permissions ve istek kaynağı için IP whitelist.
- API Secret yalnızca secrets kasasında ve istekleri imzalayan sürecin belleğinde saklanır.
- Permissions key’in görevine göre etkinleştirilir: raporlama için okuma, bot için trading, yalnızca operasyonel ödemeler için çekim.
- IP whitelist yalnızca gerçekten istek gönderen sunucuların IP’lerini içerir, böylece liste saldırı yüzeyini genişletmez.
Bir saldırgan API Secret olmadan API Key elde ederse exchange isteği geçersiz imza nedeniyle reddeder. Bir saldırgan hem API Key hem API Secret elde ederse exchange, permissions işlemi izinli kılmadığında veya IP whitelist’te yer almadığında isteği reddeder.
🎯 API üzerinden hangi kayıplar mümkündür: çekim, transferler ve trading zararı
API üzerinden oluşan zarar, etkin permissions’a ve bu key’in erişebildiği bakiyeye bağlıdır. Trade-only key, küçük çalışma bakiyesi olan bir sub-account üzerinde daha düşük risk taşır; ana sermayenin bulunduğu bir sub-account üzerinde ise daha yüksek risk taşır.
Exchange’in API üzerinden yürüttüğü üç senaryo
API kayıpları çekim, dahili transfer veya yürütme fiyatında zarar oluşturan trade’ler yoluyla ortaya çıkar.
- Doğrudan çekim: withdraw permission olan bir key, exchange’in kontrolleri ve whitelist kuralları sonrası izin vereceği bir adrese çekim başlatır.
- Dahili transfer: transfer permission olan bir key, exchange bu işlemlere API üzerinden izin veriyorsa varlıkları ürün wallet’ları arasında veya sub-accounts arasında taşır.
- Çekimsiz trading zararı: trade permission olan bir key, düşük likiditeli bir paritede emirler verir ve daha kötü fiyattan trade’ler yürütür; bu da slippage, spread ve komisyonlardan kaynaklanan zarar oluşturur.
Devre dışı withdraw permission doğrudan çekimi ortadan kaldırır. Trading wallet’ta büyük bakiye tutuluyorsa ve key IP ile enstrümanlar bakımından kısıtlı değilse trade permission zarar kaynağı olmaya devam eder.
API kontrolünü gerekli hâle getiren sinyaller
- Trading system mantığına ve başlatma takvimine uymayan emirler ortaya çıktı.
- Operasyonel neden olmadan wallet’lar veya sub-accounts arasında transferler ortaya çıktı.
- Key ayarlarında yeni permissions belirdi veya IP whitelist kaldırıldı.
- Trading system loglarında imza hataları ortaya çıktı ve kod değişmeden istek sıklığı arttı.
🌐 IP whitelist: key’in istek kaynağı sunucuya bağlanması
IP whitelist exchange’i yalnızca önceden belirtilen IP adreslerinden gelen istekleri kabul etmeye zorlar. API Secret koda, loglara, yedeklere veya üçüncü taraf servise girerse saldırgan whitelist’te olmayan bir IP’den istek gönderemez.
API istekleri için stabil kaynak seçimi
- Sabit public IP’ye sahip bir VPS (sanal özel sunucu), IP whitelist ve trading system’in kesintisiz çalışması için uygundur.
- Dinamik IP’li ev interneti uygun değildir, çünkü IP değişimi whitelist güncellenene kadar API isteklerinde retlere neden olur.
API key için IP whitelist yapılandırması
- IP whitelist, trading system sunucusunun IP’sini ve yedek sunucu gerçekten kullanılıyorsa yedek sunucunun IP’sini içerir.
- Exchange CIDR’ı destekliyorsa (örneğin 203.0.113.10/32 gibi alt ağ gösterimi), kaynak listesini genişletmemek için en küçük aralık belirlenir.
API erişiminin dayanıklılığının kontrolü
- Ayrı IP üzerinde yedek API key, altyapı migrasyonu ve sunucu adresi değişimi sırasında kullanılır.
- IP whitelist güncelleme prosedürü önceden sabitlenir, böylece IP değişimi emir kontrolü kaybıyla çakışmaz.
Cloud altyapısında istekler internete NAT üzerinden çıkabilir (ağın sınırında adres dönüştürme). Bu durumda exchange’in gördüğü dış IP, container veya sanal makine IP’sinden farklı olabilir. IP whitelist’e egress IP (giden trafiğin dış IP’si) yazılır; aksi hâlde exchange istekleri reddeder.
IP whitelist VPS kompromisini engellemez. Sunucu ele geçirilirse saldırgan aynı IP’den istek gönderir, bu yüzden VPS erişim koruması ve güncelleme kontrolü API korumasının parçası olmaya devam eder.
IP whitelist yabancı sunuculardan gelen istekleri bloke eder, çünkü exchange kaynak IP’yi whitelist ile karşılaştırır ve trading veya çekim işlemini yürütmeden önce isteği reddeder.
🔑 Permissions: belirli bir görev için key’e hangi haklar verilir
Permissions, exchange’in bu key ile hangi API endpoint’lerinin çağrılmasına izin vereceğini belirler. Hak adları exchange’e bağlıdır, ancak şema genellikle aynıdır: okuma için read, emirler için trade, dahili transferler için transfer ve blockchain’e çekim için withdraw.
| Görev | İzin ver | Yasakla | Bloke edilen işlem |
|---|---|---|---|
| Screener/analitik | Read | Trade; Transfer; Withdraw | Emir verme ve varlık taşıma |
| Trading bot | Read; Trade | Withdraw | API üzerinden doğrudan fon çekimi |
| Raporlama | Read | Trade; Transfer; Withdraw | Raporlama servisi kompromisi durumunda işlemler |
| Operasyonel transferler | Read; Transfer | Trade; Withdraw | Trading işlemleri ve blockchain’e çekim |
Monitoring ve raporlama için read-only key
Read-only key, sistemin bakiyeleri, trade geçmişini ve pozisyon durumlarını okuması gerektiğinde, ancak hesap durumunu değiştirmemesi gerektiğinde kullanılır.
- Read-only key emir verme ve iptal etmeyi bloke eder, çünkü exchange bu key için trading endpoint’lerini reddeder.
- IP whitelist veri erişimini belirli bir sunucuyla sınırlar ve API Secret leak olduğunda yabancı IP’lerden gelen istekleri bloke eder.
- Raporlama için ayrı read-only key, raporlama servisi riskini trading key riskinden ayırır.
Read-only key bakiye ve geçmişi açığa çıkarır, ancak çekim ve trade’e izin vermez, çünkü exchange trade/transfer/withdraw endpoint’lerini reddeder.
Çekimsiz trading system için trade key
Trade key emir vermek ve emir iptal etmek için kullanılır. Trading işlemleri için withdraw permission gerekli değildir.
- Trade permission, hesap piyasaları kapsamında emir ve pozisyon yönetimine erişim verir.
- Devre dışı withdraw permission çekimleri bloke eder, çünkü exchange bu key için withdrawal endpoint’lerini reddeder.
- IP whitelist key’i trading system sunucusuna bağlar ve API Secret leak olduğunda yabancı makinelerden gelen istekleri bloke eder.
Trade-only key trading wallet’taki fonlar için risk oluşturur, bu yüzden trading sub-account genellikle ana sermayeyi değil çalışma bakiyesini tutar.
Dahili hareketler için transfer key
Transfer key exchange içindeki transferler için kullanılır: ürün wallet’ları arasında veya exchange API üzerinden izin veriyorsa sub-accounts arasında.
- Transfer permission blockchain’e çıkmayan dahili transferleri yürütmeye izin verir.
- Devre dışı trade permission trade’leri dışlar, çünkü transfer key emir oluşturamaz.
- Devre dışı withdraw permission, transfer key kompromisi durumunda blockchain’e çekimi dışlar.
Transfer ve trade’i farklı keys’e ayırmak, leak durumunda zararı azaltır; çünkü tek bir key aynı anda trade’lere ve varlık hareketine erişim vermez.
Permissions, exchange’in bu key ile hangi işleme izin vereceğini belirler. Fazla permissions, exchange’in kompromize key ile yürüteceği eylem setini genişletir; bu yüzden haklar yalnızca belirli süreç için etkinleştirilir.
🏷️ Çekim koruması: adres whitelist, onaylar ve limitler
Withdraw permission, API key’in exchange bakiyesinden blockchain’e fon çekimini başlatmasına izin verir. Çekim koruması alıcı adres whitelist’ine, whitelist değişiklik kontrolüne ve çekim limitlerine dayanır.
Trading entegrasyonlarında withdraw permission genellikle devre dışı bırakılır. Emirler, iptaller ve bakiye okuma exchange içinde yürütülür ve ağa çekim gerektirmez. Monitoring ve raporlama için read hakkı yeterlidir. Algoritmik trading için trade hakkı yeterlidir.
Örnek: bir trading bot, trade permission olan ve withdraw permission olmayan bir key ile çalışır. Key kompromize olduğunda saldırgan trading endpoint’leri üzerinden trade açıp kapatabilir. Exchange çekim isteğini reddeder, çünkü key’de withdraw permission yoktur.
Adres whitelist çekim alıcısını sınırlar: exchange fonları yalnızca önceden eklenen adreslere gönderir. Birçok exchange’de whitelist’e adres eklemek 2FA (iki faktörlü kimlik doğrulama) ve ayrı bir kanal üzerinden onay gerektirir; örneğin email, uygulama veya hardware key. Bu durumda yeni adrese çekim yalnızca API key’e değil, bu onay kanallarının kontrolüne de bağlıdır.
Whitelist değişiklik gecikmesi (security lock, hold) eklenen adresi hemen etkinleştirmez. Gecikme açıkken yeni adrese çekim hold süresi boyunca bloke edilir, bu yüzden eklenen adres ilk çekimden önce fark edilebilir.
Trading botların API bağlantısı, trade-only keys ve IP whitelist “Kripto trading botlarıyla kazanç” materyalinde açıklanır.
Çekim limitleri, saldırgan whitelist ve onay kontrollerinden geçen bir key elde ettiğinde kayıp tutarını sınırlar. Günlük limit, toplam hesap bakiyesine göre değil, düzenli operasyonel ödeme tutarlarına göre belirlenir; böylece tek bir çekim döngüsü tüm depozitoyu boşaltamaz.
Email kompromisi riski artırır, çünkü birçok exchange’de adres ekleme onayları ve güvenlik ayarlarını sıfırlama email’e bağlıdır; buna onay linkleri ve whitelist değişikliği bildirimleri dahildir.
Adres whitelist olmadan withdraw permission, API key leak durumunu blockchain’e doğrudan çekim kanalına dönüştürür. Adres whitelist ve whitelist değişiklik gecikmesiyle withdraw permission, kritik riski onay kanallarının kompromisine taşır. Çekim limitleri, diğer kısıtlar aşıldığında kayıp tutarını sınırlar.
🛡️ Sub-accounts: bakiye, keys ve süreç izolasyonu
Sub-accounts, tek bir exchange içinde bakiye ve API keys’i ayırır. Key leak durumunda işlemler belirli bir sub-account’un varlıklarıyla sınırlı kalır.
- Storage ve trading’in farklı sub-accounts’a ayrılması
- Storage sub-account ana sermayeyi tutar ve kalıcı trading API keys kullanmaz.
- Trading sub-accounts belirli botlar ve stratejiler için çalışma bakiyeleri tutar.
- API üzerinden dahili transfer kontrolü
- Trading keys üzerinde transfer permission’ın devre dışı bırakılması, trading key leak durumunda varlık taşıma olasılığını azaltır.
- Dahili transferler operasyonel sürecin parçası olduğunda ayrı bir transfer key kullanılır.
- Trading paritesi whitelist desteği varsa key enstrümanlarının sınırlandırılması
- Trading paritesi whitelist, trading system’e ait olmayan enstrümanlarda trade’leri bloke eder.
- Parite sınırlaması düşük likiditeli piyasalarda zarar riskini azaltır.
Birden fazla trading system için izolasyon şeması
İzolasyon şeması bakiyeyi sub-accounts üzerinden, erişimi ise API keys, permissions ve IP whitelist üzerinden ayırır.
- Tek bir exchange’deki bir trading system, ayrı bir sub-account ve VPS IP’sine bağlı trade-only key üzerinden çalışır.
- Raporlama, ayrı bir sunucuda read-only key ile bağlanır; böylece raporlama leak’i trading key’i açığa çıkarmaz.
- Operasyonel transferler trade ve withdraw permissions olmayan transfer key ile yürütülür.
Trading system key leak olduğunda exchange işlemleri yalnızca onun sub-account bakiyesi kapsamında yürütür, bu nedenle kayıplar çalışma bakiyesiyle sınırlanır.
🗄️ Secrets saklama ve rotasyon: API Secret altyapıdan nasıl leak olur
API Secret çoğu zaman exchange üzerinden değil, trading system altyapısından leak olur: kod repolarından, CI/CD pipeline’larından (otomatik build ve deployment süreçleri), uygulama loglarından, veritabanı dump’larından, ekran görüntülerinden ve yedeklerden. Secrets yönetimi, API Secret’ın saklandığı yerleri ve ona erişebilen rolleri belirler.
API Secret uygulama kodunda saklanmaz. Secret değeri, servis başlatılırken korumalı depodan verilir ve proje dosyalarında veya repoda kaydedilmez. Kod ve konfigürasyonda secret değerinin kendisi değil, secret’a referans kalır.
Örnek: bir trading bot CI/CD üzerinden deploy edilir. Repoda yalnızca secret adı saklanır; API Secret değeri deployment aşamasında korumalı depodan verilir. Kod ve commit geçmişi leak olduğunda API Secret bunların içinde bulunmaz.
Production ortamında API Secret, secrets’ı şifreli biçimde tutan ve bunları yalnızca IAM (rol tabanlı erişim yönetimi) üzerinden izinli süreçlere veren bir secret manager içinde saklanır. Bu şema production secrets’ı dev ortamlarından ve test servislerinden ayırır.
Riskle ve trading planıyla çalışırken ortaya çıkan davranışsal hata nedenleri “Trader psikolojisi” materyalinde incelenir.
API keys rotasyonu uzun ömürlü leak riskini azaltır. Rotasyon, exchange’de yeni key oluşturmayı, sistemi yeni API Secret’a geçirmeyi ve exchange’in eski secret ile imza kabul etmeyi bırakması için eski key’i iptal etmeyi içerir.
Geçiş, açık pozisyonların ve aktif limit emirlerin olmadığı bir dönem için planlanır; böylece API Secret değişimi emir ve risk yönetimini kesintiye uğratmaz.
API Secret saklama için minimum kurallar
- API Secret, secret manager içinde veya erişim kontrollü şifreli depoda saklanır.
- API Secret, Git, Docker image, CI artifacts ve yedeklere açık biçimde girmez.
- Production secret dev ortamından erişilebilir değildir ve trading system’i çalıştırmayan rollere açık değildir.
- Rotasyon, geçişten sonra eski key’in iptal edilmesini içerir; böylece eski secret exchange tarafında çalışmayı bırakır.
Permissions, IP whitelist ve adres whitelist exchange tarafında koruma sağlar; secret management ise altyapı tarafında kod ve loglardan API Secret leak riskini azaltır.
🧩 Üçüncü taraf terminaller ve botlar: bağlantı riski nasıl etkiler
Üçüncü taraf servis, hesap adına istekleri imzalamak için API Key ve API Secret alır. Servis key’i web panelinde kabul ediyorsa API Secret sağlayıcının altyapısında saklanır. Sağlayıcıda bir incident yaşandığında saldırgan istekleri imzalayabilir ve exchange tarafındaki imza kontrolünden geçebilir.
✅ Yönetilebilir risk işaretleri
- Servis read-only ve trade-only keys ile çalışır ve trading ile raporlama için withdraw permission istemez.
- Servis API eylem günlüğü gösterir: oluşturulan emirler ve çağrılan endpoint’ler.
- Servis sınırlı çalışma bakiyesi olan ayrı bir sub-account üzerinden bağlantıyı destekler.
❌ Yükselmiş risk işaretleri
- Servis, operasyonel ödemelerle ilgili olmayan işlevler için withdraw permission ister.
- Servis IP whitelist’i devre dışı bırakmayı ister ve kullanıcı tarafı agent ile sabit IP modelini sunmaz.
- Servis API eylem geçmişi vermez, bu yüzden inceleme dolaylı sinyallere dayanır.
Konfigürasyon örneği: sinyaller ve raporlama read-only key kullanır, trading işlemleri çalışma bakiyesi olan sub-account üzerinde trade-only key kullanır, API üzerinden çekim kapalıdır.
Üçüncü taraf servis exchange kısıtlamalarını ortadan kaldırmaz. Sub-account, IP whitelist, minimum permissions ve devre dışı withdraw permission riski çalışma bakiyesiyle sınırlar.
🧯 Key leak’e tepki: yürütmeyi durdurma ve izleri sabitleme
API Key + API Secret çiftinin leak olduğundan şüphelenildiğinde risk hızlı gelişir, çünkü exchange imza, haklar, IP ve istek zamanını kontrol ettikten hemen sonra işlemleri yürütür. Tepki, key üzerinden yetkilendirmeyi durdurmak ve işlem izlerini sabitlemekle başlar.
- Exchange tarafında key’in iptali
- Key’in devre dışı bırakılması veya silinmesi, bu API Key ile imzalanmış isteklerin kabulünü durdurur.
- Leak kaynağı belirlenememişse sub-account’un tüm keys’i devre dışı bırakılır.
- İşlem izlerinin sabitlenmesi
- Anomali dönemi için açık emir listesi ve trade geçmişi, hangi işlemlerin yürütüldüğünü gösterir.
- Çekim geçmişi ve adres whitelist değişiklikleri çekim girişimlerini ve adres hazırlığını gösterir.
- Hesaba ek erişim kanallarının kapatılması
- Parola değişimi ve 2FA kontrolü web arayüzüne giriş riskini azaltır.
- Email güvenliği kontrolü gereklidir, çünkü çekim onayları ve whitelist değişiklikleri çoğu zaman email’e bağlıdır.
- Çalışma erişiminin geri yüklenmesi
- Yeni key, minimum permissions ve güncel sunucu için IP whitelist ile oluşturulur.
- API Secret, eski secret’ın kullanılmayı bırakması için secret manager’da güncellenir.
Key iptali eylemlerin yürütülmesini durdurur, çünkü istekler gelmeye devam etse bile exchange bu API Key için imza kabul etmeyi bırakır.
✅ Key leak durumunda çekim riskini azaltan konfigürasyon
API Key + API Secret çiftinin leak olmasından sonra çekim riski, trade key withdraw permission’a sahip olmadığında, istekler IP whitelist ile sınırlandığında ve ana sermaye trading sub-account’tan ayrıldığında azalır.
Trading system trade key için minimum parametre seti
- Trading system sabit IP’ye sahip VPS üzerinde çalışır ve bu IP key’in IP whitelist’ine eklenir.
- Key read + trade permissions’a sahiptir ve withdraw permission’a sahip değildir.
- Trading sub-account çalışma bakiyesini içerir, ana sermaye ise kalıcı trading keys olmadan ayrı saklanır.
- API Secret secret manager içinde veya şifreli depoda saklanır ve repolara ya da loglara girmez.
IP whitelist, minimum permissions, nadir çekimler için adres whitelist ve sub-accounts üzerinden izolasyon zararı çalışma bakiyesiyle sınırlar ve kompromize key üzerinden blockchain’e çekim riskini azaltır.
❓ API keys güvenliği hakkında FAQ
API Secret leak olsa bile IP whitelist neden korur?
Exchange istek kaynağı IP’sini key’in IP whitelist’iyle karşılaştırır ve IP eşleşmezse isteği reddeder. HMAC imzası doğru olabilir, ancak IP kontrolü exchange tarafında gerçekleştiği için işlem yürütülmez.
Withdraw permission gerçekten ne zaman gereklidir?
Withdraw permission blockchain’e otomatik operasyonel ödemeler için gereklidir. Trading, monitoring ve raporlama için withdraw permission gerekli değildir, çünkü bu süreçler exchange içinde trading ve read endpoint’lerini kullanır.
Trade-only key neden çekim olmadan kayıplara yol açabilir?
Trade-only key emir vermeye izin verir. Trade-only key’e erişim olduğunda saldırgan düşük likiditeli paritede daha kötü fiyattan trade’ler yürütebilir ve trading wallet’ta büyük bakiye varsa slippage, spread ve komisyonlardan zarar oluşturabilir.
Her trading system için neden ayrı sub-account gerekir?
Sub-account key’in erişebildiği bakiyeyi sınırlar. Trading system key leak olduğunda zarar bu sub-account’un varlıklarıyla sınırlanır, çünkü exchange işlemleri belirli sub-account bakiyesi içinde yürütür.
Emir kontrolünü kaybetmeden keys nasıl döndürülür?
Rotasyon yeni key oluşturmayı, trading system’i yeni API Secret’a geçirmeyi ve eski key’i iptal etmeyi içerir. Geçiş, key değişimi emir yönetimini kesintiye uğratmasın diye açık pozisyonların ve aktif limit emirlerin olmadığı döneme planlanır.
Üçüncü taraf terminal bağlantısında risk nasıl sınırlandırılır?
Risk, çalışma bakiyesi olan sub-account üzerinde trade-only key, IP whitelist (istekler kullanıcı tarafı agent üzerinden gidiyorsa) ve terminal operasyonel çekimlere katılmadığında devre dışı withdraw permission ile sınırlandırılır.
🧷 API kısıtlamaları çekim ve trading zararı riskini nasıl azaltır
API riski izin verilen işlemlere ve exchange’in her isteğe uyguladığı kontrollere bağlıdır: imza (API Secret), permissions, IP whitelist ve istek zamanı parametreleri.
- Devre dışı withdraw permission API üzerinden blockchain’e çekimi bloke eder, çünkü exchange bu hakka sahip olmayan key için withdrawal endpoint’lerini reddeder.
- Çekim adresi whitelist’i alıcıyı sınırlar, çünkü exchange fonları yalnızca önceden eklenen adreslere gönderir.
- IP whitelist istek kaynağını sınırlar, çünkü exchange imza doğru olsa bile key listesindeki IP’ler dışında gelen istekleri reddeder.
- Sub-accounts kayıp hacmini sınırlar, çünkü key tüm hesap varlıklarına değil, belirli sub-account bakiyesine erişir.