Mixed Content (Karışık İçerik) Hatası ve Çözümü

SSL sertifikanızı kurdunuz, siteniz https:// ile açılıyor, hatta tüm HTTP trafiğini HTTPS'e yönlendirdiniz. Ama adres çubuğundaki o güven veren kilit simgesi bir türlü tam yeşil olmuyor; onun yerine küçük bir uyarı üçgeni ya da "Bu site tam olarak güvenli değil" ibaresi duruyor. Görsellerden biri yüklenmiyor, kaydırıcı çalışmıyor veya sayfa stilinin bir kısmı bozuk görünüyor. Bu tablonun neredeyse tek bir açıklaması vardır: mixed content, yani karışık içerik.

Karışık içerik, HTTPS ile yüklenen güvenli bir sayfanın içinde hâlâ http:// üzerinden çağrılan kaynaklar (görsel, CSS dosyası, JavaScript, font, iframe, video) bulunması durumudur. Sayfanın kendisi şifreli gelse bile, içindeki bu tek bir güvensiz kaynak zincirin en zayıf halkasını oluşturur ve tarayıcı buna sessiz kalmaz. Bu rehberde önce aktif ve pasif karışık içerik ayrımını, tarayıcının hangisini engelleyip hangisine yalnızca uyardığını netleştireceğiz. Ardından konsol ve "Why No Padlock" gibi araçlarla suçlu kaynakları tam olarak nasıl bulacağınızı, son olarak da WordPress veritabanı güncellemesinden upgrade-insecure-requests başlığına kadar kalıcı çözümleri adım adım uygulayacağız.

Mixed Content Hatası Nedir?#

Bir web sayfası tek bir dosyadan ibaret değildir. Tarayıcı https://alanadi.com adresini istediğinde önce HTML belgesini indirir, sonra o belgenin içinde tanımlı onlarca alt kaynağı tek tek çeker: stil dosyaları, betikler, logolar, ürün görselleri, gömülü haritalar, yazı tipleri. Bu alt kaynakların her biri kendi tam adresiyle (http:// ya da https://) çağrılır. İşte karışık içerik, ana belge güvenli (HTTPS) gelirken bu alt kaynaklardan bir kısmının güvensiz (HTTP) adreslerden istenmesidir.

Sorun neden ciddiye alınır? Çünkü HTTP üzerinden gelen bir kaynak, aradaki ağda değiştirilebilir. Düşünün: sayfanız HTTPS ile şifreli ama içindeki bir JavaScript dosyası http:// ile yükleniyor. Kafe Wi-Fi'sindeki ya da yol üstündeki kötü niyetli bir aracı, bu şifresiz betiği kendi zararlı koduyla değiştirebilir ve tarayıcı bunu sizin güvenli sayfanızın parçasıymış gibi çalıştırır. Yani tek bir HTTP betiği, HTTPS'in tüm koruma vaadini fiilen geçersiz kılabilir. Bu yüzden tarayıcılar karışık içeriği bir konfor sorunu değil, bir güvenlik açığı olarak değerlendirir.

Karışık içerik çoğunlukla HTTPS'e yeni geçmiş sitelerde ortaya çıkar. Site yıllarca HTTP ile çalışmış, içerikler yazılırken görsellerin ve bağlantıların adresleri http://alanadi.com/... biçiminde veritabanına kaydedilmiştir. Sertifika kurulup adres HTTPS olunca ana belge güvenli gelir, ama gövdeye gömülü bu eski http:// bağlantıları olduğu gibi kalır. HTTPS'e geçişin ve zorunlu yönlendirmenin nasıl doğru yapıldığını HTTPS yönlendirme rehberimizde ayrıntılı anlattık; bu yazı ise geçiş sonrası kalan o inatçı uyarıya odaklanıyor.

Aktif ve Pasif Karışık İçerik Farkı#

Tüm karışık içerik aynı ağırlıkta değildir. Tarayıcılar kaynağı, sayfaya ne kadar zarar verebileceğine göre iki gruba ayırır ve bunlara çok farklı davranır. Bu ayrımı anlamadan çözüme geçmek, "bir görsel yüklenmiyor" ile "sayfam tamamen bozuldu" durumlarını karıştırmanıza yol açar.

