SSL (HTTPS) ve Temel Web Sitesi Güvenliği: 12 Maddelik Kontrol Listesi

Tuba Yazılım SEO ve Yazılım Ekibi · Yayın: 2026-10-07 · Son güncelleme: 7 Ekim 2026

Kısa cevap: SSL, tarayıcı ile web sunucusu arasındaki bağlantıyı şifreleyen teknolojinin yaygın adıdır; bugün kullanılan protokol TLS'tir ve güvenli sitelerin adresi HTTPS ile başlar. HTTPS aktarımı korur, ancak sitenin kodundaki açıkları, eski eklentileri ya da zayıf parolaları gidermez. Temel güvenlik bu yüzden katmanlıdır: geçerli sertifika, HTTPS yönlendirmesi, güvenlik başlıkları, güncellemeler, yedek, güçlü parola ve ikinci doğrulama, güvenli form ve dosya yükleme. Aşağıdaki 12 maddelik liste bu katmanları sırayla denetlemenizi sağlar.

SSL, TLS ve HTTPS tam olarak nedir?

HTTPS, HTTP trafiğinin TLS (Transport Layer Security) protokolüyle taşınmış hâlidir. "SSL sertifikası" deyimi günlük dilde hâlâ yaygındır, ancak MDN'nin anlattığı güncel protokol TLS'tir; güncel sürüm TLS 1.3'tür (RFC 8446), TLS 1.2 bazı sitelerde sürmektedir, TLS 1.0 ve 1.1 ise artık kullanılmamalıdır.

MDN'ye göre TLS bağlantıyı üç yönden korur: şifreleme (veri yolda okunamaz), bütünlük (veri yolda fark edilmeden değiştirilemez) ve kimlik doğrulama (sunucu, iddia ettiği site olduğunu kanıtlayabilir). Bu üçü, "site güvenli" cümlesinin gerçekte neyi kapsadığını da gösterir.

Kimlik doğrulamada sertifikanın rolü belirleyicidir. Sertifika, sitenin açık anahtarını alan adına bağlayan, dijital olarak imzalanmış bir belgedir; tarayıcı "örnek.com'a mı bağlandım?" sorusuna bu belgeyle cevap bulur. Let's Encrypt gibi kâr amacı gütmeyen bir sertifika otoritesi ücretsiz sertifika verebilir; yani sertifikanın varlığı ile maliyeti arasında doğrudan bir bağ yoktur.

HTTPS yalnızca bağlantıyı korur. Sitenizdeki yazılımın açıklarını kapatmaz; bunun için yazının sonraki bölümlerindeki başlıklar ve liste gerekir.

HTTPS Google için bir sıralama sinyali midir, tarayıcılar ne gösterir?

Google, Ağustos 2014'te Search Central blogunda HTTPS'i bir sıralama sinyali olarak kullanmaya başladığını duyurdu; o dönem bunu "çok hafif bir sinyal" olarak niteledi, küresel sorguların yüzde birinden azını etkilediğini ve yüksek kaliteli içerik gibi sinyallerden daha az ağırlık taşıdığını yazdı. Aynı yazı, zamanla bu sinyali güçlendirebileceklerini de söylüyordu.

Güncel resmî belge daha temkinlidir. Google'ın sayfa deneyimi rehberi (son güncelleme 22 Eylül 2026), "Sayfalarınız güvenli biçimde mi sunuluyor?" sorusunu sayfa deneyimi değerlendirmesinin bir parçası yapar; aynı rehber, Core Web Vitals dışındaki sayfa deneyimi unsurlarının sıralamada doğrudan yardımcı olmadığını, ama siteyi kullanımı daha memnun edici kıldığını belirtir. Dolayısıyla HTTPS'i bir sıralama aracı gibi değil, kullanıcıya ve aramaya karşı bir temel koşul olarak ele almak daha doğrudur. Sıralama artışı vaat edilemez.

Aynı 2014 yazısının uygulamaya dönük önerileri bugün de işe yarar: sayfa içi kaynaklarda göreli adresler kullanın, HTTPS sitenizi robots.txt ile taramaya kapatmayın ve sayfalarınıza gereksiz noindex etiketi koymayın.

