WordPress Secrets API 7.2 Sürümü İçin Önerildi

🇬🇧 English: Read this in English →

Son yirmi yılda devraldığım her WordPress sitesinde açmaktan kimsenin hoşlanmadığı bir çekmece var. Adı wp_options tablosu. İçinde stripe_secret_key, _sendgrid_api_key, mp_smtp_password, anthropic_api_key gibi düzinelerce satır düz metin olarak duruyor. Taşıma için bir veritabanı yedeği alıyorsun, bütün bu sırlar yedeğe binip yolculuğa çıkıyor. Yedeği staging için bir geliştiriciye e-posta ile gönderiyorsun, artık sırlar birinin gelen kutusunda. Bu, 2026’da bir WordPress sitesinin standart hâli — ve ben bu ekosisteme girdiğimden beri de standart hâliydi.

Bunu ahlak dersine dönüştürmeden söylüyorum. WordPress bu tabloyu, “API anahtarı” kavramının web’de neredeyse hiç var olmadığı bir on yıldan devraldı. Eklenti ekosistemi de sırları tutmak için hiç tasarlanmamış bir seçenek tablosunun etrafında büyüdü. Herkes durumu biliyor. Site Kit kendi şifrelemesini yazdı. WooCommerce bir alt küme ödeme sağlayıcısı için kendi çözümünü yazdı. Her SMTP eklentisi birazcık farklı bir şema getirdi. Ortak hiçbir şey, standart hiçbir şey, ve bir denetçinin parmakla gösterip “işte sınır burası” diyebileceği hiçbir şey yok.

Dün Eric Mann, bu çekmeceyi düzgün kapatmayı deneyen öneriyi Make/Core’a bıraktı.

Aslında ne yenilendi

25 Ağustos’ta Eric Mann, Make/Core üzerinde WordPress 7.2 için Secrets API önerisini yayımladı. Şekli küçük ve bilerek iddiasız: dört fonksiyon, bir değer nesnesi, platform sağlayıcıları için bir drop-in.

wp_set_secret( string $name, string $value ): bool|WP_Error
wp_get_secret( string $name, string $version = WP_Secret_Version::CURRENT ): WP_Secret|null|WP_Error
wp_delete_secret( string $name ): bool|WP_Error
wp_import_option_as_secret( string $option, string $name ): bool|WP_Error

WP_Secret::reveal(): string
WP_Secret::fingerprint(): string

Fonksiyon listesinden çok, beş tasarım kararı önemli. Birincisi: şifreleme koşulsuz. Düz metin modu yok, kapatmaya yarayan bir sabit de yok. Her sır, kendi veri anahtarıyla sarmalanıyor, o anahtar da bir ana anahtarla sarmalanıyor. Kullanılan araç PHP’nin gömülü libsodium’u (eklenti kapalıysa sodium_compat). Anahtar malzemesi öncelikle senin tanımlayacağın WP_SECRETS_KEY sabitinden geliyor; tanımlamazsan mevcut LOGGED_IN_KEY ve LOGGED_IN_SALT‘tan türetiliyor.

İkincisi: okuma yolunda filtre yok. WordPress için sıra dışı bir karar ve gerekçesi açık — düz metin sırrı alan her filtre, belgelenmiş bir dinleme noktasına dönüşür. Genişletme, secrets.php drop-in dosyasıyla yüklenen iki takılabilir sağlayıcı üzerinden yapılıyor: biri şifreli metnin nerede duracağını (Vault, AWS Parameter Store, hosting sağlayıcı API’si), diğeri ana anahtarı neyin sarmalayacağını (KMS, HSM) belirliyor. Hiçbiri düz metni görmüyor.

Üçüncüsü: wp_get_secret() üç farklı sonuç durumu döndürüyor ve üçü de farklı anlamlara geliyor. Başarıda bir WP_Secret nesnesi, sır yoksa null, sır var ama çözülemiyorsa WP_Error. Bu ayrım, hosting’de bir salt döndüğünde eklentinin neşeyle “hesabını yeniden bağla” sihirbazını başlatmasını engelleyen şey.

