Karışık İçerik

TL;DR — Karışık içerik, güvenli bir https:// sayfasının görsel, betik veya stil dosyası gibi bir kaynağı güvensiz http:// üzerinden yüklemesidir. Böylece güvenli sayfaya güvensiz parçalar karışır ve HTTPS’in sağladığı koruma zayıflar. Tarayıcılar tehlikeli türleri (betikler, stiller ve iframe’ler) engeller; daha düşük riskli türler (görseller ve medya) için uyarı verir veya bunları HTTPS’e yükseltir. HTTPS geçişinden hemen sonra bir siteyi en sık bozan sorunlardan biridir. Çözüm basittir: her kaynağı https:// üzerinden yükleyin.

Karışık içerik nedir?

Bir siteyi HTTPS’e taşıdığınızda sayfanın kendisi güvenli biçimde yüklenir. Ancak bir sayfa yalnızca HTML’den oluşmaz; görselleri, betikleri, stil dosyalarını, yazı tiplerini, videoları ve bazen başka yerlerden gömülü çerçeveleri de çeker. Bu parçalardan herhangi biri hâlâ düz http:// üzerinden isteniyorsa karışık içerik vardır: güvenli bir sayfa, güvensiz yük taşır.

Google’ın kendi açıklamasındaki tanım şöyledir: “A page has mixed content when its initial HTML is loaded over a secure HTTPS connection, but other resources (such as images, videos, stylesheets, and scripts) are loaded over an insecure HTTP connection.” (Türkçesi: Bir sayfanın ilk HTML’i güvenli bir HTTPS bağlantısıyla, diğer kaynakları ise güvensiz bir HTTP bağlantısıyla yükleniyorsa sayfada karışık içerik vardır.)

Bu önemlidir; çünkü güvensiz parçalar HTTPS’in kapattığı açığı yeniden açar. Ziyaretçi ile sunucu arasındaki ağda bulunan biri bu http:// isteklerini okuyabilir veya değiştirebilir. Dolayısıyla adres çubuğundaki kilit, sayfanın gerçekte sahip olduğundan daha fazla güvenlik vaat etmiş olur.

İki tür ve tarayıcıların bunlara yaklaşımı

Tarayıcılar bütün karışık içerikleri aynı şekilde ele almaz. Güvensiz kaynağın verebileceği zarara göre sınıflandırırlar:

• Etkin karışık içerik — betikler, stil dosyaları ve iframe’ler. Bunlar bütün sayfayı denetleyebilir; değiştirilmiş tek bir kaynak her şeyi yeniden yazabilir. Tarayıcılar bu türü engeller. Geçişten sonra düzeni, etkileşimi veya gömülü bir bileşeni gerçekten bozan tür budur.
• Pasif karışık içerik — görseller, ses ve video. Bunlar sayfayı ele geçiremez. Tarayıcılar geçmişte bunları yükleyip kilit simgesini kaldırır ve “tam güvenli değil” uyarısı gösterirdi. Bu davranış değişiyor; modern tarayıcılar bu kaynakları giderek daha çok HTTPS’e yükseltiyor veya engelliyor.

Karışık içerik olmayan bir örnek: HTTP sayfasına giden normal bir bağlantı (<a href="http://…">). Bu bağlantı yalnızca sizi başka bir yere götürür; güvenli sayfanızın içine güvensiz bir parça yüklemez.

Nasıl düzeltilir?

Çözüm neredeyse her zaman aynıdır: güvensiz kaynağı HTTPS üzerinden yükleyin. Kaynak başvurusundaki http:// değerini https:// olarak değiştirin veya protokolü sabit kodlamayan bir yol kullanın. Çoğu zaman kaynak zaten HTTPS üzerinden mevcuttur; yalnızca bir şablonda, eklentide veya veri tabanında eski bir http:// URL’si kalmıştır.

Kaçırdığınız kaynaklar için bir güvenlik ağı istiyorsanız tek satırlık upgrade-insecure-requests başlığını ekleyebilirsiniz. Bu başlık tarayıcıya, kalan http:// kaynak isteklerini göndermeden önce sessizce https:// biçimine çevirmesini söyler. Güçlü bir yedektir; fakat gerçek kaynakları temizlememek için gerekçe değildir.

Tarayıcıların engellediği kaynakların tam listesini, DevTools konsolu ve CSP raporlarıyla karışık içeriği ölçekte nasıl bulacağınızı, upgrade-insecure-requests ile block-all-mixed-content yönergelerini, CMS’in sorunu neden yeniden ürettiğini ve karışık içeriğin HSTS ile ilişkisini görmek için Gelişmiş sekmesine geçin.

TL;DR — Karışık içerik, bir HTTPS sayfasının HTTP üzerinden alt kaynak yüklemesidir. Güncel tarayıcı/W3C sınıflandırması içeriği yükseltilebilir ve engellenebilir diye ayırır. Eski etkin/pasif ayrımı çoğu kaynak türünde aynı risk sınırını açıklar; ancak CORS etkin görseller, srcset/picture adayları ve IP adresli ana makine istekleri gibi istisnalar vardır. Betik, stil dosyası, iframe ve XMLHttpRequest/fetch gibi etkin kaynaklar engellenir; değiştirilmiş bir betik tüm sayfayı yeniden yazabileceği için önce bunları düzeltin. Görsel, ses ve video gibi pasif kaynaklar geçmişte uyarıyla yüklenirdi; artık giderek daha çok otomatik yükseltilir veya engellenir. Bağlantılar ve diğer üst düzey HTTP gezinmeleri karışık içerik değildir; güvensiz indirmeler de ilişkili fakat ayrı bir sınırdır. Sorunu üç katmanda arayın: getirilen kaynak, işlenmiş/çalışma zamanı durumu ve gerçek kullanıcı oturumları. HTTPS sitesini tarayın, Chrome DevTools konsolunu inceleyin (tam metin tarayıcı ve sürüme bağlıdır) ve Content-Security-Policy-Report-Only ihlallerini toplayın. HTTPS karşılığının gerçekten çalıştığını doğruladıktan sonra her alt kaynağı https:// adresine yöneltin. Göreli veya protokole göreli yollar, ancak sahiplik ve temel URL davranışı doğrulandıysa uygundur; evrensel varsayılan değildir. Content-Security-Policy: upgrade-insecure-requests, farklı kökenlerdekiler dâhil kapsamdaki http:// alt kaynak isteklerini gönderilmeden ve karışık içerik/CSP kontrolleri çalışmadan önce https:// biçimine çevirir. Kaynağı düzeltmenin yerine geçmeyen bir güvenlik ağıdır; yükseltme başarısızsa HTTP’ye dönmez ve üçüncü taraf kökenlere üst düzey gezinmeyi yükseltmediği için HSTS’nin yerini tutmaz. Yönergenin kendisini yalnız raporlama moduna koymak etkisizdir; izleme için ayrı bir raporlama politikası kullanın. CMS veri tabanları (yedek alın, değiştirmeyi deneme modunda çalıştırın; basit metin değiştirme serileştirilmiş veriyi bozabilir), eklentiler, temalar, servis çalışanları/önbellekler ve reklam/analiz etiketleri sorunu yeniden üretebilir. Denetimi sayfa sayfa değil, ölçekte yapın.

HTTPS merkezi, karışık içeriği bir geçişin iki yaygın yayın-günü arızasından biri olarak tanıtır; diğeri yönlendirmelerdir. Bu ayrıntılı rehber kaynak sınıflarını, tespit katmanlarını, CSP yönergelerini ve sorunun neden geri döndüğünü açıklar.

Neler karışık içerik sayılır, neler sayılmaz?

Karışık içeriğin kapsamı nettir: sayfadaki bağlantılar değil, sayfanın yüklediği alt kaynaklar söz konusudur. Google’ın tanımı: “A page has mixed content when its initial HTML is loaded over a secure HTTPS connection, but other resources (such as images, videos, stylesheets, and scripts) are loaded over an insecure HTTP connection.” (Türkçesi: İlk HTML güvenli HTTPS ile, diğer kaynaklar güvensiz HTTP ile yükleniyorsa sayfada karışık içerik vardır.)