Pasif (passive/display) karışık içerik, sayfanın yalnızca görünümünü etkileyen, DOM ile etkileşime girmeyen kaynaklardır: görseller (<img>), video ve ses dosyaları (<video>, <audio>). Bir saldırgan bunları değiştirse bile en fazla yanlış bir görsel gösterebilir; sayfanın kodunu ele geçiremez. Bu yüzden tarayıcılar pasif içeriği genellikle yükler ama uyarır — kilit simgesini kırar ve konsola bir mesaj düşer.

Aktif (active) karışık içerik, sayfanın davranışını ve içeriğini değiştirebilecek her şeydir: <script> betikleri, <link> ile gelen CSS dosyaları, XMLHttpRequest/fetch istekleri, <iframe> çerçeveleri ve fontlar. Bunlar sayfanın tümüne erişebildiği için risk çok daha yüksektir. Modern tarayıcılar aktif karışık içeriği doğrudan engeller — kaynak hiç yüklenmez, sayfa bozulur.

Bu tabloyu aklınızda tutun, çünkü belirti doğrudan türü ele verir. Sitenizin görselleri geliyor ama kilit çıkmıyorsa muhtemelen pasif bir karışık içerikle uğraşıyorsunuzdur. Buna karşılık site stilsiz, "çıplak HTML" gibi görünüyor veya bir bölüm hiç çalışmıyorsa, büyük olasılıkla aktif bir kaynak (CSS ya da JS) engellenmiştir.

Tarayıcı Hangisini Engeller, Hangisine Uyarır?#

Chrome, Firefox, Edge ve Safari'nin karışık içeriğe yaklaşımı son yıllarda giderek sertleşti. Eskiden pasif içerik uyarıyla geçerken aktif içerik engelleniyordu; bugün tarayıcılar arada bir de "otomatik yükseltme" katmanı ekliyor. Süreci adım adım görelim.

Aktif karışık içerik için davranış nettir ve tüm modern tarayıcılarda aynıdır: kaynak istek bile atılmadan engellenir. Konsolda şuna benzer bir satır görürsünüz:

Mixed Content: The page at 'https://alanadi.com/' was loaded over HTTPS,
but requested an insecure script 'http://cdn.example.com/app.js'.
This request has been blocked; the content must be served over HTTPS.

Buradaki anahtar ifade "has been blocked" — yani betik hiç çalışmadı. Sayfanızın bir işlevi bu betiğe bağlıysa (menü, slider, ödeme formu doğrulaması), o işlev tamamen ölür.

Pasif içerikte ise tablo değişti. Chrome bir süredir pasif karışık içeriği (görselleri) sessizce otomatik olarak HTTPS'e yükseltmeye çalışır: http:// görselini önce https:// ile denemeye kalkar. Kaynak HTTPS'te de mevcutsa görsel sorunsuz yüklenir ve çoğu zaman kullanıcı hiçbir şey fark etmez. Ancak kaynak HTTPS'te yoksa, yükseltme başarısız olur ve görsel hiç görünmez. Konsolda bu kez "autoupgraded" veya "was not upgraded" gibi bilgilendirici mesajlar görürsünüz:

Mixed Content: The page at 'https://alanadi.com/' was loaded over HTTPS,
but requested an insecure element 'http://alanadi.com/wp-content/uploads/foto.jpg'.
This content was automatically upgraded to HTTPS.

Sonuç olarak: kilit simgesinin kırılması genellikle pasif içerikten, sayfanın işlevsel olarak bozulması ise aktif içeriğin engellenmesinden kaynaklanır. Her iki durumda da kalıcı çözüm aynıdır — kaynağı http:// yerine https:// üzerinden sunmak. Tarayıcının otomatik yükseltmesine bel bağlamak yanlıştır; çünkü bu davranış tarayıcıdan tarayıcıya ve sürümden sürüme değişir, üstelik yalnızca kaynak zaten HTTPS'te varsa işe yarar.

Konsol ile HTTP Kaynakları Bulmak#

