SSL Sonrası Mixed Content ve Güvensiz İçerik Hatalarını Düzeltmek

SSL Sonrası Mixed Content Sorununu Doğru Teşhis Etmek

HTTP’den HTTPS’e geçiş yaptıktan sonra tarayıcı adres çubuğunda beklediğiniz kilit simgesi yerine uyarı işareti, konsolda ise mixed content ve güvensiz içerik hataları görüyorsanız yalnız değilsiniz. Özellikle WordPress, özel yazılmış PHP siteler ve CDN kullanan projelerde bu sorunları neredeyse her hafta DCHost tarafında gelen destek taleplerinde görüyoruz. İyi haber şu: Bu hataların tamamı çözülebilir ve çoğu durumda kalıcı şekilde önlenebilir.

Bu yazıda mixed content hatasının ne olduğunu, neden oluştuğunu ve WordPress, PHP ve CDN senaryolarında adım adım nasıl temizlenebileceğini pratik örneklerle anlatacağız. Ayrıca .htaccess / Nginx yönlendirmeleri, HTTP güvenlik başlıkları (HSTS, CSP, upgrade-insecure-requests) ve tarayıcı geliştirici araçlarını birlikte kullanarak sorunu nasıl hem teşhis edip hem de kalıcı olarak çözebileceğinizi göreceksiniz. Eğer sitenizi henüz yeni HTTPS’e taşıdıysanız, HTTP’den HTTPS’e geçişte 301, HSTS ve SEO dengesini anlattığımız rehberi de bu yazıyla birlikte okumanızı öneririz.

Mixed Content Nedir, Neden Oluşur?

Mixed content, sayfanız HTTPS üzerinden yüklenirken içindeki bazı kaynakların (görsel, CSS, JS, font, iframe vb.) HTTP üzerinden çağrılması durumudur. Tarayıcı açısından bu, güvenli bir sayfa içine güvensiz parçalar gömülmesi anlamına gelir.

Temelde iki tür mixed content vardır:

• Pasif içerik (mixed display content): Görseller, videolar gibi sayfanın görünümünü etkileyen ama doğrudan kod çalıştırmayan içerikler. Modern tarayıcılar bunların çoğunu da engelliyor veya en azından uyarı veriyor.
• Aktif içerik (mixed active content): JavaScript dosyaları, iframe içindeki uygulamalar, bazı CSS dosyaları gibi sayfanın davranışını değiştirebilen içerikler. Güvenlik riski daha yüksek olduğu için tarayıcılar genelde bunları tamamen blokluyor.

Mixed content genellikle şu durumlarda ortaya çıkar:

• Siteniz HTTPS’e taşınır ama veritabanında veya kod içinde eski http URL’ler kalır.
• Tema veya eklentilerde statik olarak http ile yazılmış kaynak adresleri vardır.
• CDN veya statik dosya alan adınız için HTTPS tam olarak etkin değildir.
• Reverse proxy veya CDN arkasındaki PHP uygulaması, isteğin HTTPS olduğunu doğru algılamıyordur.

Mixed Content Hatalarını Neden Ciddiye Almalısınız?

Birçok kullanıcı kilit simgesini gördüğünde siteye güveniyor, görmediğinde ise ödeme adımlarında geri dönüyor. Mixed content sorunlarını hızlıca çözmenizi gerektiren başlıca nedenler:

• Tarayıcı uyarıları: Chrome, Firefox, Safari gibi tarayıcılar Not Secure (Güvenli değil) ibaresi, uyarı simgeleri ve konsolda kırmızı hatalar gösteriyor.
• Form ve ödeme güvenliği: Form verileri ve ödeme bilgileri teorik olarak HTTPS ile korunuyor olsa bile tarayıcı, sayfayı karma içerik nedeniyle riskli kabul ediyor.
• SEO etkisi: Google uzun süredir HTTPS’i sıralama faktörü olarak kullanıyor. Güvensiz / yarı güvenli sayfalar, özellikle e-ticaret ve kurumsal siteler için olumsuz sinyal oluşturabiliyor. Bu konuyu daha geniş çerçevede domain, DNS, sunucu ve SSL’in birlikte çalışma mantığını anlattığımız yazıda detaylandırdık.
• Güvenlik başlıkları ile çelişme: HSTS, CSP, upgrade-insecure-requests gibi modern güvenlik önlemleri mixed content ile birlikte doğru çalışmaz veya beklemediğiniz yan etkiler doğurur.

Mixed Content Hatalarını Tespit Etme Yöntemleri