Dördüncüsü: API dışarıya karşı sadece yazma. Dışa aktarma yok. Düz metni WP_Secret‘ten almak için açıkça ->reveal() çağırmak zorundasın. Bu, kullanım noktalarının kod incelemesinde grep ile bulunabilir olmasını sağlıyor. Nesne kendisini loglarda, var_dump()‘ta ve hata çıktılarında maskeliyor; serileştirmeyi de tümden reddediyor — yani paylaşılan hosting’te kalıcı bir object cache’e sızmıyor.

Beşincisi: otomatik geçiş yok. Çekirdek, “bu seçenek bir Stripe anahtarı tutuyor” ile “bu seçenek bir widget ayarı tutuyor” ayrımını güvenilir şekilde yapamaz, o yüzden denemiyor. Eklenti geliştiricileri her anahtar için ayrı ayrı wp_import_option_as_secret() çağırıyor ve içeri aktarılan değerler döndürülme (rotation) için işaretleniyor — çünkü düz metin sürüm zaten elindeki her yedekte var.

Takvim sıkı ama dürüst. Geri bildirim eylül ortasına kadar açık, önce API’yi gerçek kodda test edebilmek için bir feature plugin çıkacak, eylül sonunda Trac yaması geliyor ve 20 Ekim’deki 7.2 Beta 1 öncesinde ya birleşiyor ya da açıkça 7.3’e erteleniyor. 7.2’de yönetim ekranı yok — o 7.3’e planlı, gerçek kullanım verisi biriktikten sonra. WP-CLI ise ilk günden kapsamda; bu, kendi eski sızıntısını da çözüyor: kimlik bilgisi argüman olarak alan komutlar shell geçmişinde ve süreç listesinde kalıyordu. Çalışan proof-of-concept eklentisi altı aydır yayında ve API şekli buradan çıktı.

WordPress ve WooCommerce ekipleri için neden önemli

Buradaki tehdit modeli “birisi sunucunda shell açtı” değil. O olursa WordPress süreci içinde çalışan hiçbir şey seni koruyamaz, öneri bunu açıkça söylüyor. Tehdit modeli çok daha yaygın olan: veritabanı yedeği olmaması gereken bir yere düşer. Yedek, açık kaldığı sonradan anlaşılan bir S3 bucket’ında saklanır. Bir staging kopyası, laptopuna alan bir alt yükleniciye verilir. Alakasız bir eklentideki SQL enjeksiyonu wp_options okumasını dışarı verir. Bugün bu senaryoların hepsinde bütün API anahtarların açığa çıkar.

Secrets API’nin değiştirdiği şey, çalınmış bir veritabanının değeri. Bu küçük bir mesele değil. Bir WooCommerce mağazasında wp_options‘taki kimlik bilgileri şunlar: canlı ödeme sağlayıcı anahtarları, SMTP röle, kargo etiketi hesabı, KDV hesaplama servisi, ERP senkron tokeni, bülten sağlayıcısı ve gitgide daha sık bir veya birkaç yapay zekâ sağlayıcı anahtarı — sayaç üzerinden faturalanan cinsten. Sızan bir Stripe test anahtarı bir destek talebi. Sızan bir Anthropic ya da OpenAI üretim anahtarı ise birisi fark edene kadar büyümeye devam eden bir fatura.

İkinci bir şey daha söylenmeli. Bu öneri, kurumsal onboarding’lerin her birinde bize sorulan şu soruya ilk dürüst yanıt: “Bu WordPress sitesi hangi kimlik bilgilerini tutuyor, kim koydu, en son ne zaman rotate edildi?” Bugünkü cevap bir omuz silkme ve bir veritabanı export’u. Namespace’li sırlar, değişimde eski/yeni parmak izlerini taşıyan bir denetim hook’u ve zamanla 7.3’te bir ekran ile bu soru gerçek bir cevaba kavuşuyor. WordPress’in her zaman yönetişim (governance) dediği şey tam da bu — var olduğu için ölçeklenebilen sıkıcı ve olgun bir katman.