Yanlış güven veren tuzak bağlantı etiketidir. HTTP sayfasına giden bir <a href="http://…"> bağlantısı karışık içerik değildir; yeni bir belgeye gider, mevcut güvenli sayfaya güvensiz kaynak yüklemez. Bu, yalnızca bağlantı tıklamaları değil, HTTP sayfasına yapılan tüm üst düzey gezinmeler için geçerlidir.

Yine de dış bağlantıları HTTPS hedeflerine yönlendirmek yararlıdır. Modern tarayıcı varsayılanı Referrer-Policy: strict-origin-when-cross-origin altında HTTPS’ten HTTP’ye tıklama Referer başlığını düşürür ve yönlendirme analizini bozabilir. Ancak bu davranış politikaya ve tarayıcıya bağlıdır, evrensel değildir: sayfa veya üstteki proxy/CDN daha gevşek bir Referrer-Policy ayarlarsa geçişte yine yönlendiren bilgi gönderilebilir. Kayıp miktarını söylemeden önce etkin politikayı denetleyin. Her durumda bu, karışık içeriğin kendisi değil, ayrı bir sorundur.

Etkin ve pasif: öncelikleri belirleyen ayrım

Modern tarayıcı ve W3C belgeleri eski etkin/pasif ayrımı yerine öncelikle yükseltilebilir ve engellenebilir içerikten söz eder: tarayıcının sessizce HTTPS üzerinden yeniden denediği kaynaklarla doğrudan reddettiği kaynaklar. Etkin/pasif ayrımı, tarayıcıların bu sınırı neden çizdiğini — kaynağın sayfanın ne kadarını tehlikeye atabileceğini — açıklamak için hâlâ yararlıdır ve Google’ın açıklaması da bu çerçeveyi kullanır. Ancak belirli kaynak türünün güncel resmî sınıfını ararken bunu tek sınıflandırma saymayın; aşağıdaki istisnalara bakın.

Tarayıcılar karışık içeriği güvensiz kaynağın sayfanın ne kadarını tehlikeye atabileceğine göre sınıflandırır. Google’ın ifadesi: “Active mixed content poses a greater threat than passive mixed content.” (Türkçesi: Etkin karışık içerik, pasif karışık içerikten daha büyük tehdit oluşturur.) Öncelik sırasını bu cümle belirlemeli.

Etkin karışık içerik bütün sayfayla etkileşir ve onu ele geçirebilir. Google bunu “scripts, stylesheets, iframes, and any other code the browser can download and execute” diye açıklar (Türkçesi: tarayıcının indirip çalıştırabildiği betikler, stil dosyaları, iframe’ler ve diğer kodlar). Uygulamadaki liste şudur:

• <script src="http://…"> — en kötü durumdur; araya girilerek değiştirilen betik tüm DOM’u yeniden yazabilir, form verisini dışarı çıkarabilir veya içerik ekleyebilir.
• <link rel="stylesheet" href="http://…"> — CSS her şeyi gizleyebilir, taşıyabilir veya üstünü örtebilir; bu yüzden etkin sayılır.
• <iframe src="http://…"> — güvenli belgenizin içindeki güvensiz gömülü belgedir.
• HTTP’ye XMLHttpRequest / fetch() — sayfanın sonradan işleyeceği güvensiz veridir.
• Web yazı tipleri, <object>/<embed> kaynakları ve çalıştırılabilir ya da düzeni denetleyen içerik çeken <link> çeşitleri.

Değiştirilmiş etkin kaynak sayfayı yeniden yazabildiğinden, Google’ın ifadesiyle “Most browsers already block this type of content by default to protect users.” (Türkçesi: Çoğu tarayıcı kullanıcıları korumak için bu içerik türünü varsayılan olarak engeller.) Geçişten sonra görünür biçimde bozulan şeylerin nedeni budur: engellenen stil CSS’i kaldırır, engellenen betik etkileşimi öldürür, engellenen iframe boşluk bırakır. Önce etkin içeriği düzeltin. Bu yalnız güvenlik uyarısı değil, işlevsel hatadır.

Pasif (görüntülenen) karışık içerik, Google’a göre “including images, video, and audio” (görseller, video ve ses dâhil) olan ve “doesn’t interact with the rest of the page” (sayfanın geri kalanıyla etkileşmeyen) içeriktir. Araya giren biri görseli değiştirebilir, fakat belgeyi ele geçiremez. Bu yüzden tarayıcılar geçmişte onu yükleyip yalnızca güvenlik göstergesini düşürürdü. Google’ın ifadesiyle: “Until recently, passive mixed content was loaded in all browsers, because blocking it would have broken many websites. This is now beginning to change.” (Türkçesi: Yakın zamana kadar pasif karışık içerik tüm tarayıcılarda yükleniyordu; çünkü engellemek çok sayıda siteyi bozardı. Bu artık değişmeye başlıyor.) Yön, pasif kaynakları mümkün olduğunda HTTPS’e otomatik yükseltmek, yükseltilemeyeni engellemektir. Dolayısıyla “pasif = zararsız” güvenli bir varsayım değildir.

Etkin/pasif ayrımının kapsamadığı istisnalar

Yükseltilebilir/engellenebilir sınırında, genel “görseller yükseltilir, betikler engellenir” düzenine uymayan ve uygulamada sık hata yaratan istisnalar vardır:

• CORS etkin görsel istekleri yükseltilmez, zorunlu olarak başarısız olur. Normal <img src="http://…"> yükseltilebilir; ancak crossorigin ayarlı görsel isteği karışık içerik algoritmasında farklı ele alınır ve sessizce yükseltilmek yerine başarısız olur.
• srcset ve <picture> adayları yükseltilebilir değil, engellenebilirdir. Aynı görsel düz src yerine duyarlı görsel mekanizmasıyla istendiğinde engellenebilir sınıfına girer. Her görsel başvurusunun aynı davranacağını varsaymayın.
• IP adresli ana makineler, normalde yükseltilebilir kaynak türünde bile yükseltilmez, engellenir. http://203.0.113.5/logo.png benzeri başvuru, alan adı karşılığı gibi otomatik yükseltme görmez.
• İç içe bağlamlar ve çalışanlar kapsam içindedir. Denetimler yalnız üst belgede değil, iframe’lerde ve service/shared worker içinde de uygulanır. Çalışanın güvensiz betik çekmesi de karışık içeriktir.
• Yerel ve loopback kökenlerin özel kuralları vardır. localhost, loopback adresleri ve file:// bağlamları, TLS olmadan da belirtimde “potansiyel olarak güvenilir köken” sayılabilir. Basit HTTP/HTTPS sezgisi yerel geliştirmeye birebir uymaz.
• Güvensiz indirmeler ilişkili fakat ayrı bir sınırdır. Güvenli sayfanın http:// üzerinden başlattığı indirme gerçek risktir; ancak bu bölümdeki alt kaynak karışık içerik kurallarıyla değil, ayrı indirme güvenliği davranışıyla yönetilir.
• Üst düzey HTTP gezinmesi hâlâ karışık içerik değildir. Yukarıdaki bağlantı örneği buna dâhildir; yüklenen alt kaynağın değil, gezinmenin özelliğidir. Diğer istisnaların çoğu burada uygulanmaz.

Karışık içeriği tespit etme: bütün katmanlar

Tek bir düğme yoktur ve aşağıdaki her katman farklı soruyu yanıtlar; bir katmanın temiz çıkması diğerlerini temiz saydırmaz. Getirilen kaynağı (ham HTML’in gerçekte neyi referans gösterdiğini), işlenmiş/çalışma zamanı durumunu (tarayıcının sayfayı ayrıştırıp betikleri çalıştırdıktan sonra ne istediğini) ve gerçek kullanıcı oturumlarını (izin bandı, coğrafi yönlendirme, oturum duvarı veya yalnız belirli koşullarda çalışan üçüncü taraf etiketi arkasında ne olduğunu) ayrı ayrı inceleyin. Katmanlar “tek sayfa”dan “tüm site”ye şöyle ilerler:

1. Chrome DevTools konsolu (işlenmiş/çalışma zamanı durumu). HTTPS sayfasını açıp konsolu inceleyin. Engellenen etkin içerik, sayfanın HTTPS üzerinden yüklendiğini ancak güvensiz kaynak istediğini, isteğin engellendiğini ve içeriğin HTTPS üzerinden sunulması gerektiğini belirten bir ileti bırakır. Yüklenen pasif içerik engel yerine uyarı üretir. Security paneli (veya Issues sekmesi) bunları sayfa bazında toplar. Bu yöntem nokta denetimi ve belirli düzeltmeyi doğrulamak için hızlıdır; fakat tam ileti metni, panel düzeni ve engellenen türler tarayıcıya ve sürüme bağlıdır. Bu bilgi 2026-07 itibarıyla Chrome karşısında doğrulanmıştır. Sabit bir arayüz metnini alıntılamak yerine teşhis ettiğiniz gerçek sürümü kontrol edin; Firefox, Safari ve Edge’in farklı olmasını bekleyin.

2. Site tarayıcısı (getirilen kaynak, ölçekte). DevTools sayfa bazındadır; tarama site genelindedir. Ahrefs Site Audit ve Screaming Frog, HTTPS sitede http:// alt kaynaklarına başvuran sayfaları işaretler. Binlerce URL’de karışık içeriği bulmanın gerçekçi yolu budur ve denetimin temel aracıdır. Yine de yalnız kaynağı okur: temiz tarama, işlenmiş sayfanın veya gerçek oturumun temiz olduğunu kanıtlamaz. Niteliksiz “geçti/kaldı” demek yerine sonucu üreten tarayıcıyı/aracı/sürümü kaydedin.

3. CSP ihlal raporlaması (gerçek kullanıcı oturumları). Gerçek ziyaretçilerin tarayıcıları karışık içeriği size raporlayabilir. Böylece yalnız belirli sayfalarda, kullanıcılarda, izin durumlarında veya denetleyemediğiniz üçüncü taraf etiketlerinden yüklenen kaynaklar yakalanır; tek tarama ya da DevTools kontrolü bu katmana ulaşamaz. web.dev’in ifadesi: “You can use content security policy to collect reports of mixed content on your site. To enable this feature, set the Content-Security-Policy-Report-Only directive by adding it as a response header for your site.” (Türkçesi: Sitenizdeki karışık içerik raporlarını toplamak için içerik güvenliği politikasını kullanabilirsiniz; bunun için yanıt başlığı olarak Content-Security-Policy-Report-Only ayarlayın.) Yalnız raporlama modu politikayı uygulamadan ihlalleri bildirir; böylece engellemeyi açmadan önce üretimdeki sorunu ölçebilirsiniz. Mekanizma modern report-to / Reporting-Endpoints başlığını veya eski report-uri değerini kullanır. Bu, upgrade-insecure-requests yönergesini yalnız raporlama moduna koymaktan farklı genel amaçlı bir politikadır; söz konusu yönerge bu modda çalışmaz.

Üçünü birlikte kullanın: işlenmiş sayfayı doğrulamak için DevTools, getirilen kaynak envanteri için tarayıcı, yalnız gerçek kullanımda görünen uzun kuyruğu yakalamak için CSP raporları. Temiz tarama, kaynağa ilişkin kanıttır; her izin durumunun, reklam teknolojisi çeşidinin, kişiselleştirme dalının veya çalışanın temiz olduğunun garantisi değildir.

Kaynağında düzeltme

Gerçek düzeltme tek bir başvuruya dokunmadan önce başlar: HTTPS karşılığının gerçekten bulunduğunu, geçerli sertifika sunduğunu ve beklediğiniz içeriği döndürdüğünü doğrulayın. Alan adı çözümleniyor diye yalnız şemayı değiştirmenin güvenli olduğunu varsaymayın. Doğrulama sonrası her alt kaynak HTTPS üzerinden çözülmelidir. Aşağıdaki seçenekler yaklaşık tercih sırasındadır; her biri yazdığınız metinden çok sahiplik ve bağlama bağlıdır:

• Mutlak HTTPS URL’leri — http://cdn.example.com/app.js değerini https://cdn.example.com/app.js yapın. Açık ve belirsizliğe yer bırakmaz; aşağıdaki sunum bağlamından emin değilseniz en güvenli varsayılandır.
• Kökten göreli veya göreli yollar — aynı sitede sahip olduğunuz kaynaklar için /assets/app.js sayfanın şemasını otomatik devralır. Google’ın HTTPS rehberliği: “Make sure intrasite URLs and external URLs don’t depend on a specific protocol. Use relative paths or leave out the protocol as in //example.com/something.js.” (Türkçesi: Site içi ve dış URL’leri belirli protokole bağımlı kılmayın; göreli yol kullanın veya protokolü atlayın.) Bunu evrensel değil koşullu öneri sayın. Kaynağa gerçekten sahip olduğunuzu, sayfanın gerçek temel URL’sinin beklendiği gibi çözüldüğünü (<base> etiketi, proxy yolu veya gömülü/AMP bağlamı “göreli” anlamını değiştirebilir) ve istemci kodunun window.location ya da saklı mutlak değerle URL’yi yeniden kurup http:// üretmediğini doğrulayın.
• Protokole göreli URL’ler (//example.com/something.js) çalışır; fakat tercih edilen evrensel düzeltme değildir. Bunları alışkanlıkla değil, aynı sahiplik ve temel URL denetimlerinden sonra kullanın. Tümü HTTPS olan web’de açık https:// çoğunlukla daha nettir ve dosya HTTP dışı bağlamda açılırsa sürprizi önler. Şemayı sabit kodlamamak için özel nedeniniz varsa protokole göreli yolu seçin.

Ölçekte şablonları tek tek düzenlemezsiniz; ancak üretimde korumasız veri tabanı metin değiştirmesi de çalıştırmayın. http://yourdomain → https://yourdomain düz metin alanlarında genellikle güvenli görünür. CMS içeriği PHP serileştirilmiş dizileri, JSON blokları veya blok düzenleyici verisi gibi yapısal/serileştirilmiş olabilir; basit alt dize değişimi kaydı düzeltmek yerine bozar. Serileştirme biçimini anlayan uygulama araçlarını kullanın, önce veri tabanını yedekleyin ve etkilenen satırları inceleyebilmek için değişimi deneme modunda çalıştırın. Ardından URL üreten az sayıdaki şablon/yapılandırma dosyasını düzeltin; kalanları tarayıcı ve CSP raporlarıyla toplayın.

upgrade-insecure-requests: güvenlik ağı ve sınırları

Önleyici yedek bir Content-Security-Policy yönergesidir. web.dev’in ifadesi: “The upgrade-insecure-requests CSP directive instructs the browser to upgrade insecure URLs before making network requests.” (Türkçesi: Yönerge, ağ istekleri yapılmadan önce güvensiz URL’leri yükseltmesini tarayıcıya söyler.) Şu başlığı ayarlayın:

Content-Security-Policy: upgrade-insecure-requests

MDN’ye göre yönerge “instructs user agents to treat all of a site’s insecure URLs (those served over HTTP) as though they have been replaced with secure URLs (those served over HTTPS).” (Türkçesi: Kullanıcı aracılarının, bir sitenin HTTP üzerinden sunulan tüm güvensiz URL’lerini HTTPS üzerinden sunulan güvenli URL’lerle değiştirilmiş gibi ele almasını sağlar.) MDN bunun “requests to load resources (such as images, scripts, or fonts),” “navigation requests (such as link targets) that are same-origin with the document,” “navigation requests in nested browsing contexts, such as iframes,” ve “form submissions” türlerini yükselttiğini söyler. (Türkçesi: görsel/betik/yazı tipi kaynak istekleri, belgeyle aynı kökendeki gezinme istekleri, iframe gibi iç içe gezinme istekleri ve form gönderimleri.)

Alıntının ötesinde iki işletim ayrıntısı önemlidir. Birincisi, alt kaynak yükseltmesi aynı kökenle sınırlı değildir; yalnız gezinme yükseltmesi yukarıdaki alıntıya göre aynı kökenlidir. Normal alt kaynak istekleri kökenler arasında da yeniden yazılır; CDN’deki betik veya üçüncü taraf yazı tipi de yükseltilir. İkincisi, yeniden yazma tarayıcının karışık içerik ve CSP denetimleri isteği değerlendirmeden önce olur. Bu yüzden normalde doğrudan engellenecek kaynak yükseltildikten sonra temiz biçimde yüklenebilir; yükseltme engeli önceler.

Göz ardı etmemeniz gereken üç sınır vardır:

• Üçüncü taraf üst düzey gezinmesini yükseltmez. MDN: “However, top-level navigation requests whose target is a different origin will not be upgraded.” (Türkçesi: Hedefi farklı köken olan üst düzey gezinme istekleri yükseltilmez.) Bu nedenle açıkça HSTS’nin yerine geçmez: “The upgrade-insecure-requests directive will not ensure that users visiting your site via links on third-party sites will be upgraded to HTTPS for the top-level navigation and thus does not replace the Strict-Transport-Security (HSTS) header.” (Türkçesi: Üçüncü taraf bağlantılarından gelen üst düzey gezinmeyi HTTPS’e yükseltmeyi garanti etmez ve HSTS başlığının yerini tutmaz.)
• Güvenlik ağıdır, düzeltme değildir ve geri dönmez. Kaynak HTTPS üzerinde gerçekten yoksa yükseltilmiş istek doğrudan başarısız olur; özgün http:// sürümüne geri dönmez. Kaynağı temizlemek hâlâ sizin işinizdir; yönerge gerçekten bozuk olanı değil, kaçırdığınızı kapsar.
• Yalnız raporlama modu yükseltme yapmaz; etkisizdir. upgrade-insecure-requests değerini Content-Security-Policy-Report-Only içine koyarsanız tarayıcı bunu yok sayar: hiçbir şey yeniden yazılmaz ve bu yönerge için hiçbir şey raporlanmaz. Zorunlu uygulamadan önce etkiyi görmek istiyorsanız izin verilmeyen http:// hedeflerini bildiren ayrı, genel amaçlı bir raporlama politikası çalıştırın (yukarıda tespit için kullanılan default-src https: yaklaşımı). Yönergenin kendisini yalnız raporlama yaparak bu görünürlüğü elde edemezsiniz.

block-all-mixed-content: çoğunlukla tarihsel

MDN’ye göre eşlik eden block-all-mixed-content yönergesi “prevents loading any assets over HTTP when the page uses HTTPS” (sayfa HTTPS kullanırken hiçbir varlığın HTTP üzerinden yüklenmesini önler); hem “blockable and upgradable mixed content” türlerini kapsar ve iframe’lere de uygulanır. Uygulamada yerini başka davranışlar almıştır. MDN bunu kullanımdan kaldırılmış ve “obsolete in the specification” (belirtimde geçersiz) olarak işaretler; “Content that isn’t blocked is now always upgraded to a secure connection, so this directive is not needed.” (Engellenmeyen içerik artık daima güvenli bağlantıya yükseltildiği için yönerge gerekli değildir.) Yeni dağıtımda upgrade-insecure-requests kullanın; block-all-mixed-content değerini yalnız devralınabilecek eski bir ayar olarak ele alın. Zaten upgrade-insecure-requests gönderiyorsanız yükseltilebilir istekler için diğer yönergenin yapacağı bir şey kalmaz: yeniden yazma önce gerçekleştiğinden engelleme denetimine gelindiğinde istek ya yükseltilmiş ya da başarısız olmuştur. Yalnız eski değil, UIR dağıtılmış her yerde gereksizdir.

CMS neden sorunu yeniden üretir?

Karışık içerik tek seferlik temizlik değildir; birkaç sistem siz bitti sanınca sessizce http:// URL’lerini yeniden ekler:

• İçerik veri tabanı. WordPress, Drupal ve çoğu CMS’te editörler mutlak http:// URL’li görsel ve gömmeleri doğrudan yazı gövdesine yapıştırır. Bunlar şablonda değil veri tabanında yaşar; kod düzeltmesi dokunmaz. Veri tabanı arama-değiştirmesi bu yüzden gerekir.
• Temalar ve eklentiler. Yazı tipi, betik veya arka plan görseli için http:// URL’sini sabit kodlayan tema/eklenti, oluşturduğu her sayfada karışık içeriği geri getirir. Eklenti güncellemesi temizlikten sonra sorunu yeniden başlatabilir.
• Reklam teknolojisi, analiz ve üçüncü taraf etiketleri. Etiket yöneticileri, reklam ağları, sohbet bileşenleri ve analiz parçaları kendi alt kaynaklarını yükler. Sağlayıcı etiketi hâlâ http:// çağırıyorsa bunu kendi kodunuzda düzeltemezsiniz. CSP raporlaması tam bu uzun kuyruk içindir. Kalıcı çözüm, sağlayıcının HTTPS sunmasını sağlamak veya etiketi kaldırmaktır. Çalışan HTTPS uç noktası yoksa seçenekler yine üçtür: sağlayıcı düzeltsin, bağımlılığı değiştirin ya da kaldırın. Güvensiz sürümü güvenle çalıştıran dördüncü yol yoktur.
• Servis çalışanları ve önbellekler. Service worker hâlâ http:// gösteren yanıtı veya isteği önbelleğe alıp kaynak düzeltildikten sonra da tekrar ziyaretlerde eski başvuruyu sunabilir. Düzeltmenin çalışmadığı sonucuna varmadan önce gizli/önbelleksiz oturumda yeniden üretin. URL’leri değiştiren dağıtım, eski kayıtların yeniden oynatılması yerine çıkarılması için service worker/önbellek sürümünü de artırmalıdır.
• Eski içerik, e-posta ve yazdırma şablonlarında sabit kodlanan http:// yeniden kullanılabilir.

İşletim sonucu: tespiti bir kez çalıştırılan yayın kontrolü değil, yinelenen denetim (tarayıcı + CSP raporları) hâline getirin.

Karışık içerik ile HSTS nasıl ilişkilidir?

Karışık içerik ve HSTS komşu fakat farklı sorunları çözer; birbirine karıştırmak yaygın hatadır:

• upgrade-insecure-requests, güvenli sayfanızın istediği alt kaynakları düzeltir; sayfanın çektiği görselleri, betikleri ve iframe’leri yükseltir.
• HSTS (Strict-Transport-Security), sitenize yapılan üst düzey gezinmeyi daha ilk istekte ve herhangi bir yönlendirme çalışmadan önce HTTPS’e zorlar; SSL stripping saldırısına karşı korur. Google bunu “avoid the cost of a 301 redirect” ve “defeat attacks like SSL Stripping” yollarından biri olarak tanımlar (Türkçesi: 301 yönlendirme maliyetinden kaçınmak ve SSL stripping saldırılarını yenmek).

Birbirlerinin yerine geçmezler. MDN’nin açık ifadesiyle upgrade-insecure-requests, “will not ensure that users visiting your site via links on third-party sites will be upgraded to HTTPS for the top-level navigation and thus does not replace the Strict-Transport-Security (HSTS) header.” (Türkçesi: Üçüncü taraf bağlantılarından gelen kullanıcıların üst düzey gezinmesini HTTPS’e yükseltmeyi garanti etmez ve HSTS başlığının yerini tutmaz.) Tam güçlendirilmiş kurulumda ikisini de kullanın: upgrade-insecure-requests (veya temiz kaynak URL’leri) güvenli sayfada güvensiz yük bırakmaz; HSTS ise kimsenin siteye ilk aşamada HTTP üzerinden ulaşmamasını sağlar. Normal HSTS uyarısı geçerlidir: Google, sertifika doğrulama hatasıyla HTTPS dağıtmayacak kadar sağlam olduğunuzdan emin olmadan HSTS’yi açmamanızı söyler. Preload listesine girmek tek yönlü kapıya yakındır.

Karışık içerik SEO’ya doğrudan zarar verir mi?

Önce doğrudan etkileri ele alın; denetleyebildiğiniz bunlardır. Karışık içerik her şeyden önce güvenlik ve işlevsellik sorunudur. Engellenen etkin kaynaklar işlemeyi ve etkileşimi doğrudan bozar. Eksik stil veya betik, arama motorunun ne yaptığından bağımsız gerçek gerilemedir. Sıralamayı düşünmeden önce düzeltmek için bu yeterlidir.

SEO sonuçları gerçektir fakat koşulludur; doğrudan ya da garantili değildir. Google’ın güncel resmî rehberliği karışık içeriği düzeltmenin doğrudan sıralama artışı sağladığını ortaya koymaz. HTTPS sıralama sinyali URL’nin https:// ile başlayıp başlamadığına, yani şemaya dayanır; alt kaynak temizliği denetimi değildir. Tek güvensiz görsel kendi başına “HTTPS sinyalini” kaybettirmez. Ancak gerçekte bozulan şeye bağlı dolaylı etkiler görülebilir: Googlebot, CSS veya JS karışık içerik olarak engellenmiş sayfanın bozuk ya da eksik sürümünü işleyip dizine ekleyebilir; düşürülen güvenlik göstergesi sıralama değişmese bile kullanıcı güvenini, etkileşimi ve dönüşümü azaltabilir. Google’ın HTTPS kanonik tercihi de koşulludur: geçersiz sertifikalar, güvensiz bağımlılıklar, HTTPS’ten HTTP’ye yönlendirmeler veya sayfadaki çelişkili kanonik sinyaller, karışık içerikten bağımsız olarak seçilen URL’yi değiştirebilir. İşleme, dizine ekleme, kanonikleştirme ve analiz etkilerini kendi sayfalarınızda doğrulanacak unsurlar sayın; evrensel sonuçlar vaat etmeyin. Karışık içeriği önce güvenlik ve işlevsellik nedenleriyle düzeltin.

Bu konu daha geniş SEO için HTTPS rehberinin içindedir; geçiş oyun planını, sıralama sinyalinin ağırlığını ve HSTS’yi bütünüyle kapsar. Sertifikanın kendisini (zincir hataları, süre dolumu, DV/OV/EV) inceliyorsanız o ayrı fakat kardeş bir ayrıntılı rehberdir.

AI özet

Gelişmiş sürümün kısa özeti:

• Karışık içerik, HTTPS sayfasının HTTP üzerinden alt kaynak yüklemesidir. Sayfanın içerdiği bağlantılar değil, yüklediği kaynaklar söz konusudur. HTTP sayfasına bağlantı veya başka üst düzey HTTP gezinmesi karışık içerik değildir; güvensiz indirme de ilişkili fakat ayrı bir sınırdır.
• Güncel sınıflandırma yükseltilebilir/engellenebilir; etkin/pasif daha eski fakat risk alanını anlatmak için hâlâ yararlıdır. Tarayıcının çalıştırdığı betik, stil, iframe ve XMLHttpRequest/fetch gibi etkin kaynaklar değiştirilmiş betik tüm sayfayı yeniden yazabileceği için engellenir; önce bunları düzeltin. Görsel, ses ve video gibi pasif kaynaklar geçmişte düşürülen kilitle yüklenirdi; artık giderek daha çok otomatik yükseltilir veya engellenir. CORS etkin görseller, srcset/ <picture> adayları, IP adresli ana makineler, iç içe bağlamlar/çalışanlar ve yerel kökenlerin özel kuralları vardır.
• Tek değil üç katmanda tespit edin: getirilen kaynak (Ahrefs Site Audit veya Screaming Frog gibi site genelindeki tarayıcı), işlenmiş/çalışma zamanı durumu (sayfa bazında Chrome DevTools konsolu/Security paneli; tam metin tarayıcı ve sürüme bağlıdır) ve gerçek kullanıcı oturumları (Content-Security-Policy-Report-Only raporları; üçüncü taraf etiketleri ve izin koşullu kaynaklar dâhil üretimdeki uzun kuyruk). Bir katmanın temiz olması diğerlerini temiz saydırmaz.
• HTTPS karşılığının çalıştığını doğruladıktan sonra kaynağında düzeltin: her alt kaynağı https:// adresine yöneltin. Göreli veya protokole göreli yolları yalnız sahipliği ve gerçek temel URL davranışını doğruladıktan sonra kullanın. Ölçekte veri tabanını yedekleyin ve değişimi deneme modunda çalıştırın; basit metin değiştirme serileştirilmiş/yapısal CMS verisini bozabilir. Kalan şablon/yapılandırmaları düzeltin ve servis çalışanı/önbelleğin eski http:// başvurularını yeniden oynatmasını izleyin.
• upgrade-insecure-requests, farklı kökenlerdekiler dâhil kapsamdaki http:// alt kaynak isteklerini gönderilmeden ve karışık içerik/CSP denetimlerinden önce https:// biçimine çeviren CSP başlığıdır. Başarısız yükseltmede HTTP’ye dönmeyen güvenlik ağıdır. Üçüncü taraf üst düzey gezinmesini yükseltmez ve HSTS’nin yerine geçmez. Yönergenin kendisini yalnız raporlama moduna koymak etkisizdir; ayrı bir raporlama politikası kullanın.
• block-all-mixed-content kullanımdan kaldırılmış/geçersizdir ve upgrade-insecure-requests dağıtıldıktan sonra gereksizdir; yükseltme önce çalışır.
• Sorun geri döner; CMS veri tabanı, tema/eklentiler, servis çalışanları/önbellekler ve reklam/analiz etiketleri http:// URL’lerini yeniden ekleyebilir. Bir kez değil, programlı olarak denetleyin.
• SEO etkisi doğrudan değil, koşulludur. Güncel Google rehberliği düzeltmenin doğrudan sıralama artışı olduğunu ortaya koymaz; HTTPS sinyali şemaya dayanır. Engellenen etkin kaynaklar Googlebot’un bozuk sayfayı işlemesine/dizine eklemesine, düşen kilit göstergesi güven kaybına yol açabilir. HTTPS kanonik tercihi sertifika geçerliliği ve çelişkili sinyaller gibi koşullara da bağlıdır; karışık içeriğe özgü garanti değildir.

resmî dokümantasyon

Google ve tarayıcı/standart ekiplerinin birincil kaynak belgeleri.

Google / web.dev

• Karışık içerik nedir? — tanım, etkin/pasif ayrımı ve tarayıcı davranışı.
• Karışık içeriği düzeltme — bulma, alt kaynak URL’lerini düzeltme, upgrade-insecure-requests ve CSP raporlaması.
• Sunucularınızda HTTPS’i etkinleştirme — göreli/ protokole göreli URL’ler, HTTP <iframe> notu ve HSTS rehberliği.
• Karışık içeriği önleme, Google’ın HTTPS rehberliğinin parçasıdır — karışık içerik düzeltmelerinin yer aldığı site taşıma/geçiş oyun planı.

MDN / standards

• CSP: upgrade-insecure-requests — neleri yükselttiği, neleri yükseltmediği ve neden HSTS’nin yerini tutmadığı.
• CSP: block-all-mixed-content — kullanımdan kaldırılmış/geçersiz engelleme yönergesi.
• MDN — Karışık içerik — engellenebilir ve yükseltilebilir içerik için tarayıcı davranışı başvurusu.
• Content Security Policy (CSP) — raporlama dâhil bu yönergelerin bulunduğu başlık.

Kaynaktan alıntılar

Google’ın web.dev sayfalarıyla MDN standart belgelerindeki kayda geçmiş tanımlar. Platform desteklediğinde her bağlantı doğrudan alıntılanan bölüme gider.

Google / web.dev — karışık içerik nedir?

• “A page has mixed content when its initial HTML is loaded over a secure HTTPS connection, but other resources (such as images, videos, stylesheets, and scripts) are loaded over an insecure HTTP connection.” kaynak
• “Active mixed content poses a greater threat than passive mixed content.” kaynak
• Etkin karışık içerik “includes scripts, stylesheets, iframes, and any other code the browser can download and execute,” (tarayıcının indirip çalıştırabildiği betikleri, stil dosyalarını, iframe’leri ve diğer kodları içerir); ayrıca “Most browsers already block this type of content by default to protect users.” (çoğu tarayıcı kullanıcıları korumak için bunu varsayılan olarak engeller). kaynak
• Görsel, video ve ses dâhil pasif karışık içerik, “doesn’t interact with the rest of the page.” (sayfanın geri kalanıyla etkileşmez). Ayrıca: “Until recently, passive mixed content was loaded in all browsers, because blocking it would have broken many websites. This is now beginning to change.” (Yakın zamana kadar tüm tarayıcılarda yükleniyordu; engellemek çok sayıda siteyi bozardı. Bu artık değişiyor.) kaynak

Google / web.dev — tespit ve düzeltme

• “You can use content security policy to collect reports of mixed content on your site. To enable this feature, set the Content-Security-Policy-Report-Only directive by adding it as a response header for your site.” kaynak
• “The upgrade-insecure-requests CSP directive instructs the browser to upgrade insecure URLs before making network requests.” kaynak
• “Make sure intrasite URLs and external URLs don’t depend on a specific protocol. Use relative paths or leave out the protocol as in //example.com/something.js.” kaynak

MDN — upgrade-insecure-requests ve sınırları

• “The HTTP Content-Security-Policy (CSP) upgrade-insecure-requests directive instructs user agents to treat all of a site’s insecure URLs (those served over HTTP) as though they have been replaced with secure URLs (those served over HTTPS).” kaynak
• “However, top-level navigation requests whose target is a different origin will not be upgraded.” kaynak
• “The upgrade-insecure-requests directive will not ensure that users visiting your site via links on third-party sites will be upgraded to HTTPS for the top-level navigation and thus does not replace the Strict-Transport-Security (HSTS) header.” kaynak

MDN — block-all-mixed-content eski bir yönergedir

• “The HTTP Content-Security-Policy (CSP) block-all-mixed-content directive prevents loading any assets over HTTP when the page uses HTTPS.” Yönerge kullanımdan kaldırılmış ve “obsolete in the specification” (belirtimde geçersiz) olarak işaretlenir; çünkü “Content that isn’t blocked is now always upgraded to a secure connection, so this directive is not needed.” (Engellenmeyen içerik artık daima güvenli bağlantıya yükseltilir; bu yüzden yönerge gerekli değildir.) kaynak

Karışık içerik kontrol listesi

Bunu HTTP→HTTPS geçişi sırasında, sonrasında ve ardından düzenli aralıklarla çalıştırın:

Bulun

• Temel şablonları (ana sayfa, ürün, makale, ödeme) HTTPS üzerinden Chrome DevTools konsolu açıkken yükleyip her “Mixed Content” iletisini kaydedin.
• Tam tarama (Ahrefs Site Audit veya Screaming Frog) çalıştırıp http:// alt kaynaklarına başvuran sayfaların listesini çıkarın.
• Üretimdeki uzun kuyruğu (kullanıcı/sayfa bazlı ve üçüncü taraf etiketleri) yakalamak için raporlama uç noktalı Content-Security-Policy-Report-Only ayarlayın.

Düzeltin (önce etkin içerik)

• Tüm etkin başvuruları düzeltin: <script>, <link rel="stylesheet">, <iframe>, fetch/XMLHttpRequest ve yazı tipleri. Bunlar engellenir ve sayfayı bozar.
• Tüm pasif başvuruları düzeltin: <img>, <audio>, <video> ile bunların <source>/poster URL’leri.
• Yapıştırılan içerik için CMS veri tabanı değişimini (http://yourdomain → https://yourdomain) yedekleyin ve yapıyı bilen araçla deneme modunda çalıştırın; serileştirilmiş/yapısal alanlarda ham metin değişimi yapmayın.
• Tema/eklentilerde sabit kodlanan http:// varlık URL’lerini bulup düzeltin.
• Service worker/önbellek kayıtlarını önbelleksiz oturumda yeniden üretin ve eski http:// başvurularının yeniden oynatılmaması için sürümü artırın.
• Üçüncü taraf etiketlerinin (reklam, analiz, sohbet, gömme) HTTPS üzerinden yüklendiğini doğrulayın; değilse sağlayıcıyı düzeltmeye zorlayın veya etiketi kaldırın.

Güvenlik ağı ve doğrulama

• HSTS’nin yerini tutmadığını bilerek güvenlik ağı olarak Content-Security-Policy: upgrade-insecure-requests başlığını ayarlayın.
• Yeniden tarayıp konsolu tekrar inceleyin: engellenen etkin kaynak sıfır, denetlenen sayfalarda kilit göstergesi temiz olmalı.
• Eklenti güncellemeleri ve yeni içerik sorunu geri getirebildiği için tespiti yalnız yayın kontrolüne değil yinelenen denetime ekleyin.

Bu karışık içerik vakası hangi düzeltmeyi gerektirir?

Belirtiden aşağı doğru ilerleyin.

Güvensiz öğe sayfanın yüklediği kaynak mı, içerdiği bağlantı mı?

• Bağlantı (<a href="http://…">) → Karışık içerik değildir. İsterseniz yönlendirme verisi temizliği için HTTPS’e yöneltin; burada durun.
• Yüklenen kaynak (betik, stil, iframe, görsel, yazı tipi, medya, fetch) → devam edin.

Kaynak HTTPS üzerinden mevcut mu?

• Evet ve doğruladınız (geçerli sertifika, doğru içerik) → başvuruyu güvenli varsayılan olan https:// biçimine çevirin. Kaynağa sahipseniz ve sayfanın temel URL davranışını denetlediyseniz göreli/protokole göreli yol da kullanabilirsiniz. Gerçek düzeltme budur.
• Hayır / emin değilsiniz → birinci taraf (kendi varlığınız) mı?
  • Birinci taraf → kendi sunucunuzda HTTPS üzerinden sunup yukarıdaki gibi düzeltin.
  • Üçüncü taraf (sağlayıcı etiketi, reklam, gömme) → sağlayıcıdan HTTPS uç noktası isteyin; yoksa etiketi değiştirin veya kaldırın. upgrade-insecure-requests yükseltmeyi dener, ancak sağlayıcıda HTTPS yoksa istek yalnızca başarısız olur.

Etkin mi pasif mi?

• Etkin (betik/stil/iframe/fetch/yazı tipi) → en yüksek öncelik. Engellendiği için düzeltilene kadar sayfa işlevsel olarak bozuktur.
• Pasif (görsel/ses/video) → bunu da düzeltin; aciliyeti daha düşüktür (anlık bozulma yerine kilit göstergesi düşüşü veya gelecekte engellenme).

Kaçırdıklarınız için güvenlik ağı istiyor musunuz?

• Content-Security-Policy: upgrade-insecure-requests ayarlayın. Bunun bir yedek, düzeltmenin yerine geçen çözüm olmadığını ve üçüncü taraf üst düzey gezinmesini kapsamadığı için HSTS’nin yerini tutmadığını unutmayın.

İlk ziyaret/üçüncü taraf yönlendirmesinde üst düzey sayfayı da HTTPS’e zorlamanız gerekiyor mu?

• Bu, ayrı denetim olan HSTS’dir. Strict-Transport-Security ekleyin; ancak HSTS, özellikle preload, tek yönlü kapıya yakın olduğundan yalnız sertifika işletiminiz son derece sağlam olduğunda açın.

Zihinsel modeller

1. Bağlantılar değil, kaynaklar. Karışık içerik güvenli sayfanın yüklediği şeyle ilgilidir, bağlandığı yerle değil. Kararsızsanız “Tarayıcı mevcut sayfayı oluşturmak için bunu getiriyor mu?” diye sorun. Evetse olası karışık içeriktir; yalnız başka sayfaya götürüyorsa değildir.

2. Soyut önem yerine tarayıcı davranışına göre öncelik verin. Etkin (betik, stil, iframe) içerik engellenir; işlevsel hatadır, önce düzeltin. Pasif (görsel, medya) içerik için uyarı verilir veya yükseltilir; sonra düzeltin. Öncelik kuyruğunuzu tarayıcının davranışı belirlesin.

3. Tespit hunidir: doğrula → envanterle → uzun kuyruğu yakala. DevTools konsolu (tek sayfa, kesin), tarayıcı (tüm site, toplu), CSP raporları (üretim, üçüncü taraf, kullanıcı bazlı uzun kuyruk). Hiçbir araç üçünü birden görmez.

4. Kaynağı düzeltin; kalanına güvenlik ağı kurun. Veri tabanı, şablonlar ve etiketlerdeki gerçek URL’leri temizleyin. Ardından kaçanlar için upgrade-insecure-requests ekleyin. Yönerge onarımdan çok sigortadır.

5. İki farklı “HTTPS’e zorla” işi, iki farklı araç. upgrade-insecure-requests, güvenli sayfanın istediği alt kaynakları yükseltir. HSTS, sitenize üst düzey gezinmeyi HTTPS’e zorlar. Örtüşmez ve biri diğerinin yerini tutmaz; güçlendirilmiş site ikisini de kullanır.

6. Tek seferlik görev değil, yinelenen denetimdir. CMS veri tabanı, eklenti/tema güncellemeleri ve üçüncü taraf etiketleri http:// değerlerini yeniden ekler. Tespiti programlı tarama yapın; aksi hâlde sessizce döner.

Karışık içerik karşıt örüntüleri

Güvensiz içeriği canlı bırakan veya düzeltmek yerine üstünü örten hatalar.

• upgrade-insecure-requests değerini düzeltme saymak. Bu güvenlik ağıdır. Kaynağın HTTPS sürümü yoksa yükseltilmiş istek başarısız olur; bozuk bağımlılığı çözmek yerine saklamış olursunuz. URL’leri temizleyin, yönergeyi uzun kuyruk için kullanın.
• Kod dağıtımının veri tabanını temizlediğini varsaymak. CMS’te çoğu http:// görsel/gömme URL’si şablonda değil içerik satırındadır. Şablon düzeltmesi eski yazıları karışık bırakır; veri tabanı arama-değiştirmesini çalıştırın.
• “Yalnız uyarı” diye etkin içeriği ertelemek. Uyarı değildir; etkin kaynak engellenir. Engellenen stil veya betik kozmetik uyarı değil, işlevsel kesintidir.
• Ana sayfayı nokta denetleyip işi bitmiş saymak. Sorun ürün sayfaları, eski yazılar ve yalnız bazı kullanıcıların gördüğü yollarda saklanır. Tüm siteyi tarayın; taramanın ulaşamadığı yer için CSP raporlaması kullanın.
• Üçüncü taraf etiketlerini yok saymak. Reklam, analiz veya sohbet sağlayıcısı hâlâ http:// çağırıyorsa bunu kendi deponuzda düzeltemezsiniz. Sağlayıcıyı düzeltmeye zorlayın veya etiketi kaldırın.
• Yeni yapıda block-all-mixed-content kullanmak. Kullanımdan kaldırılmış ve geçersizdir; yerine upgrade-insecure-requests kullanın.
• upgrade-insecure-requests ile HSTS’yi karıştırmak. Biri alt kaynakları yükseltir; diğeri üst düzey HTTPS’i zorlar ve SSL stripping’e karşı korur. Birini dağıtıp diğerini kapsadığınızı sanmak gerçek açık bırakır.
• Tespiti yinelenen denetimin dışında bırakmak. Bir kez düzeltip tekrar bakmamak, eklenti güncellemesi veya yapıştırılan http:// görselinin fark edilmeden dönmesini garanti eder.

Karışık içerik — kısa başvuru

Etkin ve pasif karşılaştırması

Tespit katmanları

CSP yönergeleri

Bunları karıştırmayın

Tek satırlık plan (CMS): Veri tabanında http://yourdomain → https://yourdomain değişimini güvenle yapın; şablon/eklentileri düzeltin; ardından upgrade-insecure-requests ayarlayın.

Karışık içeriği bulma — kod parçaları

1. Komut satırından tek sayfa tarama

Sayfayı alıp HTML’de kalan güvensiz src/href alt kaynaklarını işaretleyin.

macOS / Linux

# Flag insecure script/img/link/iframe/source references on a single URL
curl -s https://example.com/ \
  | grep -Eo '(src|href)="http://[^"]+"' \
  | sort -u

Windows (PowerShell)

(Invoke-WebRequest -Uri "https://example.com/").Content `
  | Select-String -Pattern '(src|href)="http://[^"]+"' -AllMatches `
  | ForEach-Object { $_.Matches.Value } | Sort-Object -Unique

Bu yalnızca ham HTML’i görür. JavaScript’in eklediği kaynaklar görünmez; bu nedenle DevTools ve gerçek site tarayıcısını da kullanmalısınız.

2. Chrome DevTools Console — işlenmiş sayfadaki güvensiz kaynakları listeleme

JavaScript’in eklediği başvuruları da yakalamak için HTTPS sayfasının konsoluna yapıştırın:

// Every element with an http:// resource attribute in the live DOM
[...document.querySelectorAll('[src],[href],[srcset],[data-src]')]
  .filter(el => /^http:\/\//.test(
    el.src || el.href || el.getAttribute('srcset') || el.getAttribute('data-src') || ''
  ))
  .map(el => ({ tag: el.tagName, url: el.src || el.href }));

Tarayıcı engellenen etkin karışık içeriği ayrıca kendisi kaydeder: Mixed Content: … This request has been blocked; the content must be served over HTTPS. Önce bu iletileri okuyun.

3. Yer imi betiği — tek tıkla konsol dökümü

Yer imi olarak kaydedin; herhangi bir HTTPS sayfasında tıklayıp http:// başvurularını konsola yazdırın:

javascript:(()=>{const h=[...document.querySelectorAll('[src],[href]')].filter(e=>/^http:\/\//.test(e.src||e.href)).map(e=>e.src||e.href);console.log('%cMixed content candidates:','font-weight:bold',h.length);h.forEach(u=>console.log(u));})();

4. CSP raporlamasını açma (üretimde algılama)

Gerçek ziyaretçilerin tarayıcılarının, üçüncü taraf etiketleri ve taramanın kaçırdığı sayfalar dâhil ihlalleri bildirmesi için yalnız raporlama başlığı ekleyin:

Content-Security-Policy-Report-Only: default-src https:; report-uri /csp-report-endpoint

Yalnız raporlama modu zorunlu uygulamadan ihlalleri raporlar; böylece upgrade-insecure-requests veya zorunlu politikayı açmadan önce sorunu güvenle ölçebilirsiniz. Modern karşılığı Reporting-Endpoints başlığıyla report-to kullanır.

5. Güvenlik ağı başlığı (kaynağı düzelttikten sonra)

Content-Security-Policy: upgrade-insecure-requests

Üçüncü taraf üst düzey gezinmesini yükseltmediğini ve HSTS’nin yerine geçmediğini unutmayın.

Yinelenen karışık içerik denetimi SOP’si

HTTPS yayını, CMS/tema sürümü ve etiket yöneticisi değişikliğinden sonra; içeriği sık değişen sitelerde de düzenli programla çalıştırın.

1. HTTPS sayfalarını ham ve işlenmiş modda tarayın. src, srcset, stil, iframe, medya ve fetch/XHR isteklerindeki güvensiz URL’leri dışa aktarın. Normal HTTP bağlantıları karışık içerik değildir.
2. Tarayıcı kanıtını toplayın. Temsilî şablonlarda DevTools’u inceleyin; gerçek ziyaretçi ve üçüncü taraf etiket ihlalleri için Content-Security-Policy-Report-Only kullanın.
3. Her bulguyu sınıflandırın. Etkin/pasif, birinci/üçüncü taraf, statik/JavaScript ekli ayrımını yapıp kaynağın sahibi olan şablon, veri alanı, eklenti, etiket veya sağlayıcıyı belirleyin.
4. Kaynak başvurusunu düzeltin. Çalışan HTTPS kaynağına veya güvenli göreli URL’ye yöneltin. Yalnız http:// → https:// değişiminin yeterli olduğunu varsaymayın; hedefin gerçekten TLS desteklediğini doğrulayın.
5. CSP’yi güvenlik ağı olarak kullanın. Bulguları inceledikten sonra upgrade-insecure-requests ekleyin. Maruziyeti azaltabilir; CMS kaydını onarmaz ve HSTS’nin yerini tutmaz.
6. Yeniden tarayın ve işleyin. Denetlenen şablonlarda etkin karışık içerik hatası sıfır olmalı; pasif kaynaklar da geri dönüş olmadan HTTPS üzerinden çözülmeli.
7. Tekrarı önleyin. Kaynak şablonu/editör iş akışını düzeltin, uygun yerde yalnız raporlama toplamayı sürdürün ve yeni ihlali sistem sahibine atayın.

Belirti → olası neden → düzeltme

Karışık içerik yayın testleri

Test 1: işlenmiş şablon taraması

• Amaç: Ham HTML’in kaçırdığı etkin ve pasif kaynakları yakalamak.
• Yöntem: Her şablon ve etkileşim durumu için temsilî URL’yi işleyin; güvensiz veya engellenmiş istekler için Console ve Network çıktısını inceleyin.
• Beklenen sonuç: Hiçbir alt kaynak HTTP üzerinden istenmez ve hiçbir etkin içerik engellenmez.
• Başarısızlık tetikleyicisi: Karışık içerik uyarısı, otomatik yükseltme başarısızlığı veya engellenen kaynağın yol açtığı eksik düzen/işlev.
• Sonraki adım: İsteği şablon, etiket, eklenti veya saklı alanına kadar izleyin; kaynağı düzeltip taramayı yeniden çalıştırın.

Test 2: kaynak ve CSP karşılaştırması

• Amaç: Yalnız gerçek ziyaretçiler veya üçüncü taraflar için eklenen ihlalleri bulmak.
• Yöntem: Tarayıcı bulgularıyla Content-Security-Policy-Report-Only olaylarını engellenen URL, sayfa şablonu, yönerge ve sahip bazında karşılaştırın.
• Beklenen sonuç: Açıklanamayan yalnız üretim ihlali kalmaz; bilinen gürültü belgelenir ve dar kapsamda dışlanır.
• Başarısızlık tetikleyicisi: Taramada bulunmayan tekrarlanabilir ihlal veya sahipsiz üçüncü taraf kaynak.
• Sonraki adım: Ziyaretçi durumunu yeniden üretip isteği ekleyen entegrasyonu düzeltin veya kaldırın.

Test 3: yayın sonrası tekrar testi

• Amaç: CMS’in artık yeni güvensiz başvurular üretmediğini doğrulamak.
• Yöntem: Normal editoryal iş akışıyla test öğesi yayınlayın; üretimde kullanılan aynı denetimlerle tarayıp işleyin.
• Beklenen sonuç: Üretilen işaretleme ve yüklenen kaynaklar geçerli HTTPS URL’leri kullanır.
• Başarısızlık tetikleyicisi: Yeni sayfa, eski içerikten temizlenen HTTP başvurusunu yeniden oluşturur.
• Sonraki adım: Yayın ilerlemeden editör varsayılanını, şablonu, eklentiyi veya içerik dönüşümünü düzeltin.

Zaman ayırmaya değer kaynaklar

Konuşmalarım

• Better Safe Than Sorry with HTTPS — SMX East 2016 (SlideShare) — TLS, yaygın HTTPS uygulama hataları ve karışık içeriği ilk aşamada üreten geçiş tuzaklarına ilişkin ayrıntılı sunumum. (Sürekli geçerli açıklama: Bu, sistemleri benim anlayışımı yansıtır; benimsenme istatistikleri 2016 tarihlidir.)

İlgili yazılarım

• Teknik SEO için başlangıç rehberi — HTTPS ve karışık içeriğin daha büyük teknik tabloda yeri.

Sektörden

• Karışık içerik nedir? (web.dev / Google) — temel tanım ve etkin/pasif ayrımı.
• Karışık içeriği düzeltme (web.dev / Google) — bulma, alt kaynak URL’lerini düzeltme, upgrade-insecure-requests ve CSP raporlaması adımları.
• MDN — upgrade-insecure-requests — tam olarak neleri yükselttiği, neleri yükseltmediği ve neden HSTS’nin yerini tutmadığı.
• MDN — block-all-mixed-content — devraldığınızda karşılaşabileceğiniz kullanımdan kaldırılmış engelleme yönergesi.
• MDN — Karışık içerik — engellenebilir/yükseltilebilir kaynaklara ilişkin tarayıcı davranışı.
• Sunucularınızda HTTPS’i etkinleştirme (web.dev / Google) — göreli/protokole göreli URL’ler ve genel HTTPS kurulum rehberliği.

Alıntılamaya değer istatistikler

• Etkin karışık içerik varsayılan olarak engellenir. Google: “Most browsers already block this type of content by default to protect users.” (Türkçesi: Çoğu tarayıcı kullanıcıları korumak için bu içerik türünü varsayılan olarak engeller.) Bu yüzden etkin karışık içerik uyarı değil, işlevsel kesintidir. kaynak
• Etkin karışık içerik daha büyük tehdittir. Google’ın iki sınıfa ilişkin sıralaması: “Active mixed content poses a greater threat than passive mixed content.” (Türkçesi: Etkin karışık içerik, pasif karışık içerikten daha büyük tehdit oluşturur.) Öncelik sıranızı bu belirlemeli. kaynak
• Pasif karışık içerik artık güvenle “izin veriliyor” sayılamaz. Google: “Until recently, passive mixed content was loaded in all browsers … This is now beginning to change.” (Türkçesi: Yakın zamana kadar tüm tarayıcılarda yükleniyordu; bu artık değişmeye başlıyor.) “Görseller zararsızdır” varsayımı geçerliliğini yitiriyor. kaynak
• upgrade-insecure-requests, HSTS’nin yerine geçmez. MDN açıkça yönergenin “does not replace the Strict-Transport-Security (HSTS) header” olduğunu söyler (HSTS başlığının yerini tutmaz). İki denetim sorunun farklı yarılarını çözer. kaynak
• Web’in yaklaşık %89’u HTTPS kullanıyor (W3Techs, 2026; güncel rakamı doğrulayın). Tam da bu nedenle aksi hâlde güvenli sayfadaki kalan http:// alt kaynakları artık yaygın hata biçimidir: sayfa HTTPS’e geçer, yük geride kalır. Bağlam için HTTPS merkezine bakın.

Kendinizi sınayın: karışık içerik

Karışık içerik hakkında beş kısa soru. Her biri için yanıt seçip sonucu kontrol edin.

Değişiklik günlüğü