Tarayıcı Geliştirici Araçları

İlk adım her zaman tarayıcı tarafında teşhistir:

1. Chrome veya Firefox ile sitenizi açın.
2. Sağ tıklayıp Inspect / İncele deyin.
3. Console (Konsol) sekmesine geçin.
4. Mixed content veya Güvensiz içerik ile ilgili kırmızı/sarı uyarıları inceleyin.

Genellikle şu tip mesajlar görürsünüz:

• Mixed Content: The page at ‘https://siteadiniz.com’ was loaded over HTTPS, but requested an insecure image ‘http://…’
• Mixed Content: This request has been blocked; the content must be served over HTTPS.

Bu mesajlar size tam olarak hangi kaynağın (görsel, CSS, JS) hangi URL’den http olarak yüklendiğini gösterir. Makalenin devamında yapacağımız tüm düzeltmeleri bu listeye bakarak adım adım doğrulayacağız.

Ağ Sekmesi ve Kaynak Filtreleme

Network (Ağ) sekmesinde istekleri protokole göre filtreleyerek http ile gelenleri görebilirsiniz:

1. Network sekmesine geçin, sayfayı yenileyin.
2. Domain sütununda http ile başlayan istekleri bulun.
3. Türüne göre (image, script, stylesheet, font) gruplandırarak hangi tür kaynaklarda sorun olduğunu not alın.

Sunucu ve Panel Tarafı Loglar

Özellikle büyük projelerde, tarayıcı ile tek tek sayfa gezmek zahmetli olabilir. Bu durumda:

• Web sunucu loglarında http ile başlayan istekleri arayabilir,
• Uygulama loglarına basit bir filtre ekleyerek gelen URL’lerde http kullanımını yakalayabilir,
• WordPress veya PHP uygulamanızda geçici bir loglama ile oluşturulan mutlak URL’leri analiz edebilirsiniz.

Genel SSL problemlerini daha geniş bir perspektiften ele aldığımız SSL sertifika hataları rehberi makalesi de tarayıcı uyarılarını okuma konusunda işinizi kolaylaştıracaktır.

WordPress Sitelerde Mixed Content Hatalarını Temizlemek

1. Site Adresi (URL) Ayarlarını Kontrol Edin

WordPress’te en kritik adım, site URL’lerinin HTTPS’e tam olarak geçmesidir:

• Yönetim paneline giriş yapın.
• Ayarlar > Genel menüsüne gidin.
• ‘WordPress adresi (URL)’ ve ‘Site adresi (URL)’ alanlarının her ikisinin de https ile başladığından emin olun.

Eğer bu alanlara erişemiyorsanız veya gri görünüyorsa, muhtemelen wp-config.php içinde şu sabitler tanımlıdır:

<?php
define('WP_HOME', 'http://siteadiniz.com');
define('WP_SITEURL', 'http://siteadiniz.com');
?>

Bunları https’e çevirin:

<?php
define('WP_HOME', 'https://siteadiniz.com');
define('WP_SITEURL', 'https://siteadiniz.com');
?>

Değişiklikten sonra önbelleği temizleyip (varsa cache eklentisi ve CDN cache) sayfayı yenileyin, konsolu tekrar kontrol edin.

2. Veritabanında http -> https Dönüşümü

Eski yazılar, sayfalar, menüler, widget’lar, shortcoder ve Gutenberg blokları içinde http ile başlayan mutlak linkler kalmış olabilir. Bunları veritabanı seviyesinde temizlemek gerekir. İşleme başlamadan önce mutlaka tam bir yedek alın. cPanel kullanıyorsanız cPanel’de tam site yedeği alma rehberimize göz atabilirsiniz.

En basit yaklaşım, bir arama-değiştirme aracıyla şu dönüşümleri yapmaktır:

• http://siteadiniz.com → https://siteadiniz.com
• http://www.siteadiniz.com → https://www.siteadiniz.com (varsa)

WordPress veritabanı seri hale getirilmiş (serialized) veriler içerdiği için, doğrudan SQL ile replace yapmak risklidir. Bu yüzden:

• WordPress’e özel arama-değiştirme araçları veya WP-CLI kullanan skriptler tercih edilmeli,
• Önce staging veya test ortamında denenmeli,
• İşlem sonrası özellikle wp_options ve wp_postmeta içeriği spot kontrollerle kontrol edilmelidir.

Staging ortamı kurmak ve değişiklikleri canlıya almadan önce test etmek için paylaşımlı hosting’de WordPress staging ortamı kurma rehberimizi kullanabilirsiniz.