Ziyaretçi tarafında etki daha görünürdür. Chrome yardım sayfasına göre güvenli bağlantıda özel bir simge görünür; HTTPS kullanmayan sitelerde "Güvenli değil" ifadesi ya da bilgi simgesi çıkar. Aynı sayfa, "Your connection is not private" (bağlantınız gizli değil) türünde tam sayfa bir hata mesajının sitedeki, ağdaki ya da cihazdaki bir sorunu gösterdiğini söyler. Süresi dolmuş ya da yanlış kurulmuş bir sertifika da tarayıcıda bu tür bir uyarıya yol açabilir; yani yalnızca teknik bir ayrıntı değil, ziyaretçinin siteye girmekte zorlanması demektir.

Güvenli bağlantı simgesi, sitenin içeriğinin ya da sahibinin güvenilir olduğunu söylemez. Chrome yardımı da güvenli bir bağlantıda bile hassas bilgi paylaşırken dikkatli olunmasını önerir.

DV, OV ve EV sertifikaları arasındaki fark nedir?

Üç kısaltma, sertifika otoritesinin sertifikayı vermeden önce neyi doğruladığını anlatır: DV (Domain Validated, alan adı doğrulamalı), OV (Organization Validated, kuruluş doğrulamalı) ve EV (Extended Validation, genişletilmiş doğrulamalı). CA/Browser Forum Baseline Requirements belgesindeki not, tüm bu türlerin cihaz kimliği (alan adı ya da IP adresi) bakımından aynı güvence düzeyini sağladığını belirtir. Yani seçim "hangisi daha güçlü şifreler?" sorusu değil, "sertifikada hangi kimlik bilgisi yer almalı?" sorusudur.

Let's Encrypt SSS sayfasına göre bu otorite yalnızca DV sertifika verir; OV ve EV vermez ve vermeyi planlamaz, çünkü bu türlerin verilişini otomatikleştiremez. Başka bir deyişle ücretsiz ve otomatik sertifika ile kuruluş doğrulamalı sertifika farklı ihtiyaçlara hizmet eder.

Tür	Kavramsal olarak neyi doğrular?	Hangi soruyla seçilir?
DV	Başvuranın alan adını denetlediğini doğrular.	Sadece şifreli bağlantı ve alan adı doğrulaması yeterli mi?
OV	Alan adına ek olarak kuruluşa ilişkin bilgilerin doğrulanmasını ister.	Sözleşme, kurum ya da iş ortağı kuruluş bilgisini sertifikada görmek istiyor mu?
EV	Kuruluşun, ayrı bir EV rehberine bağlı daha ayrıntılı doğrulanmasını ister.	Bir yükümlülük özellikle EV mi istiyor? Yoksa fark yalnızca kimlik bilgisinde mi?

Sertifika geçerlilik süreleri kısalıyor. Baseline Requirements v2.3.1'e (4 Ekim 2026) göre 15 Mart 2026'dan önce verilen sertifikalar için üst sınır 398 gün, 15 Mart 2026 ile 15 Mart 2027 arasında verilenler için 200 gün, 15 Mart 2027 ile 15 Mart 2029 arasında verilenler için 100 gün, 15 Mart 2029'dan sonra verilenler için 47 gündür. Let's Encrypt'in varsayılan sertifikası 90 gündür ve 60 günde bir yenilemeyi önerir. Elle yenileme bu yüzden sürdürülebilir değildir; otomatik yenileme ve bitiş tarihi takibi gerekir.

HSTS nedir ve karışık içerik nasıl giderilir?

HSTS (HTTP Strict Transport Security), sunucunun tarayıcıya "bu siteye yalnızca HTTPS ile bağlan" demesini sağlayan bir yanıt başlığıdır. MDN'ye göre tarayıcı HTTP isteklerini kendisi HTTPS'e çevirir ve geçersiz sertifika uyarısının kullanıcı tarafından atlanmasına izin vermez. Bu ikinci özellik önemlidir: HSTS gönderen bir sitede sertifika süresi dolarsa ziyaretçi uyarıyı geçip siteye giremez.

HSTS'in sınırları da vardır. Tarayıcı başlığı yalnızca HTTPS yanıtında dikkate alır, HTTP üzerinden gelen başlık yok sayılır; ilk ziyaret bu yüzden korumasızdır. max-age tarayıcının kuralı ne kadar süre hatırlayacağını saniye cinsinden belirler; includeSubDomains kuralı alt alan adlarına yayar; preload ise alan adının tarayıcıların hazır listesine girmesini sağlar ve MDN'ye göre en az bir yıllık max-age ile includeSubDomains gerektirir. Geri almak zordur: HSTS'i kapatmak için HTTPS üzerinden max-age=0 göndermek gerekir ve bunun etkili olması için tarayıcının siteyi yeniden ziyaret etmesi gerekir.

