WordPress Güvenlik Denetimi: Yayına Almadan Önce Neler Kontrol Edilmeli

Herhangi bir PAGEnza tarafından oluşturulan eklenti bir kullanıcının WordPress kurulumuna ulaşmadan önce üç otomatik güvenlik kontrolünden geçer. Bu gönderi, bu kontrollerin ne aradığını ve her birinin neden önemli olduğunu açıklıyor.

Neden Yapay Zeka tarafından üretilen kod denetime ihtiyaç duyar?

Büyük dil modelleri, WordPress eklentileri yazmakta şaşırtıcı derecede iyidir. Hook adlarını bilirler, WP kodlama standartlarını anlarlar, okunabilir PHP üretirler. Ancak öngörülebilir hatalar da yaparlar — ve bu hatalar güvenlik açıklarına yol açar.

En sık gördüklerimiz:

• Temizleme (sanitization) olmadan $_GET veya $_POST kullanımı
• Form gönderimlerinde nonce doğrulamasının eksikliği
• $wpdb->prepare() olmadan doğrudan veritabanı sorguları
• Dinamik davranış için eval() veya exec() kullanımı
• esc_html() veya esc_attr() olmadan kullanıcı verilerini çıktı alma

Bunlar egzotik uç durumlar değildir. LLM çıktılarında düzenli olarak görünürler — en iyi modellerde bile.

Aşama 1: Prompt doğrulama

Yapay zeka tek bir satır yazmadan önce, kullanıcının açıklamasını analiz ederiz. Bu adım iki kategori sorunu yakalar:

Manipülasyon girişimleri — yapay zekayı kasıtlı olarak kötü amaçlı kod üretmeye zorlayan promptlar. "Önceki talimatları yoksay" veya "test için bir arka kapı oluştur" gibi şeyler.

Belirsiz veya uygulanamaz açıklamalar — yararlı kod üretmek için çok kısa veya çok belirsiz olan promptlar. "Bir eklenti yap" çöp üretir; "Spam filtresi olan bir e-posta adresine gönderileri gönderen bir iletişim formu oluştur" gerçek bir şey üretir.

Prompt bu kontrolü geçemezse, kullanıcı genel bir reddetme yerine nedenini açıklayan özel bir hata mesajı görür.

Aşama 2: İzole bir kapta PHP lintleme

Yapay zeka PHP kodu ürettikten sonra, tamamen izole edilmiş bir Docker konteyneri içinde php -l aracılığıyla çalıştırılır. Bu, eklenti bir WordPress kurulumuna ulaşmadan önce sözdizimi hatalarını yakalar.

Ancak daha da ileri gidiyoruz: lintleme başarısız olursa, sistem çıktıyı reddetmekle kalmaz. Hatayı bir düzeltme promptuyla yapay zekaya geri gönderir — buna iyileştirme (healing) diyoruz. Yapay zeka kendi hatasını görür ve en fazla üç kez tekrar dener.

Bu, kullanıcıların neredeyse hiç "oluşturma başarısız oldu" mesajı görmediği anlamına gelir. Biraz daha uzun bir oluşturma süresi — ve çalışan kod görürler.

Aşama 3: Kod güvenlik taraması

Bu en önemli aşamadır. Aşağıdakileri kontrol eden statik bir analiz çalıştırırız:

Tehlikeli fonksiyonlar: eval(), exec(), system(), shell_exec(), passthru() — bunların herhangi biri eklentinin yayınlanmasını engeller.

SQL enjeksiyon vektörleri: enterpole edilmiş değişkenlerle ham $wpdb->query() çağrıları, $wpdb->prepare() eksikliği, doğrudan mysql_query() kullanımı.

Eksik izin kontrolleri: Ayrıcalıklı herhangi bir işlem yapmadan önce current_user_can() çağırmayan AJAX işleyicileri.

Eksik nonce doğrulama: wp_verify_nonce() veya check_ajax_referer() çağırmayan form işlemcileri.

Kaçırılmamış çıktı: echo $_GET[...], kaçış fonksiyonları olmadan echo $user_input.

Bunlardan herhangi biri bulunursa, eklenti engellenir. Kullanıcı, sadece "güvenlik kontrolü başarısız oldu" yerine, hangi fonksiyonların engellemeyi tetiklediğini ve nedenini tam olarak listeleyen bir rapor görür.

Denetim raporu nasıl görünür?

Her oluşturulan eklenti, açık dilde bir güvenlik denetim raporuyla birlikte gelir. Şunları listeler:

• Hangi kontroller geçti (yeşil)
• Hangi kontroller uyarıları tetikledi (kehribar) — engelleyici olmayan ancak dikkat gerektiren sorunlar
• İyileştirme sırasında otomatik olarak uygulanan düzeltmeler

Rapor, otomatik olarak oluşturulur ve eklenti indirmesine eklenir. Hem kendi güveniniz hem de müşterilere güvenliği ciddiye aldığınızı göstermek için kullanışlıdır.

Aşama 4: Kayıt sırasında doğrulama

Bu, ilk oluşturmanın bir parçası değildir — kullanıcılar PAGEnza düzenleyicisinde eklenti kodunu manuel olarak düzenlediklerinde geçerlidir.

Her kaydettiğinizde, aynı lint + güvenlik taraması tekrar çalışır. Düzenleme sırasında kritik bir güvenlik açığıintroduceseniz, onu düzeltene kadar kaydetme işlemi engellenir. Bu, bir geliştiricinin iki yıl boyunca üretimde kalan hızlı bir "geçici" değişiklik yaptığı yaygın senaryoyu önler.

Otomatik denetimin sınırları

Otomatik tarama, belirli bir sorun sınıfını iyi yakalar. Her şeyi yakalamaz.

Mantık hataları, bozuk iş mantığı ve bilinen tehlikeli kalıpları içermeyen ince izin yükseltme sorunları hala insan incelemesi gerektirir. Bu konuda belgelerimizde şeffafız — denetim, güvenlik incelemesinin yerini tutmaz, minimum bir standardı garanti eden bir tabandır.

Ödeme veya hassas verileri işleyen üretim eklentileri için, otomatik kontrollerin yanı sıra manuel bir inceleme öneririz. Denetim raporu, insan incelemecisine iyi bir başlangıç noktası sağlar.