Vercel 2026 Veri İhlalinden 7 API Güvenliği Dersi

ÖZET

19 Nisan 2026'da Vercel, saldırganların üçüncü taraf bir yapay zeka aracının OAuth entegrasyonu aracılığıyla dahili sistemlerini tehlikeye attığını ve beklemede şifrelenmemiş olarak saklanan müşteri ortam değişkenlerini açığa çıkardığını duyurdu. Bu ihlal, her API geliştiricisinin uygulaması gereken yedi kritik dersi ortaya koyuyor: sırları beklemede şifreleyin (yalnızca aktarımda değil), yapay zeka geliştirme araçlarından gelen OAuth izinlerini denetleyin, tüm ortam değişkenlerini varsayılan olarak hassas kabul edin, kimlik bilgisi rotasyonunu otomatikleştirin, CI/CD hattınızı güvence altına alın, API'leri varsayılan olarak güvenlik açık olacak şekilde oluşturun ve bir olaya müdahale eylem planını ihtiyacınız olmadan önce hazırlayın.

Giriş

Context.ai adlı küçük bir yapay zeka aracına verilen tek bir OAuth izni, saldırganlara Vercel'in dahili sistemlerine doğrudan bir yol açtı. Buradan, beklemede şifrelenmemiş olan müşteri ortam değişkenlerine, API anahtarlarına, veritabanı kimlik bilgilerine ve dağıtım tokenlarına eriştiler.

İhlal, Vercel'in güvenlik duvarlarının olmamasından veya HTTPS'i etkinleştirmeyi unutmasından kaynaklanmadı. Mimari varsayımlar yüzünden oldu: geliştiricilerin sırları "hassas" olarak işaretlemek için manuel olarak kabul edeceği, üçüncü taraf yapay zeka entegrasyonlarının düşük riskli olduğu ve üretkenlik araçlarına verilen OAuth kapsamlarının düzenli denetimlere ihtiyaç duymadığı varsayımları.

API'ler oluşturuyorsanız veya kullanıyorsanız, bu olay incelenmeye değer bir vaka çalışmasıdır. Saldırı zinciri, çoğu geliştirme ekibinin her gün tekrarladığı kalıpları kullandı: kimlik bilgilerini ortam değişkenlerinde saklama, yapay zeka araçlarına OAuth erişimi verme ve hassas verileri korumak için platform varsayılanlarına güvenme.

Bu kılavuz, Vercel ihlalinden çıkarılacak yedi dersi ayrıntılarıyla ele almakta ve her birini kendi API iş akışınıza nasıl uygulayacağınızı, bu hafta atabileceğiniz somut adımlarla birlikte göstermektedir.

Ne Oldu: Vercel Nisan 2026 İhlali

Saldırı Zinciri

17 Nisan ile 19 Nisan 2026 tarihleri arasında bir saldırgan Context.ai'nin Google Workspace OAuth uygulamasını tehlikeye attı. Context.ai, küçük bir oyuncu ve büyük bir kimlik sağlayıcı olmayan bir yapay zeka gözlemlenebilirlik aracıydı. Ancak bir Vercel çalışanının Google Workspace hesabına OAuth erişimi vardı.

İşte zincirin nasıl geliştiği:

1. Saldırgan Context.ai'nin OAuth uygulamasını tehlikeye atar ve Google Workspace entegrasyonunun kontrolünü ele geçirir
2. O OAuth erişimini kullanarak bir Vercel çalışanının Google hesabını ele geçirir, o çalışanın sahip olduğu tüm izinleri devralır
3. Vercel'in dahili sistemlerine sızar, müşteri odaklı veri depolarına erişir
4. Müşterilerin "hassas" olarak işaretlemediği ortam değişkenlerini çıkarır; bunlar beklemede şifrelenmemiş olarak saklanıyordu

Vercel, saldırganı "işletme hızı ve Vercel'in sistemlerine dair ayrıntılı anlayışı göz önüne alındığında oldukça sofistike" olarak tanımladı.

Ne Açığa Çıktı

Onaylanmış tehlikeye atılanlar:

• ''Hassas'' olarak işaretlenmemiş müşteri ortam değişkenleri (API anahtarları, veritabanı URL'leri, imzalama anahtarları, dağıtım tokenları)
• 580 çalışan kaydı (isimler, Vercel e-postaları, hesap durumu, etkinlik zaman damgaları)

Tehlikeye atılmayanlar (Vercel'e göre):

• ''Hassas'' olarak işaretlenmiş ortam değişkenleri (beklemede şifrelenmiş)
• Temel platform altyapısı

Kritik tasarım detayı: Vercel'in ortam değişkenleri için "hassas" bayrağı varsayılan olarak KAPALIydı. Sırlar yalnızca bir geliştirici açıkça kabul ederse beklemede şifrelenir. Bu isteğe bağlı katılım modeli, geliştirici topluluğundan yoğun eleştiriler aldı.

Bu Neden API Geliştiricileri İçin Önemli

Oluşturduğunuz veya tükettiğiniz her API, sırlar üzerinde çalışır: API anahtarları, OAuth tokenları, veritabanı kimlik bilgileri, webhook imzalama anahtarları. Vercel ihlali API'leri doğrudan hedef almadı. API kimlik bilgilerinin yaşadığı altyapıyı hedef aldı. Ve bu altyapı sizinle aynıdır: ortam değişkenleri, OAuth entegrasyonları, CI/CD boru hatları ve üçüncü taraf araçlar.

Ders 1: Sırları yalnızca aktarımda değil, beklemede de şifreleyin

HTTPS, API anahtarlarınızı aktarımda korur. Peki bu anahtarlar bir dağıtım platformundaki bir ortam değişkeninde durduğunda ne olur? Vercel'in durumunda, "hassas olmayan" ortam değişkenleri beklemede şifrelenmemiş olarak saklanıyordu. Saldırganın ağ trafiğini engellemesine gerek kalmadı. Kimlik bilgilerini doğrudan depolamadan okudular.

Ne Yapmalı

• Özel bir sır yöneticisi kullanın. HashiCorp Vault, AWS Secrets Manager ve Azure Key Vault varsayılan olarak sırları beklemede şifreler. API anahtarlarınız, veritabanı parolalarınız ve imzalama anahtarlarınız buraya aittir, düz metin ortam değişkenlerine değil.
• Platformunuzda beklemede şifrelemeyi doğrulayın. Dağıtım platformunuzun ortam değişkenlerini varsayılan olarak şifreleyip şifrelemediğini veya kabul etmenizi isteyip istemediğini kontrol edin. Eğer isteğe bağlıysa, bazılarını kaçırmış olabileceğinizi varsayın.
• Yapılandırmayı sırlardan ayırın. Ortam değişkenleri hassas olmayan yapılandırmalar (günlük seviyeleri, özellik bayrakları, bölge ayarları) için uygundur. Kimlik bilgileri bir kasaya aittir.

Apidog Bunu Nasıl Yönetir

Apidog, HashiCorp Vault, Azure Key Vault ve AWS Secrets Manager ile yerel olarak entegre olur. Kimlik doğrulama gerektiren API'leri test ederken, kimlik bilgileriniz çalışma zamanında kasadan çekilir; asla proje dosyalarınızda veya ortam yapılandırmanızda düz metin olarak bulunmazlar. Apidog'daki kimlik doğrulama şablonları ile gerçek kimlik bilgileri arasındaki ayrım, API test yapılandırmalarını sırları açığa çıkarmadan ekibinizle paylaşabileceğiniz anlamına gelir.

Ders 2: Yapay Zeka Geliştirme Araçlarından Gelen OAuth İzinlerini Denetleyin

Tüm Vercel ihlali, bir yapay zeka aracına verilen tek bir OAuth izniyle başladı. Context.ai şüpheli bir uygulama değildi. Tehlikeye atılmış, yasal bir gözlemlenebilirlik aracıydı.

Yapay zeka araç ekosistemi hızla büyüyor. Claude Code, Cursor, GitHub Copilot, Windsurf, v0 ve düzinelerce daha küçük araç, geliştirme ortamınıza OAuth veya API erişimi talep ediyor. Her biri bir saldırgan için potansiyel bir pivot noktasıdır.

Ne Yapmalı

• Google Workspace, GitHub ve kimlik sağlayıcınızdaki her OAuth iznini envanterleyin. Bir uygulamayı tanımıyorsanız, iptal edin.
• Üç aylık bir denetim planı belirleyin. OAuth izinleri sessizce birikir. Altı ay önce bir günlüğüne denediğiniz bir araç hala erişime sahip olabilir.
• En az ayrıcalık ilkesini uygulayın. Yapay zeka araçlarına OAuth kapsamları verirken, mevcut en dar kapsamı seçin. Mümkünse salt okunur erişim sağlayın. Kesinlikle gerekli olmadıkça yönetici erişimi vermeyin.
• Anormal OAuth davranışlarını izleyin. Google Workspace Yönetici Konsolu üçüncü taraf uygulama erişimini gösterir. Yeni OAuth izinleri ve olağandışı etkinlik modelleri için uyarıları etkinleştirin.

Yapay Zeka Tedarik Zinciri Riski

Bu, çoğu API güvenlik kılavuzunun henüz yakalayamadığı, 2026'ya özgü bir tehdittir. Geliştiriciler, yapay zeka kodlama yardımcılarını, gözlem araçlarını ve otomasyon ajanlarını güvenlik incelemesini aşan bir hızda çalışma alanlarına bağlıyorlar. Bağlı her araç saldırı yüzeyinizi genişletir. Vercel olayı, küçük ve niş bir yapay zeka aracının bile büyük bir ihlal için giriş noktası olabileceğini kanıtlıyor.

Ders 3: Tüm Ortam Değişkenlerini Varsayılan Olarak Hassas Kabul Edin

Vercel'in mimarisi "hassas" özelliğini isteğe bağlı bir bayrak haline getirmişti. Varsayılan, şifrelenmemiş depolamaydı. Bu, bir kutuyu işaretlemeyi unutan (veya bilmeyen) herhangi bir geliştiricinin API anahtarlarını açığa çıkarması anlamına geliyordu.

Bu bir tasarım felsefesi sorunudur, bir onay kutusu sorunu değil.

Ne Yapmalı

• Varsayılan olarak şifrelenmiş olsun. Platformunuz bir "hassas" geçiş düğmesi sunuyorsa, her şey için etkinleştirin. Çalışma zamanında ortam değişkenlerini şifre çözme performans maliyeti, bir ihlalin maliyetiyle karşılaştırıldığında ihmal edilebilir düzeydedir.
• Değişkenlerinizi sınıflandırın. Onları iki kategoriye ayırın: yapılandırma (sır olmayan) ve kimlik bilgileri (sır). İstisnasız tüm kimlik bilgilerine şifreleme uygulayın.
• Disiplini sağlamak için adlandırma kuralları kullanın. Sır değişkenlerini SECRET_ veya CREDENTIAL_ ile ön ekleyin, böylece ekibiniz kod incelemesi sırasında korunmasız sırları fark edebilir.

# Yapılandırma (sır olmayan)
LOG_LEVEL=info
REGION=us-east-1
FEATURE_FLAG_NEW_UI=true

# Kimlik Bilgileri (her zaman beklemede şifrelenir)
SECRET_DATABASE_URL=postgresql://...
SECRET_API_KEY=sk-...
SECRET_WEBHOOK_SIGNING_KEY=whsec_...

• Sınıflandırmayı otomatikleştirin. KEY, SECRET, TOKEN, PASSWORD veya CREDENTIAL gibi desenler içeren ve hassas olarak işaretlenmemiş herhangi bir ortam değişkenini işaretleyen bir CI kontrolü yazın.

Ders 4: Kimlik Bilgisi Rotasyonunu Otomatikleştirin

Vercel ihlali açıkladığında, müşterilerine ilk tavsiyesi tüm hassas olmayan ortam değişkenlerini derhal döndürmeleri oldu. Düzinelerce hizmeti ve yüzlerce API anahtarı olan ekipler için bu, acı verici, manuel bir süreçtir.

En hızlı toparlanan ekipler, zaten otomatik rotasyon mekanizmalarına sahip olanlardı.

Ne Yapmalı

• Kısa sona erme süreleri belirleyin. API anahtarları ve tokenları 90 gün veya daha kısa sürede sona ermelidir. Daha kısa olması daha iyidir. Bir anahtar sızarsa, açıklık penceresi sınırlı olur.
• Sır yöneticinizle rotasyonu otomatikleştirin. AWS Secrets Manager ve HashiCorp Vault'un her ikisi de otomatik rotasyon zamanlamalarını destekler. Bunları yapılandırın.
• Rotasyonu dağıtım hattınıza dahil edin. Yeni bir sürüm dağıttığınızda, kimlik bilgilerini sürecin bir parçası olarak döndürün. Bu, rotasyonu bir güvenlik görevinden bir dağıtım adımına dönüştürür.
• İhtiyaç duymadan önce rotasyonu test edin. Üç ayda bir rotasyon tatbikatı yapın. Ekibiniz üretim ortamınızdaki her kimlik bilgisini 4 saat içinde döndürebilir mi? Eğer yapamıyorsanız, yapana kadar pratik yapın.

API Geliştiricileri İçin Bir Rotasyon Kontrol Listesi

Bir ihlal açıklandığında (sizin veya bağımlı olduğunuz bir platformun), bu sırayla döndürün:

1. Veritabanı kimlik bilgileri (en yüksek etki alanı)
2. Harici hizmetler için API anahtarları (ödeme işlemcileri, e-posta sağlayıcıları, bulut hizmetleri)
3. OAuth istemci sırları (daha fazla kimliğe bürünmeyi önler)
4. Webhook imzalama anahtarları (sahte webhook yüklerini önler)
5. Dağıtım tokenları (izinsiz dağıtımları önler)
6. Oturum imzalama anahtarları (potansiyel olarak tehlikeye atılmış oturumları geçersiz kılar)

Ders 5: CI/CD Hattınızı Bir API Saldırı Yüzeyi Olarak Güvence Altına Alın

CI/CD hattınız, derleme zamanında ortam değişkenlerini ve sırları okur. Kod tabanınıza, dağıtım hedeflerinize ve genellikle üretim kimlik bilgilerinize erişimi vardır. Vercel ihlalinde, saldırgan dağıtımları yöneten dahili sistemlere erişti. Hattınız da farklı değil.

Ne Yapmalı

• Sırları belirli hatlarla sınırlayın. Üretim veritabanı URL'nizi her CI işi için kullanılabilir hale getirmeyin. Sırları onlara ihtiyaç duyan hatlarla kısıtlayın.
• CI'da kısa ömürlü kimlik bilgileri kullanın. Uzun ömürlü API anahtarları yerine, derleme tamamlandıktan sonra süresi dolan OIDC tokenları veya geçici kimlik bilgileri kullanın. GitHub Actions, AWS, Azure ve GCP için OIDC'yi yerel olarak destekler.
• Hat erişim günlüklerini denetleyin. Derlemeler sırasında sırlara kimlerin (ve nelerin) eriştiğini gözden geçirin. Normalde ihtiyaç duymadığı sırları okuyan bir derleme işi gibi anormal erişim modelleri uyarıları tetiklemelidir.
• CI bağımlılıklarınızı sabitleyin. Tedarik zinciri saldırıları CI çalıştırıcılarını da hedef alır. Eylem sürümlerini değiştirilebilir etiketler yerine belirli commit SHA'larına sabitleyin.

# Kötü: değiştirilebilir etiket
- uses: actions/checkout@v4

# İyi: belirli bir commite sabitlenmiş
- uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11

• Derleme ortamlarını izole edin. Her derlemeden sonra yok olan kısa ömürlü derleme çalıştırıcıları kullanın. Kalıcı çalıştırıcılar durum biriktirir ve kimlik bilgisi sızıntısı riski taşır.

Apidog CI/CD Güvenliğinize Nasıl Uyar

Apidog'un CLI aracı, kimlik bilgilerini hat yapılandırmanıza gömmeden CI/CD hatlarında API testleri yapmanızı sağlar. Kimlik bilgilerini çalışma zamanında kasanızdan çekebilir, test senaryolarınızı yürütebilir ve derleme bittiğinde kimlik bilgilerini atabilirsiniz. Bu, dağıtım sürecinizi yavaşlatmadan API testinizi güvende tutar.

Ders 6: API'leri Varsayılan Olarak Güvenlik Açık Olacak Şekilde Oluşturun

Vercel olayı daha geniş bir prensibi vurgulamaktadır: güvenlik kontrolleri varsayılan olarak etkinleştirilmeli, geliştiriciler belirli bir nedeni olduğunda vazgeçmelidir. Vercel'deki isteğe bağlı katılım modeli başarısız oldu çünkü geliştiriciler bir kutuyu işaretlemeleri gerektiğini bilmiyorlardı (veya unutmuşlardı).

Bu prensibi oluşturduğunuz API'lere uygulayın.

Ne Yapmalı

• Varsayılan olarak tüm uç noktalarda kimlik doğrulamasını zorunlu kılın. Kimlik doğrulaması yapılmamış erişimi kural değil, istisna haline getirin. Bir uç nokta herkese açıksa, nedenini belgeleyin.
• Varsayılan olarak hız sınırlamayı etkinleştirin. Muhafazakar limitlerle başlayın (API anahtarı başına dakikada 100 istek) ve müşterilerin ihtiyacı olduğunda bunları artırın.
• Minimal hata bilgisi döndürün. API'niz hata yanıtlarında dahili ayrıntıları sızdırmamalıdır. Yığın izleri, veritabanı adları ve dahili IP'ler günlüklerinizde olmalı, 500 yanıtlarında değil.
• Tüm girdiyi agresif bir şekilde doğrulayın. İstemci tarafından sağlanan verilere güvenmeyin. Her uç noktada türleri, uzunlukları, aralıkları ve formatları doğrulayın.
• Tüm kimlik doğrulama olaylarını günlüğe kaydedin. Başarılı oturum açma işlemleri, başarısız denemeler, token yenilemeleri ve izin değişikliklerinin tümü denetim günlüğü girişleri oluşturmalıdır.

Apidog'da Güvenlik Şeması Tasarımı

Apidog, OAuth 2.0, JWT, mTLS, API Anahtarı ve Hawk kimlik doğrulaması dahil olmak üzere 13 kimlik doğrulama yöntemini yerel olarak destekler. API'nizi Apidog'da tasarlarken, güvenlik şemalarını proje düzeyinde tanımlar ve tüm uç noktalarınızda devralırsınız. Bu, oluşturduğunuz her uç nokta için kimlik doğrulamasının varsayılan olarak açık olduğu anlamına gelir. Bir uç noktanın herkese açık olmasını istiyorsanız, güvenlik şemasını açıkça kaldırırsınız; bu bilinçli bir vazgeçme, unutulmuş bir kabul etme değil.

Her kimlik doğrulama yöntemini, özel istemci sertifikaları ve CA sertifikalarıyla karşılıklı TLS dahil olmak üzere doğrudan Apidog'un arayüzünde test edebilirsiniz. Bu, dağıtımdan önce güvenlik yapılandırmanızın doğru çalıştığını doğrulamanızı ve kimlik doğrulama yanlış yapılandırmalarını erken yakalamanızı sağlar.

Ders 7: Bir Olay Müdahale Eylem Planını İhtiyaç Duymadan Önce Oluşturun

Mevcut SERP'deki hiçbir sıralama API güvenlik kılavuzu, bir API kimlik bilgisinin tehlikeye atılmasından sonra ne yapılması gerektiğini kapsamaz. Vercel ihlali birçok ekibi bir eylem planı olmadan yakaladı. Hangi anahtarları önce döndüreceklerini, izinsiz API çağrılarını nasıl kontrol edeceklerini ve etkilenen kullanıcılarla nasıl iletişim kuracaklarını bulmak için çabaladılar.

API Kimlik Bilgisi Olay Müdahale Eylem Planınız

Aşama 1: Sınırlama (ilk 30 dakika)

• Potansiyel olarak açığa çıkan kimlik bilgilerini belirleyin
• En yüksek riskli kimlik bilgilerini derhal döndürün (veritabanı, ödeme işlemcileri)
• Tüm API uç noktalarında gelişmiş günlüğü etkinleştirin
• Tespit edilirse bilinen saldırgan IP'lerini/tokenlarını engelleyin

Aşama 2: Değerlendirme (ilk 4 saat)

• Maruz kalma penceresi için API erişim günlüklerini inceleyin
• Tehlikeye atılmış kimlik bilgileriyle yapılan izinsiz API çağrılarını belirleyin
• Veri sızdırma desenlerini kontrol edin (olağandışı sorgu hacimleri, büyük yanıtlar, hassas uç noktalara erişim)
• Nelere erişildiğini ve nelere erişilmediğini belgeleyin

Aşama 3: Onarım (ilk 24 saat)

• Kalan tüm kimlik bilgilerini döndürün (Ders 4'teki rotasyon kontrol listesine bakın)
• Tüm aktif oturumları iptal edin ve yeniden kimlik doğrulamayı zorlayın
• Üçüncü taraf uygulamalara verilen OAuth izinlerini gözden geçirin ve iptal edin
• Güvenlik duvarı kurallarını ve IP izin listelerini güncelleyin
• İhlale izin veren güvenlik açığını yamalayın

Aşama 4: İletişim (48 saat içinde)

• Etkilenen müşterileri belirli ayrıntılarla bilgilendirin: neyin açığa çıktığı, neyin çıkmadığı, ne yapmaları gerektiği
• API tüketicileri için açık rotasyon talimatları sağlayın
• Zaman çizelgesi ve onarım adımlarıyla bir olay sonrası analizi yayınlayın
• Öğrenilen derslere göre güvenlik belgelerinizi güncelleyin

Eylem Planınızı Apidog ile Test Etme

Apidog'un test senaryolarını kullanarak kimlik bilgisi tehlikeye atma senaryolarını simüle edebilirsiniz. Şunları yapan test durumları oluşturun:

• Süresi dolmuş tokenların önbelleğe alınmış veri değil, 401 döndürdüğünü doğrulayın
• Döndürülen API anahtarlarının eski anahtarları hemen geçersiz kıldığını onaylayın
• Kaba kuvvet denemeleri sırasında hız sınırlamanın devreye girdiğini test edin
• Hata yanıtlarının dahili bilgileri sızdırmadığını doğrulayın

Güvenlik kontrollerinizin beklendiği gibi çalıştığını doğrulamak için her kimlik bilgisi rotasyonundan sonra bu testleri CI/CD hattınızda çalıştırın.

Gerçek Dünya Kullanım Senaryoları

Fintech API Platformu

Bir ödeme işleme girişimi, Vercel açıklamasından sonraki 3 saat içinde 340 API anahtarını döndürdü. AWS Secrets Manager'a bağlı önceden oluşturulmuş rotasyon komut dosyalarına sahiplerdi. Apidog'daki API testleri, üretim trafiğini değiştirmeden önce her döndürülmüş anahtarın doğru çalıştığını doğruladı. Sıfır kesinti süresi.

SaaS İşbirliği Aracı

Bir proje yönetimi API'si oluşturan bir ekip, ihlal açıklamasından sonra Vercel'de 17 şifrelenmemiş ortam değişkenine sahip olduklarını keşfetti. Tüm kimlik bilgilerini HashiCorp Vault'a taşıdılar, rotasyon sonrası her kimlik doğrulama yöntemini doğrulamak için Apidog test senaryoları kurdular ve şifrelenmemiş sırlarla yapılan dağıtımları engelleyen bir CI kontrolü eklediler.

E-ticaret API Ağ Geçidi

Bir e-ticaret platformu OAuth izinlerini denetledi ve GitHub organizasyonlarına erişimi olan 12 yapay zeka aracı buldu. Bu araçlardan sekizi 6 aydan uzun süredir kullanılmamıştı. Tüm kullanılmayan izinleri iptal ettiler ve üç aylık bir denetim döngüsü uyguladılar.

Sonuç

Vercel ihlali egzotik değildi. Çoğu API geliştirme iş akışında bulacağınız kalıpları kullandı: düz metin sırları, birikmiş OAuth izinleri ve isteğe bağlı güvenlik varsayılanları. Buradaki yedi ders teorik değil. Saldırı zincirinin nasıl işlediğine doğrudan yanıtlardır.

Anahtar Çıkarımlar:

• Tüm sırları yalnızca aktarımda değil, beklemede de şifreleyin
• Her OAuth iznini denetleyin, özellikle yapay zeka geliştirme araçlarını
• Tüm kimlik bilgileri için varsayılan olarak "hassas"ı kullanın
• İhtiyaç duymadan önce rotasyonu otomatikleştirin
• CI/CD hatlarını saldırı yüzeyleri olarak değerlendirin
• Varsayılan olarak kimlik doğrulama açık olacak şekilde API'ler oluşturun
• Olay müdahale eylem planınızı bu hafta yazın, bir ihlal sırasında değil

API kimlik bilgileriniz, araç zincirinizdeki en zayıf halka kadar güvenlidir. Vercel olayı, bu halkanın altı ay önce bağladığınız ve unuttuğunuz küçük bir yapay zeka aracı olabileceğini kanıtlıyor.

API iş akışınızı bugün güvence altına almaya başlayın. Kimlik doğrulama yöntemlerinizi test etmek, sır yöneticinizi bağlamak ve güvenlik odaklı test senaryoları çalıştırmak için Apidog'u indirin, hepsi tek bir çalışma alanında. Kredi kartı gerekmez.

Sıkça Sorulan Sorular

Vercel Nisan 2026 güvenlik olayı neydi?

Saldırganlar, Context.ai adlı üçüncü taraf bir yapay zeka aracının OAuth uygulamasını tehlikeye atarak, bir Vercel çalışanının Google Workspace hesabını ele geçirmek için kullandı ve beklemede şifrelenmemiş olan müşteri ortam değişkenlerine erişti. İhlal 19 Nisan 2026'da açıklandı.

Vercel müşteri API anahtarları açığa çıktı mı?

''Hassas'' olarak işaretlenmemiş müşteri ortam değişkenleri açığa çıktı. Buna, beklemede şifrelenmemiş olarak saklanan API anahtarları, veritabanı kimlik bilgileri ve dağıtım tokenları dahildir. Açıkça ''hassas'' olarak işaretlenmiş (beklemede şifrelenmiş) değişkenler tehlikeye atılmadı.

Vercel ortam değişkenlerimin şifreli olup olmadığını nasıl kontrol ederim?

Vercel panonuzda, Proje Ayarları > Ortam Değişkenleri bölümüne gidin. ''Hassas'' olarak işaretlenmiş değişkenler beklemede şifrelenmiştir. Bu bayrağı olmayan herhangi bir değişken şifrelenmemiş olarak saklanmıştır ve etkilendiyseniz derhal döndürülmelidir.

API anahtarlarını güvenli bir şekilde saklamanın en iyi yolu nedir?

HashiCorp Vault, AWS Secrets Manager veya Azure Key Vault gibi özel bir sır yöneticisi kullanın. Bunlar varsayılan olarak sırları beklemede şifreler, otomatik rotasyonu destekler ve denetim günlükleri sağlar. API anahtarlarını asla düz metin ortam değişkenlerinde, git depolarında veya yapılandırma dosyalarında saklamayın.

API anahtarlarını ne sıklıkla döndürmeliyim?

API anahtarlarını en az 90 günde bir döndürün. Yüksek riskli kimlik bilgileri (veritabanı parolaları, ödeme işlemcisi anahtarları) için her 30 günde bir döndürün. Altyapınızı veya bağımlı olduğunuz bir platformu etkileyen herhangi bir güvenlik olayından sonra tüm kimlik bilgilerini derhal döndürün.

OAuth tedarik zinciri saldırısı nedir?

Bir OAuth tedarik zinciri saldırısı, sistemlerinize OAuth erişimi olan üçüncü taraf bir uygulamayı hedefler. Sizi doğrudan saldırmak yerine, saldırgan üçüncü taraf uygulamayı tehlikeye atar ve mevcut OAuth izinlerini verilerinize erişmek için kullanır. Vercel ihlali, bu saldırı vektörünün tipik bir örneğidir.

Apidog, API güvenlik testine nasıl yardımcı olur?

Apidog, 13 kimlik doğrulama yöntemini destekler, önemli sır yöneticileriyle (HashiCorp Vault, Azure Key Vault, AWS Secrets Manager) entegre olur ve güvenlik odaklı test senaryoları çalıştırmanıza olanak tanır. Token sona ermesi, kimlik bilgisi rotasyonu, hız sınırlama ve hata yanıtı işleme gibi durumları CI/CD hattınızda çalışan otomatik test paketlerinde test edebilirsiniz.

Bir API kimlik bilgisi ihlalinden sonra ilk olarak ne yapmalıyım?

En yüksek riskli kimlik bilgilerinizi derhal döndürün: veritabanı parolaları, ödeme işlemcisi API anahtarları ve OAuth istemci sırları. Ardından tüm API uç noktalarında gelişmiş günlüğü etkinleştirin, maruz kalma penceresi için erişim günlüklerini inceleyin ve olay müdahale eylem planınızı sistematik olarak uygulayın.