Karışık içerik (mixed content), HTTPS ile açılan bir sayfanın içinde görsel, betik ya da stil dosyasının HTTP ile yüklenmesidir. MDN'ye göre tarayıcılar betik, stil dosyası, iframe ve fetch gibi sayfayı değiştirebilen kaynakları engeller; görsel, ses ve video gibi kaynakları ise otomatik olarak HTTPS'e yükseltir. Çözüm, tüm kaynakları HTTPS ya da göreli adresle çağırmaktır. Content-Security-Policy: upgrade-insecure-requests yönergesi güvenlik ağı olarak kullanılabilir, ancak tek tek adresleri düzeltmenin yerini tutmaz.

HSTS'i ve karışık içerik denetimini şu sırayla uygulamak, siteyi kilitleme riskini azaltır:

HTTPS'in tüm sayfalarda ve alt alan adlarında sorunsuz çalıştığından, yönlendirmede döngü olmadığından emin olun.
Sayfaları tarayıcı geliştirici araçlarının konsolunda açın; karışık içerik uyarısı görünen her adresi HTTPS'e çevirin.
HSTS'i kısa bir süreyle açın: Strict-Transport-Security: max-age=300 (beş dakika). Tarayıcıda ve formlarınızda sorun çıkmıyorsa devam edin.
Süreyi bir haftaya (max-age=604800), ardından bir aya (max-age=2592000) çıkarın; her aşamada kırık sayfa olup olmadığını izleyin. Google'ın işlettiği hstspreload.org bu aşamaları includeSubDomains ile birlikte örnekler; iç alt alan adları dahil tüm alt alan adlarınız HTTPS ile çalışmıyorsa includeSubDomains eklemeyin.
Her şey kararlıysa bir yıllık süreye (max-age=31536000) geçin. Preload listesine girmek ayrı ve geri alması zor bir karardır; önce alt alan adlarınızın tamamını denetleyin.

Hangi güvenlik başlıklarıyla başlanmalı ve örnek yapılandırma nasıl olur?

Güvenlik başlıkları, sunucunun tarayıcıya "bu sayfayla şunları yapma" diyen kurallarıdır. OWASP, sunucunun güvenlik başlıklarını hiç göndermemesini ya da güvenli olmayan değerlerle göndermesini güvenlik yanlış yapılandırması (A02:2025) örnekleri arasında sayar. Aşağıdaki tablo, bir kurumsal sitede başlangıç için dört satırda bu başlıkları toplar; HSTS bir önceki bölümde anlatıldı, diğerleri aşağıda açıklanıyor.

X-Frame-Options ile frame-ancestors aynı işi yapar: sayfanızın başka bir sitenin iframe'i içinde gösterilmesini engelleyerek clickjacking'e (kullanıcıyı gizli bir sayfaya tıklatma) karşı koruma sağlar. MDN, sayfanın gömülmesi gerekmiyorsa frame-ancestors 'none' kullanılmasını önerir ve frame-ancestors'ı X-Frame-Options başlığının daha esnek bir karşılığı olarak tanıtır. İkisi de yalnızca HTTP başlığı olarak çalışır; meta etiketiyle verilirse etkisizdir.

Content-Security-Policy (CSP) ise tarayıcıya hangi kaynaklardan hangi kodun çalışabileceğini söyler. MDN'ye göre ana kullanım alanı XSS'e karşı derinlemesine savunmadır; default-src ya da script-src içeren bir CSP satır içi JavaScript'i varsayılan olarak engeller. MDN 'unsafe-inline' kullanımından kaçınılmasını, nonce ya da hash tabanlı sıkı politikaların tercih edilmesini söyler. CSP'yi doğrudan uygulamak siteyi bozabileceği için önce Content-Security-Policy-Report-Only başlığıyla denemek mümkündür: politika uygulanmaz, yalnızca ihlal raporu üretilir.