3. Tema ve Eklentilerde Hard-Coded HTTP Kaynakları

Bazı eski temalar ve eklentiler, özellikle CSS, JS ve font dosyalarını sabit http adresiyle çağırır. Örneğin:

<link rel='stylesheet' href='http://cdn.ornek.com/style.css'>

Bunları tespit etmek için:

• Tema klasörünüzü (genellikle wp-content/themes/tema-adi) açın.
• http:// ifadesini tüm dosyalarda arayın.
• Benzer şekilde wp-content/plugins içinde de arama yapın.

Mümkünse:

• Kaynakları https ile düzeltin,
• Şemadan bağımsız (protocol-relative) kullanın: //cdn.ornek.com/style.css,
• Veya WordPress fonksiyonlarıyla dinamik üretin: get_template_directory_uri(), plugins_url() vb.

4. WordPress + CDN Senaryosunda Mixed Content

WordPress sitelerde CDN kullanırken mixed content yaşanmasının yaygın nedenleri:

• CDN alan adının yalnızca http ile yapılandırılmış olması,
• CDN sertifikasının eksik ya da hatalı olması,
• Temada CDN adresinin http ile sabitlenmiş olması,
• CDN’ye taşınmayan bazı dosyaların hala origin üzerinden http ile çağrılması.

Çözüm için:

1. CDN sağlayıcınızda kullandığınız alan adının (örneğin cdn.siteadiniz.com) mutlaka geçerli bir SSL sertifikası ile çalıştığından emin olun.
2. WordPress CDN ayarlarınızda tüm URL’leri https olarak tanımlayın.
3. Tema dosyalarında doğrudan yazılmış CDN URL’lerini https veya şema bağımsız hale getirin.
4. CDN cache’ini tamamen temizleyip sayfayı yenileyin.

CDN kullanımının performansa etkilerini ve ne zaman mantıklı olduğunu CDN nedir, ne zaman gerekir rehberimizde ayrıntılı anlattık. Ayrıca CDN ile önbellek ve cache-control başlıklarını doğru kullanmak için tarayıcı ve CDN önbelleklemenin önemi yazısı da işinize yarayacaktır.

Özel Yazılmış PHP Sitelerde Mixed Content Çözümleri

1. Temel Base URL / Config Ayarları

Özel yazılmış PHP uygulamalarda genellikle bir config.php veya .env dosyasında base URL bulunur:

$config['base_url'] = 'http://siteadiniz.com/';

HTTPS’e geçtikten sonra bunu:

$config['base_url'] = 'https://siteadiniz.com/';

şeklinde güncellemeniz gerekir. Eğer uygulama, tüm linkleri ve statik dosya yollarını bu base_url üzerinden üretiyorsa, mixed content’in büyük kısmı burada çözülecektir.

2. Kod İçinde Mutlak HTTP URL’leri Temizlemek

Kod tabanınızda doğrudan http ile başlayan URL’ler olabilir:

<img src='http://siteadiniz.com/uploads/resim.jpg'>
<script src='http://cdn.siteadiniz.com/app.js'></script>

Adımsal çözüm:

• Proje klasöründe http://siteadiniz.com ve http://www.siteadiniz.com ifadelerini arayın.
• Bunları https’e çevirin veya base URL fonksiyonlarınızla dinamik hale getirin.
• Mutlak URL yerine mümkün olduğunda göreli URL (/uploads/resim.jpg) kullanmayı tercih edin.

3. Reverse Proxy ve X-Forwarded-Proto Sorunları

PHP uygulamanız bir CDN veya reverse proxy (örneğin önünde bir HTTP yük dengeleyici) arkasında çalışıyorsa, uygulama gelen isteğin HTTPS olduğunu doğru algılamayabilir. Bu durumda:

• $_SERVER['HTTPS'] boş gelebilir,
• $_SERVER['SERVER_PORT'] 80 görünebilir,
• Uygulama URL üretirken http kullanmaya devam eder.

Çözüm için:

• Proxy sunucusunda X-Forwarded-Proto: https başlığını ilettiğinizden emin olun.
• PHP veya framework katmanında bu başlığı kontrol edip HTTPS’i zorlayın.
• Nginx veya Apache tarafında uygun set_real_ip_from / RemoteIPHeader ayarları yapın.