Karışık içeriği çözmenin ilk kuralı: tahmin etmeyin, bulun. En hızlı, en güvenilir ve hiçbir araç gerektirmeyen yöntem tarayıcının kendi geliştirici konsoludur. Sorunlu sayfayı açın ve F12 (macOS'ta Cmd+Option+I) ile geliştirici araçlarını açın.

Console sekmesi ilk durağınız olsun. Karışık içerik varsa, sayfa yüklenirken sarı ya da kırmızı renkte "Mixed Content" ile başlayan satırlar dökülür. Her satır size tam olarak hangi kaynağın HTTP üzerinden çağrıldığını, tam adresiyle söyler. Genellikle iki üç farklı domainin (kendi siteniz, eski bir CDN, üçüncü taraf bir servis) tekrar tekrar geçtiğini görürsünüz; bu, sorunun kaynağını daraltır.

Daha sistematik bir yol Network (Ağ) sekmesidir. Sekmeyi açık tutarak sayfayı yenileyin, ardından filtre kutusuna basit bir şekilde http:// yazamazsınız ama isteklerin protokolünü sütunlardan görebilirsiniz. Firefox'ta Network panelinde güvensiz istekler ayrıca bir kilit-kırık simgesiyle işaretlenir. Böylece her bir güvensiz kaynağı, boyutunu ve nereden çağrıldığını tek listede görürsünüz.

Sunucuya SSH erişiminiz varsa, sitenin ham HTML çıktısında http:// bağlantılarını komut satırından da avlayabilirsiniz. Bu, özellikle onlarca sayfayı hızla taramak için pratiktir:

# Tek bir sayfanın HTML'inde http:// ile başlayan kaynak bağlantılarını listele
curl -s https://alanadi.com/ | grep -oE '(src|href)="http://[^"]+"' | sort -u

Çıktı size hangi src ve href özniteliklerinin hâlâ http:// ile başladığını temiz bir liste hâlinde verir. Aynı yaklaşımı bir dosya ağacında çalıştırarak tema veya şablon dosyalarına gömülü sabit bağlantıları da bulabilirsiniz:

# Tema/şablon dosyalarında sabit http:// bağlantılarını ara
grep -rniE 'http://(www\.)?alanadi\.com' /var/www/alanadi.com/wp-content/themes/

Konsolda bir kaynak "blocked" (engellendi) diyorsa aktif içerikle, "upgraded" ya da yalnızca uyarıyla geçiyorsa pasif içerikle uğraştığınızı hemen anlarsınız. Listeyi çıkardıktan sonra iş, bu adresleri tek tek HTTPS'e taşımaya kalır. Eğer konsolda karışık içerikten bağımsız, doğrudan sertifikaya ait "NET::ERR_CERT" türü hatalar da görüyorsanız, bunlar ayrı bir konudur; onları SSL hatalarının çözümü yazımızda ele aldık.

Why No Padlock ve Diğer Tarama Araçları#

Siteye teknik erişiminiz yoksa ya da her sayfayı tek tek gezmeden bütüncül bir rapor istiyorsanız, çevrimiçi tarayıcılar devreye girer. Bunların en bilineni Why No Padlock (whynopadlock.com) adlı ücretsiz araçtır. Alan adınızı girersiniz, araç sayfayı sunucu tarafında yükler ve kilidin neden çıkmadığını maddeler hâlinde raporlar: hangi kaynağın güvensiz olduğu, hangi öğenin (görsel mi, betik mi) sorun çıkardığı ve tam URL'si listelenir.

Why No Padlock'un güçlü yanı, size teknik jargon yerine sade bir "şu görsel HTTP, şu iframe HTTP" listesi vermesidir. Ancak sınırı da vardır: yalnızca girdiğiniz tek bir URL'yi tarar. Sitenizin ana sayfası temizken bir blog yazısı ya da ürün sayfası karışık içerik barındırıyorsa, o sayfanın adresini ayrıca girmeniz gerekir. Bu yüzden aracı, sorunun türünü hızlıca anlamak için bir başlangıç noktası olarak kullanın; kapsamlı temizlik için konsol ve toplu yöntemlerle birleştirin.

Site genelini tek seferde taramak istiyorsanız birkaç seçenek daha vardır. JitBit SSL Check ya da benzeri tarayıcılar, siteyi bir örümcek (crawler) gibi gezerek birden fazla sayfadaki güvensiz kaynakları toplu raporlar. Chrome/Firefox eklentileri arasında da karışık içeriği vurgulayan araçlar bulunur. Bunların hepsinin ortak amacı aynıdır: sizin gözünüzle fark edemeyeceğiniz, sayfanın derinlerine gömülü tek bir http:// bağlantısını ortaya çıkarmak.

Aşağıdaki tablo, hangi durumda hangi aracın daha uygun olduğunu özetler:

Hangi aracı seçerseniz seçin, elinizde sonunda bir "güvensiz kaynaklar listesi" olmalıdır. Çözüm bölümüne ancak bu listeyle geçin; kör düzeltme, çoğu zaman gerçek suçluyu atlar.

WordPress'te Mixed Content Çözümü#

WordPress, karışık içeriğin en sık görüldüğü platformdur çünkü içerik, görsel ve tema ayarlarındaki bağlantıları tam URL olarak veritabanına yazar. Yıllarca HTTP ile çalışan bir sitede binlerce satır http://alanadi.com/... bağlantısı birikmiştir. Bunları temizlemenin doğru sırası önce site adreslerini, sonra gövdedeki bağlantıları güncellemektir.

İlk adım, WordPress'in kendi adres ayarlarını HTTPS'e çevirmektir. Yönetici panelinde Ayarlar → Genel ekranından "WordPress Adresi (URL)" ve "Site Adresi (URL)" alanlarını https://alanadi.com yapın. Panele erişemiyorsanız aynısını doğrudan veritabanından yapabilirsiniz:

UPDATE wp_options SET option_value = 'https://alanadi.com'
WHERE option_name IN ('siteurl', 'home');

Asıl kritik iş, içerik gövdesindeki gömülü bağlantıları düzeltmektir. Burada bir tuzak vardır: WordPress birçok ayarı (özellikle tema seçenekleri ve sayfa oluşturucu verileri) serileştirilmiş (serialized) biçimde saklar. Bu alanlarda ham bir SQL REPLACE çalıştırırsanız, dize uzunluğu bilgileri bozulur ve o ayarlar tamamen kaybolabilir. Bu yüzden basit yazı gövdeleri için SQL kullanılabilir, ama site geneli için serileştirmeye duyarlı bir araç şarttır.

Yalnızca yazı içeriğindeki düz bağlantılar için SQL güvenlidir:

UPDATE wp_posts
SET post_content = REPLACE(post_content, 'http://alanadi.com', 'https://alanadi.com');

Site genelinde güvenli, serileştirme farkında bir değişim için en iyi yol WP-CLI'nin search-replace komutudur. --precheck niteliğiyle önce bir prova (dry-run) yapıp kaç satırın değişeceğini görün, sonra gerçek işlemi çalıştırın:

# Önce prova: hiçbir şey değiştirmeden kaç kayıt etkilenecek göster
wp search-replace 'http://alanadi.com' 'https://alanadi.com' --dry-run

# Onayladıktan sonra gerçek değişim (serialize verileri güvenle işler)
wp search-replace 'http://alanadi.com' 'https://alanadi.com' --all-tables --report-changes-only

WP-CLI yoksa aynı işi Better Search Replace eklentisi yapar; o da serileştirilmiş veriyi doğru işler ve önce bir kuru çalıştırma sunar. Kolaylık isteyenler için Really Simple SSL eklentisi site adreslerini günceller, bağlantıları yeniden yazar ve kalan karışık içeriği çalışma anında düzeltmeye çalışır — ancak bu son madde her sayfa isteğinde küçük bir işlem yükü ekler; yüksek trafikli sitelerde nihai çözüm, bağlantıları veritabanında kalıcı düzeltip eklentiyi devreden çıkarmaktır.

Hangi yöntemi seçerseniz seçin, işlemden önce mutlaka bir yedek alın; veritabanı üzerinde toplu değişiklik geri alınması zor bir adımdır. WordPress bakımını kendiniz üstlenmek istemiyorsanız, bu tür HTTPS geçişlerini ve düzenli kontrolleri WordPress hosting paketlerimiz ile WordPress bakım hizmetimiz kapsamında sizin yerinize yürütebiliriz.

upgrade-insecure-requests ile Toplu Çözüm#

Bağlantıların tamamını tek tek bulup düzeltmek her zaman mümkün olmaz — özellikle içerik çok eskiyse ya da kaynaklar kontrol edemediğiniz eklentilerden geliyorsa. İşte burada güçlü bir güvenlik başlığı devreye girer: Content-Security-Policy: upgrade-insecure-requests. Bu direktif tarayıcıya şunu söyler: "Bu sayfada bulduğun her http:// kaynağını, istek atmadan önce otomatik olarak https:// ile dene." Yani tarayıcı, gövdedeki bağlantıyı fiziksel olarak değiştirmeden, çalışma anında güvenli sürümünü ister.

Başlığı sunucu düzeyinde eklemek en temiz yoldur. Apache kullanıyorsanız .htaccess dosyanıza şu satırı ekleyin:

Header always set Content-Security-Policy "upgrade-insecure-requests"

Nginx tarafında, HTTPS sunucu bloğunun içine:

add_header Content-Security-Policy "upgrade-insecure-requests" always;

Sunucu yapılandırmasına erişemeyen kullanıcılar aynı etkiyi sayfanın <head> bölümüne bir meta etiketiyle de sağlayabilir (örneğin WordPress'te tema başlığına eklenerek):

<meta http-equiv="Content-Security-Policy" content="upgrade-insecure-requests">

Bu başlığın büyük avantajı, tek satırla sitenizdeki tüm dahili karışık içeriği anında güvenli hâle getirmesidir. Ancak sınırlarını bilin. İlk olarak, yükseltme yalnızca kaynak HTTPS'te de mevcutsa işe yarar; http:// adresindeki dosya HTTPS'te yoksa istek yine başarısız olur, çünkü başlık adresi değiştirir ama olmayan bir dosyayı var etmez. İkincisi, upgrade-insecure-requests bir yara bandıdır, tedavi değil. Veritabanınızdaki bağlantılar hâlâ http:// olarak durur; başlığı bir gün kaldırırsanız sorun geri gelir. Bu yüzden en sağlıklı yaklaşım, önce bağlantıları veritabanında kalıcı olarak düzeltmek, ardından upgrade-insecure-requests başlığını bir güvenlik ağı olarak açık bırakmaktır — böylece ileride gözden kaçan yeni bir HTTP bağlantısı da otomatik olarak yakalanır.

Bir noktaya dikkat: Content-Security-Policy başlığını daha geniş güvenlik kurallarıyla birlikte kullanıyorsanız, upgrade-insecure-requests direktifini mevcut politikanıza eklemeyi unutmayın; ayrı bir başlık ikinci bir CSP tanımı olarak çakışabilir. Sunucu tarafı güvenlik başlıklarını ve WAF katmanını profesyonel yönetmek isterseniz WAF çözümlerimiz ve SSL hizmetlerimiz bu yapılandırmayı sizin adınıza standartlaştırır.

Sıkça Sorulan Sorular#

Mixed content hatası siteme zarar verir mi?#

Doğrudan sitenizi çökertmez ama iki gerçek zararı vardır. Birincisi güvenliktir: aktif karışık içerik (HTTP ile gelen bir betik) aradaki bir saldırgan tarafından değiştirilerek sayfanıza kötü amaçlı kod enjekte edilebilir, yani HTTPS'in koruması fiilen delinir. İkincisi kullanıcı güvenidir: tarayıcı kilidi kırar, "güvenli değil" uyarısı gösterir ve ziyaretçiler özellikle formu ya da ödemesi olan sayfalarda tereddüt eder. Ayrıca aktif kaynaklar engellendiğinde sitenizin bir kısmı çalışmaz hâle gelir.

Görsellerim geliyor ama kilit yine de çıkmıyor, neden?#

Bu klasik pasif karışık içerik belirtisidir. Görselleriniz <img> etiketiyle geldiği için tarayıcı onları yükler ya da otomatik HTTPS'e yükseltir, fakat sayfada http:// ile çağrılan en az bir kaynak kaldığı için kilidi yine de kırar. F12 ile konsolu açıp "Mixed Content" satırlarına bakın; orada tam olarak hangi görsel, font veya arka plan görselinin hâlâ HTTP olduğunu göreceksiniz. O adresi HTTPS'e çevirdiğinizde kilit tamamlanır.

upgrade-insecure-requests kullanırsam bağlantıları düzeltmeme gerek kalır mı?#

Kalıcı çözüm için yine de düzeltmelisiniz. Bu başlık, tarayıcının çalışma anında her HTTP kaynağını HTTPS ile denemesini sağlar; pratik ve hızlı bir kurtarıcıdır, ama veritabanınızdaki bağlantılar hâlâ http:// olarak durur. Başlığı bir gün kaldırırsanız ya da kaynak HTTPS'te mevcut değilse sorun geri döner. En sağlıklı yol, bağlantıları veritabanında kalıcı düzeltip upgrade-insecure-requests başlığını gözden kaçan yeni bağlantılar için bir güvenlik ağı olarak açık tutmaktır.

Sorun üçüncü taraf bir kaynaktan geliyorsa ne yapmalıyım?#

Önce o kaynağın HTTPS sürümünü deneyin; günümüzde ciddi sağlayıcıların neredeyse tamamı https:// adres sunar, çoğu zaman http://yi https:// yapmak yeterlidir. Sağlayıcı HTTPS desteklemiyorsa iki seçeneğiniz vardır: HTTPS destekleyen bir alternatifle değiştirmek ya da o kaynağı (örneğin bir görsel veya fontu) kendi sunucunuza indirip yerel olarak HTTPS üzerinden sunmak. Güvensiz kalmakta ısrar eden bir üçüncü taraf betiği asla HTTP ile bırakmayın; aktif içerik olduğu için tarayıcı zaten engelleyecek ve o işlev çalışmayacaktır.

WordPress'te SQL ile toplu değiştirme yapmak güvenli mi?#

Kısmen. Yalnızca wp_posts gibi düz metin gövdelerinde ham SQL REPLACE güvenlidir. Ancak WordPress tema ayarlarını ve sayfa oluşturucu verilerini serileştirilmiş (serialized) biçimde saklar; bu alanlarda ham SQL çalıştırmak dize uzunluğu bilgisini bozarak ayarları kaybettirebilir. Site geneli için WP-CLI'nin search-replace komutunu ya da Better Search Replace eklentisini kullanın; ikisi de serileştirmeye duyarlıdır. Her koşulda işlemden önce mutlaka bir veritabanı yedeği alın.

Kilit hâlâ çıkmıyor, her şeyi kontrol ettim; başka nereye bakmalıyım?#

Sık atlanan üç yer vardır. Birincisi CSS içindeki background-image: url(http://...) tanımlarıdır; bunlar HTML'de görünmez, konsolda ise pasif içerik olarak geçer. İkincisi yönetici panelindeki widget'lar, favicon ve gömülü harita/video iframe'leridir. Üçüncüsü tarayıcı önbelleğidir; düzeltmeyi yaptıktan sonra bir gizli (incognito) sekmede veya önbelleği temizleyip test edin. Yine de bulamıyorsanız Why No Padlock ile bir tam URL taratmak, gözden kaçan tek kaynağı çoğu zaman ortaya çıkarır.

Kapanış#

Mixed content, ilk bakışta ürkütücü görünen ama aslında tek bir mantığa dayanan bir sorundur: HTTPS bir sayfada, güvenlik ancak içindeki her kaynak da HTTPS ile gelirse tamamlanır. Çözüm bu yüzden her zaman aynı iki adıma iner — önce güvensiz kaynakları konsol veya Why No Padlock ile eksiksiz bulmak, sonra onları kalıcı olarak https:// üzerinden sunmak. WordPress'te bu iş çoğunlukla site adreslerini güncellemek ve WP-CLI ile bağlantıları toplu düzeltmekten ibarettir; upgrade-insecure-requests başlığı ise gözden kaçanları yakalayan güvenilir bir emniyet ağıdır.

Karışık içerikle her yeni içerik ekledikçe tek tek uğraşmak yerine, altyapınızı baştan HTTPS'e uygun kurmak en kalıcı çözümdür. Clou.TR'de ücretsiz SSL, tek tık HTTPS yönlendirmesi ve karışık içeriği daha ortaya çıkmadan yakalayan güvenlik başlıkları hosting paketlerimizde hazır gelir. Sitenizi güvenle taşımak, sertifikayı kurmak ve o yeşil kilidi kalıcı hâle getirmek için SSL çözümlerimizi ve WordPress hosting seçeneklerimizi inceleyerek dakikalar içinde başlayabilirsiniz.