Başlık	Ne yapar?	Dikkat edilecek nokta
X-Content-Type-Options: nosniff	Tarayıcının içeriğin türünü tahmin etmesini engeller; betik ve stil dosyalarında tür uyuşmazsa isteği engeller.	Sunucunun doğru Content-Type gönderdiğinden emin olun; MDN'ye göre betik ve stil isteklerinde tür uyuşmazsa yanıt engellenir.
frame-ancestors (CSP) ve X-Frame-Options	Sayfanın başka sitelerde iframe içinde gösterilmesini engeller (clickjacking).	Haritanız ya da bir ödeme bileşeni sizin sayfanızı gömüyorsa 'none' kullanmayın; ALLOW-FROM eskidir.
Content-Security-Policy	Hangi kaynaklardan betik, görsel ve stil yüklenebileceğini sınırlar; XSS riskini azaltır.	Üçüncü taraf betikler (ölçüm, harita, sohbet) engellenebilir; önce Report-Only ile deneyin.
Strict-Transport-Security	Tarayıcıyı siteye yalnızca HTTPS ile bağlanmaya zorlar.	Kısa max-age ile başlayın; sertifika süresi dolarsa ziyaretçi uyarıyı atlayamaz.

Apache .htaccess için güvenlik başlıkları örneği

# ÖNCE TEST ORTAMINDA DENEYİN. Bu dosyanın yedeğini alın.
# Bu örnek yalnızca Apache (mod_headers) için geçerlidir.
<IfModule mod_headers.c>
  # MIME türü tahminini kapatır.
  Header always set X-Content-Type-Options "nosniff"

  # Siteniz yalnızca kendi sayfalarında iframe içinde görünebilir.
  Header always set X-Frame-Options "SAMEORIGIN"
  Header always set Content-Security-Policy "frame-ancestors 'self'"

  # CSP'yi önce yalnızca raporlama modunda deneyin; engellemez.
  # Kendi kaynaklarınıza göre düzenleyin (ölçüm kodu, harita, yazı tipi vb.).
  Header always set Content-Security-Policy-Report-Only "default-src 'self'; img-src 'self' data:; object-src 'none'; base-uri 'self'"

  # HSTS: yalnızca HTTPS sorunsuz çalışıyorsa ve önce KISA sürelerle.
  # Kararlıysa 604800, 2592000, en son 31536000 değerine çıkın.
  Header always set Strict-Transport-Security "max-age=300"
</IfModule>

Apache belgesine göre 'always' koşulu, başlığın hata yanıtlarına da eklenmesini ve iç yönlendirmelerde (örneğin ErrorDocument) korunmasını sağlar. Nginx kullanıyorsanız .htaccess çalışmaz; MDN aynı başlıklar için add_header örnekleri verir. Başlıkları ekledikten sonra sitenizi, formlarınızı ve ölçüm kodlarınızı tarayıcıda deneyin; Report-Only ile görülen ihlaller temizlenmeden CSP'yi zorunlu hâle getirmeyin.

Güvenlik başlıkları siteyi bozabilir: sıkı bir CSP üçüncü taraf betikleri, HSTS ise sertifika sorunu olan alt alan adlarını erişilmez yapabilir. Önce test ortamında deneyin, yedek alın ve değişikliği tek tek uygulayın.

OWASP'a göre en temel riskler nelerdir: enjeksiyon, kırık erişim denetimi, güncel olmayan bileşenler?

OWASP Top 10, web uygulamalarındaki en kritik güvenlik risklerinin uzlaşıya dayalı bir listesidir; bu yazıda okunan sürüm 2025'tir. Listenin tamamı site sahibi için gerekli değildir, ancak aşağıdaki üç başlık küçük kurumsal sitelerde de karşılaşılan temel risklerdir. Teknik düzeltmeler sitenin yazıldığı yazılıma bağlıdır; site sahibi olarak amacınız doğru soruyu doğru kişiye sormaktır.

Enjeksiyon (A05:2025): OWASP, bunu güvenilmeyen kullanıcı girdisinin bir yorumlayıcıya (veritabanı, tarayıcı, komut satırı) gönderilip komut olarak çalıştırılması diye tanımlar. SQL enjeksiyonu ve XSS bu sınıfa girer. Önlemin özü veriyi komuttan ayırmaktır; OWASP öncelikli yolu, parametreli bir arayüz sunan güvenli bir API kullanmak olarak gösterir. CMS ya da hazır yazılım kullanıyorsanız bu iş büyük ölçüde yazılımın veritabanı katmanındadır; kendi yazdığınız form ve sorgu kodları ise ayrıca denetlenmelidir.