Bu tür senaryolar özellikle çok katmanlı mimarilerde ve ayrı frontend + API sunucusu kullanan yapılarda sık görülür. Bu tip mimarileri SPA + API aynı alan adında Nginx yönlendirme ve SSL mimarisi yazımızda ayrıntılı olarak ele aldık.

CDN Senaryolarında Güvensiz İçerik ve Özel Durumlar

1. Farklı Alan Adlarında Statik İçerik

Birçok projede asıl site adresi ile statik içerik alan adı ayrılır:

• Uygulama: https://www.siteadiniz.com
• Statik / CDN: https://static.siteadiniz.com veya https://cdn.siteadiniz.com

Eğer CDN alan adınız için SSL tam kurulu değilse veya kod içinde hala http://cdn.siteadiniz.com kullanılıyorsa, tarayıcı bu istekleri güvensiz kabul eder. Yapmanız gerekenler:

• CDN alan adınız için geçerli bir SSL sertifikası kurmak (DV, Wildcard vb.),
• Origin sunucunuzun da HTTPS ile sağlıklı yanıt verdiğinden emin olmak,
• Uygulama konfigurasyonunda tüm CDN URL’lerini https’e çevirmek.

2. upgrade-insecure-requests ile Geçici Yamalar

CSP (Content Security Policy) içinde upgrade-insecure-requests yönergesini kullanarak tarayıcıya http ile çağrılan kaynakları otomatik olarak https’e yükseltmesini söyleyebilirsiniz:

Content-Security-Policy: upgrade-insecure-requests;

Bu, özellikle yüzlerce içerik içeren büyük sitelerde geçici bir güvenlik filesi gibi işe yarar, ancak tek başına kalıcı çözüm değildir:

• Eski içerikleriniz hala http ile kayıtlı kalır.
• CDN veya üçüncü parti servisleriniz https desteklemiyorsa sorun devam eder.
• Uzun vadede veritabanı ve kod tarafında gerçek temizlik yapılması gerekir.

CSP ve diğer HTTP güvenlik başlıklarını daha geniş bir çerçevede ele aldığımız HTTP güvenlik başlıkları rehberimiz ve CSP üzerinde derinleşmek için CSP’yi doğru kurmak üzerine yazımız mixed content ile birlikte düşünülmesi gereken ayarları detaylandırıyor.

.htaccess, Nginx ve HSTS ile HTTPS Zorunlu Hale Getirmek

1. HTTP’den HTTPS’e Yönlendirme

Mixed content temizliğinin yanında, tüm trafiği HTTPS’e zorlayan bir yönlendirme kuralı kullanmalısınız. Apache için tipik bir .htaccess kuralı:

RewriteEngine On
RewriteCond %{HTTPS} !=on
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

Nginx için örnek:

server {
    listen 80;
    server_name siteadiniz.com www.siteadiniz.com;
    return 301 https://$host$request_uri;
}

Bu kurallar, HTTP isteklerini kalıcı olarak HTTPS’e yönlendirir. Özellikle SEO tarafında 301 yönlendirmelerin doğru kurulması önemlidir; bu konuyu htaccess ve Nginx 301 yönlendirme rehberimizde detaylı anlattık.

2. HSTS (HTTP Strict Transport Security)

Mixed content temizliğiniz büyük ölçüde bittikten sonra, HSTS başlığı ile tarayıcıya sadece HTTPS üzerinden bağlanmasını söyleyebilirsiniz:

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

HSTS şunları sağlar:

• Tarayıcı, aynı alan adına yapılan sonraki tüm istekleri otomatik olarak HTTPS’e yükseltir.
• Ortadaki adam (MITM) saldırılarını zorlaştırır.
• Yanlışlıkla http link bıraksanız bile tarayıcı tarafında bir güvenlik katmanı eklenmiş olur.

Ancak HSTS etkinleştirmeden önce:

• Tüm alt alan adlarınızın HTTPS ile sorunsuz çalıştığından emin olun.
• Mixed content hatalarının büyük kısmını temizlemiş olun.
• Geri dönüşü zor bir adım olduğunu bilerek ilerleyin (özellikle preload listesine başvurursanız).

Gerçekçi Senaryolar: Adım Adım Çözüm Örnekleri

Senaryo 1: Küçük E-Ticaret Sitesi (WordPress + WooCommerce)

Durum:

• Site Let’s Encrypt SSL ile HTTPS’e geçiyor.
• Ürün sayfalarında görseller çıkmıyor, konsolda mixed content hataları var.

Çözüm adımları:

1. WordPress ve Site adresi ayarlarını https olarak düzeltme.
2. Veritabanında http://siteadiniz.com ifadelerini HTTPS’e dönüştürme.
3. Tema içindeki sabit http görsel yollarını dinamik fonksiyonlarla değiştirme.
4. Önbellek eklentisi + CDN cache temizliği.
5. HSTS başlığını dikkatli bir şekilde etkinleştirme.

Senaryo 2: Kurumsal PHP Tanıtım Sitesi (Özel Yazılım)

Durum:

• SSL kurulu, anasayfa kilit simgeli görünüyor.
• Hakkımızda sayfasında fontlar yüklenmiyor, tasarım bozulmuş.

Çözüm adımları:

1. Tarayıcı konsolunda mixed content hatalarının hangi kaynaklara işaret ettiğini tespit etmek.
2. Genellikle http://fonts.siteadiniz.com gibi sabit adresleri https’e çevirmek.
3. Base URL tanımını https’e güncellemek.
4. Gerekirse CSP içinde upgrade-insecure-requests ekleyerek geçiş dönemini konforlu hale getirmek.

Senaryo 3: CDN Arkasında Yüksek Trafikli Blog

Durum:

• Statik dosyalar CDN üzerinden geliyor.
• Bazı eski yazılardaki görseller direkt http ile embed edilmiş.

Çözüm adımları:

1. Veritabanında eski http alan adlarını https’e dönüştürmek.
2. CDN alan adının SSL yapılandırmasını doğrulamak.
3. CDN cache politikalarını gözden geçirip tüm içeriği yeniden ısıtmak.
4. CSP ile upgrade-insecure-requests ekleyerek kalan köşeleri yakalamak.

DCHost Altyapısında Mixed Content Riskini Azaltmak İçin Neler Yapıyoruz?

DCHost olarak paylaşımlı hosting, VPS, dedicated ve colocation hizmetlerimizi tasarlarken SSL ve HTTPS’i artık varsayılan kabul ediyoruz. Bu nedenle:

• Kontrol panellerinde (cPanel, DirectAdmin vb.) Let’s Encrypt veya benzeri ACME tabanlı otomatik SSL kurulumunu destekliyoruz.
• HTTP/2 ve HTTP/3 desteği ile TLS üzerindeki performans kaybını en aza indiriyoruz. Bu konunun SEO ve hız tarafındaki etkilerini HTTP/2 ve HTTP/3 rehberimizde detaylıca anlattık.
• SSL yenilemelerini otomatikleştiren ve sertifika süresi dolmadan uyarı veren altyapılar kullanıyoruz. Birden fazla alan adı için otomasyon stratejileriyle ilgileniyorsanız çoklu SSL yenileme stratejisi yazımıza göz atabilirsiniz.
• Güvenlik odaklı müşterilerimiz için HTTP güvenlik başlıkları, HSTS, CSP ve WAF kuralları konusunda danışmanlık sunuyoruz.

Özetle, altyapı tarafında HTTPS’i sorunsuz ve performanslı hale getirirken, uygulama tarafındaki mixed content kaynaklı sorunları tespit etmeniz ve temizlemeniz için de yanında olduğumuz bir yaklaşımı benimsiyoruz.

Sonuç: Kalıcı Bir Mixed Content Temizlik Yol Haritası

SSL sonrası mixed content ve güvensiz içerik hataları, ilk bakışta karmaşık görünse de aslında üç temel adımın karışımından ibaret: doğru yönlendirmeler, temiz veritabanı/kod ve sağlam güvenlik başlıkları. Önce tarayıcı konsolunda hangi kaynakların http ile geldiğini tek tek tespit edip listeleyin. Ardından WordPress veya PHP uygulamanızda base URL ve veritabanı içeriğini HTTPS’e taşıyın, tema/eklenti/kod tarafında hard-coded http adresleri temizleyin. Son aşamada ise .htaccess/Nginx yönlendirmelerini, HSTS ve gerekirse CSP ile upgrade-insecure-requests politikasını devreye alarak sistemi sağlamlaştırın.

Eğer bu süreç size karmaşık geliyorsa veya yüksek trafikli bir WordPress, WooCommerce ya da özel PHP uygulaması yönetiyorsanız, DCHost tarafında sunduğumuz domain, hosting, VPS, dedicated sunucu ve colocation çözümleriyle birlikte HTTPS mimarinizi baştan sona planlayabiliriz. Altyapıyı biz üstlenelim; siz de ziyaretçilerinizin tarayıcılarında yalnızca güvenli kilit simgesini ve hızlı yüklenen sayfaları görün.