V1’de bilerek olmayan parçayı da not edelim. Eklenti başına yalıtım yok. WordPress olarak çalışan her kod, her namespace için wp_get_secret() çağırabilir. Eklenti slug’ları kimlik doğrulamıyor. Kurduğun bir eklenti kötü niyetliyse anahtarlarına zaten hep erişimi vardı, olmaya da devam edecek. Eric Mann bu sınırı önerinin içinde açıkça söylüyor. Secrets API’yi eklenti güvenlik duvarı olarak okuma.

Ben olsam ne yapardım (ya da yapmazdım)

Tavsiyem kısa.

Ajans işi yürütüyorsan: öneriyi bu hafta oku ve Make/Core başlığına, API şekli hâlâ ucuz değişebiliyorken geri bildirimini bırak. Eric’in en alta koyduğu beş açık soru, senin operasyonel gerçekliğinin cevap verebileceği sorular. Kaç rotation slot’una ihtiyaç var, bugün sırları tüketen hangi WP-CLI komutları en can sıkıcı, Pantheon’un platform depoları için işaret ettiği “okunabilir ama yazılamaz” durumu senin hosting yığınını etkiliyor mu — bunlar. Geri bildirimin şu iki hafta içinde koda dönüşür. İki ay sonra destek talebine dönüşür.

Eklenti geliştiriyorsan: Displace Secrets Manager proof-of-concept’ini bir dev sitede kur, kimlik bilgilerinden birini uçtan uca oradan geçir ve neyin kırıldığını gör. Feature plugin olarak önce yayımlamanın bütün amacı bu: API şekli donmadan önce sivri kenarları yüzeye çıkarmak. Şimdi iki saatini vermek, tasarımın doğru oturduğu bir ekosisteme değer.

Üretimdeki WordPress veya WooCommerce siteleri işletiyorsan: henüz hiçbir şeyi migrate etme. API bir öneri, sürüm değil. Feature plugin bir önizleme. Ekimde 7.2’de yer alsa bile içeri aktarılan sırlar zaten rotation için işaretli — çünkü düz metin sürüm elindeki her yedekte. Gerçek geçiş, o anahtarları upstream sağlayıcıların üzerinde tek tek, bakım penceresinde, geri dönüş planıyla döndürmek demek. Bunu 2027’nin ilk çeyreğinde hijyen backlog’una koy. Öne çekme.

Ve önümüzdeki altı ayda pazarlama metninde “WordPress secrets” geçen hiçbir şeyi satın alma. Eklentiler çıkacak. Bazıları iyi niyetli olacak. Ama çekirdekteki standart arayüz var olana kadar hiçbiri standart olamaz. Bir müşteri bu çeyrekte “şifreli API anahtar depolaması” isterse, dürüst cevap şu: WordPress bunun üzerinde çalışıyor, tasarım açık, doğru hamle üçüncü bir yamayla üzerini örtmek yerine doğru uygulamayı beklemek.

Kişisel bir not. Doksanlı yılların ortasında çok dilli CD-ROM projeleri çıkarıyorduk. Çevrimiçi katmanın “API anahtarı” bir Lingo script’inde sabit kodlu duruyor, cast dosyasına derleniyor ve yüz bin diskin üzerine basılıyordu. Sızdığında — ki tabii ki sızıyordu — çözüm yeni bir baskı almaktı. Yirmi beş yıl sonra düz metnin bilinen bir yerde durması kalıbı hâlâ bizimle, sadece farklı bir tabloda. WordPress’in bunu düzgün çözmeye — koşulsuz şifreleme duruşuyla ve tembelliğe kaçış kapısı bırakmadan — yeltendiğini görmek gerçekten sevindirici. Ben bu önerinin bu sürümünün yerleşmesini istiyorum.

Çekmecenin nihayet bir kilidi olacak. Öneriyi oku, geri bildirim bırak ve üretimde ellemeden önce tasarımın oturmasını bekle.