Kırık erişim denetimi (A01:2025): Kullanıcıların kendilerine verilen izinlerin dışına çıkamaması gerekir. OWASP'ın örnekleri arasında adresi değiştirerek yetkisiz sayfaya ulaşmak, bir kimlik numarasını değiştirerek başkasının hesabını görmek ve oturum açmadan yönetici sayfasına erişmek vardır. OWASP bu kategorinin test edilen uygulamaların tamamında bir biçimde bulunduğunu belirtir; ilke, varsayılan olarak reddetmek ve yalnızca gerekli yetkiyi vermektir.

Güncel olmayan bileşenler: OWASP'ın 2025 listesinde bu risk "Yazılım Tedarik Zinciri Hataları" (Software Supply Chain Failures, A03:2025) başlığında genişletilmiştir; OWASP, riskin 2013'te "bilinen açıklara sahip bileşenlerin kullanımı" olarak listeye girdiğini ve kapsamın o günden bu yana büyüdüğünü yazar. Güncel olmayan işletim sistemi, web sunucusu, veritabanı, eklenti ve kütüphaneler bu başlığa girer; bileşen sürümlerini takip etmemek ve açıkları düzenli taramamak OWASP'ın riskli saydığı durumlardandır.

Risk	Basit anlatımı	Site sahibi olarak sorulacak soru
Enjeksiyon (SQL, XSS)	Kullanıcıdan gelen veri komut gibi çalışır.	Form ve arama kutularındaki veri sorguya parametre olarak mı geçiyor, sayfaya yazılırken kodlanıyor mu?
Kırık erişim denetimi	Kullanıcı izni olmayan sayfa ya da kayda ulaşır.	Giriş yapmadan ya da düşük yetkiyle yönetim adreslerine girilebiliyor mu? Gereksiz yönetici hesabı var mı?
Güncel olmayan bileşenler	Eski yazılımın bilinen açıkları kullanılır.	CMS, tema, eklenti ve sunucu yazılımı güncel mi, kullanılmayanlar kaldırıldı mı?

Güncelleme, yedekleme, parola, ikinci doğrulama, form ve dosya yükleme güvenliği sahada nasıl uygulanır?

Google'ın web.dev'deki hacklenmiş siteler rehberi, uzun vadeli bakım için şunları güçlü biçimde önerir: sitenin düzenli ve otomatik yedeğini almak, yazılımları güncel tutmak, kurmadan önce uygulama ve eklentilerin güvenlik uygulamalarını anlamak, güçlü parola zorlamak ve siteye giriş yapılan cihazları (işletim sistemi, tarayıcı) güncel tutmak. Aynı rehber, kullanılmayan eklenti ve uygulamaların sunucudan kaldırılmasını da ister. Yedeğin dosyaları, veritabanını ve görselleri içermesi gerekir; yedeğin işe yaradığını anlamanın yolu geri yüklemeyi denemektir.

Parola ve ikinci doğrulama için OWASP'ın Kimlik Doğrulama Cheat Sheet'i, ikinci doğrulamayı (MFA) parolaya yönelik saldırıların çoğuna karşı en güçlü savunma olarak niteler ve mümkün olan her yerde kullanılmasını söyler. Aynı kaynak NIST SP 800-63B'ye atıfla, MFA açıkken sekiz karakterden, MFA yokken on beş karakterden kısa parolaları zayıf sayar. Yönetim paneli, barındırma hesabı, alan adı hesabı ve e-posta için benzersiz parola ve ikinci doğrulama, bu yüzden öncelikli bir adımdır.

Formlar için temel ilke, kullanıcıdan gelen her veriye sunucu tarafında güvenmemektir: veriyi doğrulayın, veritabanına parametreli sorguyla yazın, sayfada gösterirken bağlama uygun kodlayın. Oturum açılmış işlemleri yapan formlarda OWASP'ın CSRF önleme rehberi, sunucunun ürettiği ve her istekle doğrulanan jetonları (senkronizör jeton) anlatır.

Dosya yükleme alanları ayrı bir risk taşır. OWASP Dosya Yükleme Cheat Sheet'i, tek bir tedbirin yetmediğini ve katmanlı savunma gerektiğini vurgular. Başlıca ilkeler şunlardır:

Yalnızca iş için gereken uzantıları izin listesiyle kabul edin; .jpg.php gibi çift uzantı ve büyük/küçük harf hilelerini hesaba katın, uzantıyı doğrulamadan önce dosya adına girdi doğrulaması uygulayın.
Content-Type başlığına güvenmeyin; bu başlık taklit edilebilir. Dosya türünü kendiniz doğrulayın.
Dosya adını uygulamanın ürettiği bir adla değiştirin; ad uzunluğunu ve dosya boyutunu sınırlayın.
Yalnızca yetkili kullanıcıların yüklemesine izin verin.
Dosyaları web kök dizininin dışında ya da ayrı bir sunucuda saklayın; mümkünse antivirüsten ya da korumalı alandan (sandbox) geçirin.

12 maddelik temel web sitesi güvenliği kontrol listesi nedir?

Aşağıdaki liste, bu yazıdaki başlıkları sıraya koyan pratik bir denetim aracıdır. Her maddeyi "evet", "hayır" ya da "bilmiyorum" diye işaretleyin; "bilmiyorum" cevapları, barındırıcınıza ya da siteyi yapan kişiye sorulacak sorulardır. Liste OWASP'ın ya da başka bir kurumun resmî sınıflandırması değil, bu yazının derlediği bir çerçevedir; her madde yukarıda atıf yapılan kaynaklara dayanır.

Listeyi kendiniz uygulayamazsanız Tuba Yazılım sunucu, hosting ve DevOps desteği verir; web sitesi güvenliği ve SSL için ayrı hizmet sayfaları da vardır. Hangi işlerin kapsama gireceği teklif aşamasında yazılı netleştirilir; çalışma için sizden sunucu ya da panel erişimi ve değişikliklere onay beklenir. Bu yazı bir güvenlik denetimi değildir ve bir korumayı taahhüt etmez.

#	Madde	Nasıl doğrulanır?
1	Sertifika geçerli; hem alan adı hem www sürümü kapsanıyor.	Her iki adresi tarayıcıda açın; uyarı çıkmamalı.
2	HTTP adresleri tek adımda ve kalıcı olarak HTTPS'e yönleniyor, döngü yok.	http:// ile açın; adresin HTTPS'e geçtiğini ve zincir oluşmadığını görün.
3	Sertifika otomatik yenileniyor ve bitiş tarihi takip ediliyor.	Yenileme ayarını ve sertifikanın bitiş tarihini kontrol edin.
4	Karışık içerik yok.	Tarayıcı geliştirici araçları konsolunda sayfaları gezin; HTTP uyarısı çıkmamalı.
5	HSTS kademeli ve doğru kurulmuş.	Yanıt başlığında Strict-Transport-Security görünmeli; süre kademeli artırılmış olmalı.
6	nosniff, frame-ancestors/X-Frame-Options ve (en az Report-Only) CSP başlıkları gönderiliyor.	curl -I ile ya da tarayıcının ağ sekmesinde yanıt başlıklarına bakın.
7	CMS, tema, eklenti ve sunucu yazılımı güncel; kullanılmayanlar kaldırılmış.	Yönetim panelindeki güncelleme listesini ve eklenti dökümünü gözden geçirin.
8	Yönetici ve barındırma hesaplarında benzersiz güçlü parola ve ikinci doğrulama var.	Her kritik hesabın güvenlik ayarlarını açıp doğrulayın.
9	Düzenli, otomatik yedek var ve geri yükleme denenmiş.	Son yedeğin tarihine bakın; test ortamında geri yüklemeyi deneyin.
10	Formlar sunucu tarafında doğrulanıyor, sorgular parametreli, çıktı kodlanıyor, CSRF jetonu kullanılıyor.	Siteyi yazan kişiye ya da yazılımın belgesine sorun; özel kodsa kod incelemesi isteyin.
11	Dosya yüklemede izin listesi, boyut sınırı, yeniden adlandırma ve web kökü dışı saklama var.	Test ortamında izinsiz bir uzantıyla yüklemeyi deneyin (reddedilmeli); yüklenen dosyanın adresini ve saklandığı yeri inceleyin.
12	Yetkiler en az düzeyde; gereksiz hesap yok, yönetim adreslerine giriş yapmadan erişilemiyor.	Kullanıcı ve rol listesini temizleyin; çıkış yapmış bir tarayıcıda yönetim adreslerini deneyin.

Bu liste bir başlangıçtır, sitenizin saldırıya uğramayacağı anlamına gelmez. Güvenlik sürekli bakım gerektirir; liste yalnızca sık görülen eksikleri yakalamaya yöneliktir.

Sık sorulan sorular

SSL ile TLS aynı şey midir?

Günlük dilde "SSL sertifikası" deyimi yaygındır; ancak MDN'nin açıkladığı ve bugün kullanılan protokol TLS'tir. HTTPS, HTTP'nin TLS ile taşınmış hâlidir. Güncel sürüm TLS 1.3'tür; TLS 1.0 ve 1.1 artık kullanılmamalıdır.

HTTPS kullanmak tek başına Google'da sıralamamı yükseltir mi?

Kesin bir sonuç vaat edilemez. Google 2014'te HTTPS'i "çok hafif" bir sıralama sinyali olarak duyurdu; güncel sayfa deneyimi rehberi ise Core Web Vitals dışındaki unsurların doğrudan sıralamaya yardımcı olmadığını, ama siteyi daha memnun edici kıldığını söyler. HTTPS'i bir temel gereklilik olarak düşünün.

Sertifikam süresi dolarsa ne olur ve ne sıklıkla yenilenir?

Tarayıcı, sertifika sorunlarında çoğunlukla tam sayfa bir uyarı gösterir (Chrome yardımı bu tür tam sayfa hata mesajlarını anlatır); HSTS kullanıyorsanız MDN'ye göre ziyaretçi uyarıyı atlayıp siteye giremez. Yenileme sıklığı sertifikaya bağlıdır: Let's Encrypt sertifikaları 90 gün geçerlidir ve 60 günde bir yenilenmesi önerilir; genel üst sınırlar da kısalmaktadır. Otomatik yenileme ve bitiş tarihi takibi bu yüzden gereklidir.

Ücretsiz sertifika yeterli midir?

Alan adı doğrulaması ve şifreli bağlantı yeterliyse DV sertifika işi görür; Let's Encrypt gibi otoritelerin ücretsiz sertifikaları DV türündedir. Baseline Requirements'a göre DV, OV ve EV aynı alan adı kimliği güvencesini sağlar; fark sertifikada yer alan kuruluş bilgisindedir. Sözleşmeniz ya da sektörünüz kuruluş doğrulamalı sertifika istiyorsa o şartı kaynağından teyit edin.

HSTS'i hemen bir yıllık süreyle açabilir miyim?

Google'ın işlettiği hstspreload.org kısa bir max-age ile (5 dakika) başlayıp aşamalı artırmayı (1 hafta, 1 ay) önerir. Çünkü MDN'ye göre tarayıcı kuralı süre boyunca hatırlar ve sertifika uyarısının atlanmasına izin vermez. Preload ise en az bir yıllık süre ve includeSubDomains ister; önce tüm alt alan adlarınızı denetleyin.

Güvenlik başlıkları eklemek sitemi bozar mı?

Bozabilir. Sıkı bir CSP üçüncü taraf betikleri (ölçüm, harita, sohbet gibi) engelleyebilir; frame-ancestors 'none' sayfanızı gömen bir bileşeni durdurabilir. CSP'yi önce Report-Only ile deneyin, başlıkları tek tek ekleyin ve her adımdan sonra sitenizi ve formlarınızı test edin.

Güvenlik başlıklarının gelip gelmediğini nasıl kontrol ederim?

Komut satırında curl -I https://siteniz.com yazarak ya da tarayıcının geliştirici araçlarındaki ağ sekmesinde ana sayfa isteğinin yanıt başlıklarına bakarak kontrol edebilirsiniz. Beklenen başlıklar X-Content-Type-Options, Strict-Transport-Security ve CSP ile ilgili olanlardır.

Dosya yükleme formum varsa en önemli önlem nedir?

OWASP tek bir önlemin yetmediğini söyler. Yine de başlangıç için izin verilen uzantıları listelemek, Content-Type başlığına güvenmemek, dosya adını sizin üretmeniz, boyutu sınırlamak, yüklemeyi yalnızca yetkili kullanıcılara açmak ve dosyaları web kök dizininin dışında saklamak temel adımlardır.

Bu konuda destek almak isterseniz

Sertifika, HTTPS yönlendirmesi ve yenileme konularında destek kapsamı teklif aşamasında yazılı netleştirilir.

SSL sertifikası

Temel güvenlik bakımı ve güvenlik başlıkları gibi işlerin kapsamı teklif aşamasında yazılı netleştirilir.

Web sitesi güvenliği Ücretsiz teklif alın WhatsApp