Web Sitesi Güvenliği: XSS, SQL Injection, HTTPS ve Hacklenen Site İçin Rehber

Tuba Yazılım · Son güncelleme: 2 Ekim 2026

Kısa cevap: Web sitesi güvenliği tek bir ayar değil, katmanlı bir kontrol listesidir: HTTPS ile sunum, güncel yazılım ve eklentiler, XSS'e karşı bağlama uygun çıktı kodlama, SQL injection'a karşı parametreli sorgular, güçlü parola ve güvenli oturum yönetimi, yedekleme. WAF, uygulama düzeyinde HTTP trafiğine kural uygulayan bir koruma katmanıdır; OWASP'ın cheat sheet'leri birincil savunmayı kodda tanımlar. Bu sayfa OWASP, Google ve MDN kaynaklarına dayanan genel bir rehberdir ve bir hizmet kataloğu değildir.

📝 Ücretsiz teklif alın 💬 WhatsApp 📞 0216 393 10 07

Web Sitesi Güvenliği: bir bakışta

Konu	Web sitesi güvenliğinin temel başlıkları: HTTPS, güncellemeler, XSS, SQL injection, parola ve oturum, yedekleme, WAF ve site hacklenirse yapılacaklar.
Kime yönelik	Kurumsal web sitesi sahipleri; kendi sitesinin güvenlik durumunu anlamak, geliştiriciye ya da barındırma sağlayıcısına doğru soru sormak isteyenler.
Dayanak	OWASP (Top 10:2025, XSS, SQL Injection ve Cheat Sheet serisi), Google Search Central ve Search Console yardımı, Google'ın web.dev rehberleri, MDN güvenlik sayfaları.
Kendiniz kontrol edebilecekleriniz	Sitenin HTTPS ile açılması, yönetici hesapları ve eklenti listesi, yedeğin varlığı, Search Console'daki Güvenlik Sorunları raporu.
Kod tarafı	Sorgu ve şablon kodu (XSS ile SQL injection önlemleri) sitenin yazıldığı yazılıma bağlıdır; bu kontroller kodu yazan kişi ya da ekip tarafından yapılmalıdır.
Garanti edilmeyenler	Bu rehberdeki adımlar bir sitenin saldırıya uğramayacağı anlamına gelmez; güvenlik sürekli bakım gerektirir.
Tuba Yazılım ile çalışma	Merkez İstanbul/Pendik; hizmetler 81 ilde uzaktan verilir. Ücret teklifle belirlenir.
Paket kalemleri	Günlük otomatik yedekleme Profesyonel, Kurumsal ve Pro Plus paketlerinde, ücretsiz SSL ise hosting paketlerinde (/kategori/hosting) paket kalemi olarak yer alır; bunlar ayrı bir güvenlik hizmeti anlamına gelmez.

Ücret ve kapsam

Ücret: kapsama göre teklifle belirlenir

Hedefler, sayfa/içerik hacmi ve gereken teknik işler netleştikten sonra yazılı bir teklif hazırlanır. Bu sayfada sabit bir tutar yayımlamıyoruz; teklif talebiniz için formu veya WhatsApp'ı kullanabilirsiniz.

Web sitesi güvenliği nasıl sağlanır? Yedi başlıkta kontrol listesi

MDN, web sitesi güvenliğini siteyi ve kullanıcıları kötü niyetli saldırganların vereceği zarardan korumak olarak anlatır ve bu zararın itibar, finans ya da fiziksel boyutta olabileceğini, özel olması gereken verileri hedef alabileceğini belirtir. Önlemler tek bir noktada toplanmaz. OWASP Top 10:2025 de tek bir açığı değil, geliştiriciler ve web uygulaması güvenliği için bir farkındalık belgesi olarak on risk kategorisini sıralar: A01 Broken Access Control, A02 Security Misconfiguration, A03 Software Supply Chain Failures, A04 Cryptographic Failures, A05 Injection, A06 Insecure Design, A07 Authentication Failures, A08 Software or Data Integrity Failures, A09 Security Logging and Alerting Failures ve A10 Mishandling of Exceptional Conditions.

Aşağıdaki yedi başlık bu sayfanın kendi çerçevesidir, OWASP ya da Google'ın resmî bir sınıflandırması değildir; her başlığın dayanağı sayfanın altındaki kaynaklardadır. Kontrollerin bir kısmını site yöneticisi olarak kendiniz doğrulayabilirsiniz: adresin HTTPS ile açılması, yönetici hesapları, eklenti listesi ve yedek gibi. XSS ile SQL injection önlemleri ise sitenin kodunda uygulanır ve kodu yazan kişiye sorulması gereken sorulardır.

HTTPS: site ve alt kaynakları HTTPS üzerinden mi sunuluyor, HTTP adresleri kalıcı olarak HTTPS'e yönleniyor mu?
Güncellemeler: işletim sistemi, CMS, tema, eklenti ve kütüphaneler güncel mi, kullanılmayanlar kaldırıldı mı?
Çıktı kodlama (XSS): kullanıcıdan gelen veri sayfaya yazılırken bağlama uygun biçimde kodlanıyor mu?
Parametreli sorgular (SQL injection): kullanıcı girdisi sorgu metnine eklenmek yerine parametre olarak mı geçiyor?
Parola ve oturum: parolalar güçlü ve benzersiz mi, ikinci doğrulama açık mı, oturum çerezleri korunuyor mu?
Yedekleme: yedekler düzenli ve otomatik alınıyor mu, güncel bir yedek mevcut mu?
İzleme ve hazırlık: günlük kayıtlarına bakılıyor mu, site hacklenirse ilk adımın ne olduğu ve kime ulaşılacağı biliniyor mu?

XSS (Cross-Site Scripting) nedir ve nasıl önlenir?

XSS, OWASP'ın tanımıyla zararlı betiklerin güvenilen, zararsız sitelere enjekte edildiği bir enjeksiyon türüdür: saldırgan bir web uygulamasını kullanarak, genellikle tarayıcı tarafında çalışan bir betik biçimindeki kodu başka bir kullanıcıya gönderir. OWASP genel olarak iki ana türden söz eder. Yansıyan (reflected) XSS'te girdi, hata mesajı ya da arama sonucu gibi bir yanıtta sunucudan geri döner; saklanan (stored) XSS'te zararlı betik veritabanı, yorum alanı ya da ziyaretçi kaydı gibi bir yerde kalıcı olarak durur. DOM tabanlı XSS üçüncü, daha az bilinen türdür ve OWASP'ın sınıflamasında istemci tarafı XSS'in alt kümesidir. MDN ise sorunu istemci tarafı ve sunucu tarafı oluşturma (rendering) açısından anlatır.

OWASP'a göre sonuçlar arasında oturum çerezinin ele geçirilip hesabın kaçırılması, kullanıcıların saldırganın sitesine yönlendirilmesi ve sayfa içeriğinin değiştirilmesi bulunur. OWASP'ın XSS Önleme Cheat Sheet'i çıktı kodlamayı ve gerektiğinde HTML temizlemeyi (sanitization) temel savunma sayar; HTTP filtresi gibi merkezi bir noktada yapılan işlemin, verinin sayfanın hangi bağlamına yazılacağını bilemediğini de belirtir. Aşağıdaki maddeler bu cheat sheet ile MDN'nin XSS sayfasının özetidir.

Çıktı kodlama: veri HTML içeriğine, HTML özniteliğine, JavaScript'e, CSS'e ya da URL'ye yazılırken her bağlam için ayrı kodlama gerekir. HTML içeriğinde özel karakterler HTML varlıklarına çevrilir; özniteliklerde değerler her zaman tırnak içine alınır.
Framework kullanımı: modern framework'ler şablonlarda otomatik kaçış sağlar, ancak React'in dangerouslySetInnerHTML ya da Angular'ın bypassSecurityTrust ailesi gibi kaçış kapıları bu korumayı devre dışı bırakır; bunların kullanıldığı yerler gözden geçirilmelidir.
Temizleme (sanitization): kullanıcıların HTML yazmasına izin veriliyorsa DOMPurify gibi bir kütüphane tehlikeli HTML'i ayıklar.
İçerik Güvenlik Politikası (CSP): OWASP CSP'yi derinlemesine savunma katmanı olarak görür, tek başına yeterli saymaz; MDN de sıkı bir CSP kurmayı önerir.

SQL injection nedir ve nasıl önlenir?

OWASP, SQL injection saldırısını istemciden gelen girdi verisi yoluyla uygulamaya bir SQL sorgusunun eklenmesi ya da enjekte edilmesi olarak tanımlar. Başarılı bir saldırıyla hassas veritabanı verisi okunabilir, kayıtlar değiştirilebilir, eklenebilir ya da silinebilir, veritabanı üzerinde yönetici işlemleri çalıştırılabilir; OWASP bazı durumlarda işletim sistemi komutlarının verilebildiğini de belirtir. MDN'nin örneği, kullanıcı adının sorgu metnine doğrudan eklendiği bir kodun, girdiye eklenen ek bir SQL komutuyla bir tabloyu silecek biçimde çalışabildiğini gösterir.

Önlemin özü, SQL kodunu ve veriyi birbirinden ayırmaktır. OWASP'ın SQL Injection Önleme Cheat Sheet'i dört savunma seçeneği sıralar ve ilk tercih olarak hazır ifadeleri (parametreli sorgular) gösterir. Siteniz bir CMS ya da hazır yazılım kullanıyorsa bu işi büyük ölçüde yazılımın veritabanı katmanı yapar; özel kodlanmış sorgular ise kodu yazan kişi tarafından kontrol edilmelidir.

Hazır ifade (parametreli sorgu): önce SQL kodu yazılır, sonra her parametre sorguya ayrıca geçirilir; böylece veritabanı kodu ve veriyi ayırt eder. MDN de ham SQL yerine Django modelleri gibi kapsüllenmiş arayüzlerin kullanılmasını önerir.
Saklı yordamlar (stored procedures): güvenli yazıldıklarında parametreli sorgularla eşdeğer koruma sağlar; yordamın içinde güvenli olmayan dinamik SQL üretiliyorsa bu koruma kaybolur.
İzin verilenler listesiyle doğrulama: tablo adı, sütun adı ya da sıralama yönü gibi parametreyle bağlanamayan yerlerde OWASP bunu en uygun savunma olarak gösterir; değerler önceden belirlenmiş meşru adlara eşlenir. Girdi doğrulaması tek başına parametreli sorgunun yerini tutmaz.
Kaçışlama: OWASP bu yöntemi kırılgan bulur ve tüm durumlarda SQL injection'ı önleyeceğini garanti edemeyeceğini yazar; mümkünse kaçınılması gerekir.
En az yetki: uygulamanın veritabanı hesabına yalnızca gereken haklar verilir, yönetici yetkisi verilmez; başarılı bir saldırının vereceği zarar azalır.

Web sitesi hacklenirse ne yapılmalı? Google'ın önerdiği sıra

Google'ın web.dev'deki hacklenmiş siteler rehberi, önce sitenin gerçekten hacklenip hacklenmediğinin doğrulanmasıyla başlar; rehberin makaleleri arasında tespit, destek ekibi kurma, karantina, kök neden araştırması, temizlik ve bakım ile inceleme isteği yer alır. Rehber, saldırganların site sahibine farklı, arama motoruna farklı içerik gösterebildiğini (cloaking) ve bu yüzden bir hack'in sahibi için görünmez kalabildiğini de anlatır.

Karantina adımında Google, siteyi içerik sunmaz hâle getirmeyi (web sunucusunu durdurmak ya da DNS'i başka bir sunucudaki, 503 yanıtı veren sabit bir sayfaya yönlendirmek) ve barındırıcıyı durumdan haberdar etmeyi söyler. robots.txt ile engellemenin ve tek başına 4xx ya da 5xx durum kodlarının kullanıcıları zararlı içerikten korumaya yetmediğini de ekler. Aynı sayfa, kurtarma sürecinde sitenin geçici ya da zaman zaman kapalı kalmasının gelecekteki sıralamayı etkilemesinin olası olmadığını belirtir.

Temizlik aşamasında rehber şu yolu izler:

Parolaları değiştirin: FTP, veritabanı, sistem yöneticisi ve CMS hesaplarının parolaları süreç boyunca birkaç aşamada, temizliğin sonunda bir kez daha değiştirilir.
Yedeğin durumuna göre ilerleyin: temiz ve güncel bir yedeğiniz varsa geri yüklersiniz; temiz ama eski bir yedek varsa onu sunucuda geri yüklersiniz; hiç yedek yoksa site hâlâ enfekteyken bile iki yedek almanız önerilir. Disk görüntüsü ya da klon sürüm, geri yüklemeyi kolaylaştırır.
Yalnızca yükseltme değil, temiz kurulum yapın: yükseltmeler önceki sürümden kalan dosyaları bırakabilir. Sunucuda sitenin artık kullanmadığı widget, eklenti ve uygulamaları kaldırmayı da değerlendirin.
Kök nedeni bulun: Google yönetici bilgisayarlarında virüs taraması, zayıf ya da tekrar kullanılmış parolalar, eski yazılım ve güvenli olmayan kodlama (açık yönlendirme, SQL injection gibi) olmak üzere dört alanın incelenmesini söyler. Kök neden araştırması sırasında günlüklerde bir yönetici için çok sayıda giriş denemesi ya da beklenmedik komutlar, veritabanında ise normal metin alanlarında iframe ya da betik aranır.
İnceleme isteği gönderin: hacklenmiş siteler ve zararlı yazılım için Search Console'daki Güvenlik Sorunları raporu üzerinden yapılır; Google temizliği kısaca açıklamanızı önerir (örneğin güncel olmayan bir eklentiyi güncelleyip spam içeriği kaldırdığınızı). Karar gelmeden yeniden göndermemeniz istenir; Search Console yardımı incelemenin birkaç gün ya da hafta sürebildiğini belirtir.

WAF (Web Uygulaması Güvenlik Duvarı) nedir?

OWASP'a göre WAF, HTTP uygulamaları için bir uygulama güvenlik duvarıdır ve bir HTTP konuşmasına bir dizi kural uygular. Genellikle XSS ve SQL injection gibi yaygın saldırıları ele alır. Kullanıcıları koruyan geleneksel vekil sunuculardan farklı olarak WAF sunucuları korur ve ters vekil sunucu olarak düşünülebilir. Cihaz, sunucu eklentisi ya da filtre olarak uygulanabilir ve bir uygulamaya göre özelleştirilebilir.

WAF kurmak tek başına yeterli sayılmaz: OWASP'ın cheat sheet'leri birincil savunmayı kodda (çıktı kodlama, parametreli sorgu) tanımlar. OWASP ayrıca WAF'ın uygulamaya göre özelleştirilmesinin ciddi emek isteyebildiğini ve uygulama değiştikçe bakım gerektirdiğini belirtir.

Güvenlik başlıklarında neye bakılır?

HTTPS ve HSTS: neden önemli?

MDN'ye göre HTTPS (TLS) üç koruma sağlar: aktarım sırasında veriyi okunamaz kılan şifreleme, verinin fark edilmeden değiştirilememesini sağlayan bütünlük ve sunucunun kendini kanıtlayabildiği kimlik doğrulama. HTTPS, araya giren bir saldırganın (MITM) trafiği okuyup değiştirmesine karşı savunmadır; sitenin kodundaki açıklar (XSS gibi) ise ayrı önlemler gerektirir. MDN, HTTP isteklerinin 301 (Moved Permanently) yanıtıyla HTTPS sürümüne yönlendirilmesini ve Strict-Transport-Security (HSTS) başlığının gönderilmesini önerir; HSTS, tarayıcının sonraki ziyaretlerde doğrudan HTTPS ile bağlanmasını sağlar. HSTS'yi HTTPS kurulumunuzun sorunsuz çalıştığından emin olduktan sonra etkinleştirin: HTTPS bozulursa tarayıcı HTTP üzerinden de bağlanmaz, bu yüzden MDN kısa bir max-age ile başlayıp zamanla artırmayı önerir. Karma içerik (HTTPS sayfasında HTTP ile yüklenen görsel, betik, stil dosyası ya da yazı tipi) korumayı zayıflatır. Google'ın sayfa deneyimi belgesi, sayfaların güvenli sunulmasını bir değerlendirme sorusu olarak sayar; aynı belge, Core Web Vitals dışındaki sayfa deneyimi unsurlarının tek başına sıralamayı doğrudan yükseltmediğini söyler.

Yazılım, eklenti ve tema güncellemeleri

Google'ın hacklenmiş siteler rehberi, kaçırılan güvenlik güncellemelerini ve güncel olmayan ya da yama almamış tema ve eklentileri sitelerin hacklenme yollarından biri olarak sayar. Öneri; CMS, web sunucusu yazılımı ve tüm eklentileri güncel tutmak, bakımı yapılmayan eklentileri yalnızca devre dışı bırakmak yerine tamamen kaldırmak ve ücretsiz sürümleri güvenilmeyen kaynaklardan indirmemektir. Google'ın zararlı yazılım önleme sayfası, bir forum ya da blogu kurup unutmanın yaygın bir tuzak olduğunu söyler.

Parola saklama ve kimlik doğrulama

Kullanıcı hesabı olan sitelerde parolalar düz metin olarak değil, tuzlanarak (her parolaya benzersiz, rastgele bir tuz eklenerek) ve parola saklamaya uygun bir algoritmayla özetlenerek (hash) saklanmalıdır. OWASP Parola Saklama Cheat Sheet'i ilk tercih olarak Argon2id'yi önerir ve SHA-256 gibi hızlı özet algoritmalarının, saldırganın çok sayıda tahmini hızla denemesine izin verdiği için parola saklamaya uygun olmadığını belirtir. Site sahibinin hesapları için Google benzersiz parola ve iki adımlı doğrulamayı (2FA) önerir. MDN de parolaları tek başına kullanmamayı, mümkünse geçiş anahtarlarını (passkey), olmazsa zamana dayalı tek kullanımlık parolaları (TOTP) tercih etmeyi sayar.

Oturum yönetimi ve çerezler

OWASP Oturum Yönetimi Cheat Sheet'ine göre oturum çerezlerinde üç öznitelik önemlidir: Secure (çerez yalnızca HTTPS bağlantısında gönderilir), HttpOnly (betikler çereze erişemez) ve SameSite (siteler arası isteklerde davranışı belirler; Strict tercih edilir, Lax kabul edilir). HttpOnly yalnızca çerezin gizliliğini korur; XSS ile birlikte kullanılan bir saldırıda istek yine de gönderilebilir, bu yüzden XSS'e karşı çıktı kodlama ayrıca gerekir. Kullanıcı giriş yaptıktan sonra oturum kimliği yenilenmelidir; çıkışta oturum sunucu tarafında da geçersiz kılınmalıdır. Cheat sheet, boşta kalma ve mutlak zaman aşımı sürelerinin uygulamanın kritikliğine göre belirlenmesini söyler.

Yedekleme

Google'ın temizlik rehberi, hacklenmiş bir siteyi toparlamanın yolunu yedeğin durumuna göre ayırır: güncel ve temiz bir yedek, temiz ama eski bir yedek ya da hiç yedek olmaması. Uzun vadeli bakım için otomatik ve düzenli yedeklemeyi önerir.

Sunucu erişimi, dosya izinleri ve günlükler

Google'ın zararlı yazılım önleme sayfası, sunucu erişimi olanlar için günlük kayıtlarını izlemeyi, açık izinli dizinlerden kaçınmayı, telnet ya da FTP gibi düz metin protokoller yerine SSH ya da SFTP kullanmayı ve site: arama operatörüyle Google'ın sitenizde bulduğu sayfalara ara sıra bakmayı sayar. Aynı sayfa saldırganların günlük dosyalarını değiştirmeye çalışabildiğini, bu dosyaların korunması gerektiğini söyler. .htaccess dosyasında değişiklik yapacaksanız önce geçici bir kopya almanızı, iş bitince bu kopyayı silmenizi ister. Hacklenmiş siteler rehberi de güvenlik politikası boşlukları arasında gereksiz hizmetlerin kapatılmasını ve giriş gibi hassas sayfalarda HTTPS kullanılmasını sayar.

İçerik Güvenlik Politikası (CSP) ve üçüncü taraf betikler

MDN'nin güvenlik sayfası, mümkünse sıkı bir CSP kurmayı, olmuyorsa en azından satır içi JavaScript'i yasaklamayı önerir. CDN gibi dış kaynaklardan yüklenen betikler için Subresource Integrity (SRI) kullanılması da aynı sayfada yer alır. Google, üçüncü taraf uygulama ve reklamların güvenilir ve meşru kaynaklardan seçilmesini söyler. OWASP Top 10:2025'teki A03 Software Supply Chain Failures kategorisi, bağımlılık ve üçüncü taraf bileşenlerin ayrı bir risk alanı olduğunu gösterir.

Barındırma sağlayıcısıyla iletişim

Google'ın karantina rehberi, sorun yaşandığında barındırıcıyı durumdan haberdar etmeyi söyler; barındırıcı da saldırıdan etkilenmişse bu, onun sorunun kapsamını anlamasına yardımcı olabilir.

Güvenlikte resmî kaynaklar ne diyor?

SQL injection: parametreli sorgular	Kullanıcı girdisini sorgu metnine eklemeyin, hazır ifadeler (parametreli sorgular) kullanın; parametreyle bağlanamayan yerlerde (tablo adı, sütun adı, sıralama yönü) izin verilenler listesiyle eşleştirme yapın. Kaynak: OWASP: SQL Injection Prevention Cheat Sheet
XSS: bağlama uygun çıktı kodlama	Kullanıcı verisini sayfaya yazarken HTML, öznitelik, JavaScript, CSS ve URL bağlamlarının her biri için uygun kodlamayı uygulayın; framework'ün otomatik kaçışını kapatan özelliklerden kaçının. Kaynak: OWASP: Cross Site Scripting Prevention Cheat Sheet
Parola saklama	Parolaları düz metin olarak değil, Argon2id gibi parola saklamaya uygun bir algoritmayla özetleyerek saklayın; SHA-256 gibi hızlı özet algoritmalarından kaçının. Kaynak: OWASP: Password Storage Cheat Sheet
Oturum çerezleri	Oturum çerezlerinde Secure, HttpOnly ve SameSite özniteliklerini ayarlayın, giriş sonrasında oturum kimliğini yenileyin, çıkışta oturumu sunucuda geçersiz kılın. Kaynak: OWASP: Session Management Cheat Sheet
HTTPS'e geçiş	HTTP isteklerini 301 ile HTTPS sürümüne yönlendirin, HTTPS'in sorunsuz çalıştığından emin olduktan sonra HSTS başlığını gönderin ve karma içerikten kaçının. Kaynak: MDN: Transport Layer Security (TLS)
Hacklenen sitede temizlik	Yedeğin durumuna göre geri yükleyin, ilgili hesapların parolalarını değiştirin, yalnızca yükseltme değil temiz kurulum yapın ve düzenli otomatik yedeklemeyi sürdürün. Kaynak: Google web.dev: Clean and maintain your site

Web sitesi güvenliğinde sık yapılan altı hata

SSL sertifikası var, site güvenli diye düşünmek

HTTPS aktarımı korur: şifreleme, bütünlük ve kimlik doğrulama sağlar. Sitenin kodundaki XSS ya da SQL injection açıklarını, eski eklentileri ve zayıf parolaları gidermez; bunların her biri ayrı kontrol gerektirir.

Girdiyi “temizledim” deyip çıktıyı kodlamamak

OWASP, merkezi bir noktada yapılan işlemin verinin hangi bağlama yazılacağını bilemediğini belirtir; kodlamanın veri sayfaya yazılırken, bağlama uygun yapılması gerekir.

Kullanılmayan eklenti ve temaları yalnızca devre dışı bırakmak

Google, bakımı yapılmayan eklentilerin devre dışı bırakılmakla yetinilmeyip tamamen kaldırılmasını ve ücretsiz sürümlerin güvenilmeyen kaynaklardan indirilmemesini söyler.

Aynı parolayı birden çok hizmette kullanmak ve ikinci doğrulamayı açmamak

Google, ele geçirilen parolaları sitelerin hacklenme yollarından biri olarak sayar; benzersiz parola ve iki adımlı doğrulama önerir.

Hacklenmiş siteyi çevrimiçi bırakıp yalnızca robots.txt ile engellemeye çalışmak

robots.txt engeli yalnızca arama motoru tarayıcılarını durdurur, normal kullanıcılar zararlı içeriğe erişebilir; Google'a göre siteyi gerçekten içerik sunmaz hâle getirmek gerekir.

Yalnızca görünen zararlı dosyaları silip açığı aramamak

Google, temizlikle birlikte kök nedenin (virüslü yönetici bilgisayarı, zayıf parola, güncel olmayan yazılım, güvenli olmayan kod) araştırılmasını söyler.

Tuba Yazılım'dan teklif istenirse genel çalışma akışı

İhtiyaç ve hedeflerin netleşmesi
Telefon, WhatsApp (0216 393 10 07) ya da teklif formu (/teklif-al) üzerinden sitenizin durumunu ve ne istediğinizi iletirsiniz; örneğin yalnızca bilgi almak mı istiyorsunuz, yoksa belirli bir iş mi? Akışın sırası projeye göre değişebilir.
Yazılı teklif ve kapsam
Teklif hazırlanır; yapılacak işler ve ücret bu teklifte yer alır.
İçerik ve erişim bilgilerinin alınması
İş için gereken erişim ve içerik bilgileri sizden alınır.
Hazırlık ve uygulama
Teklifte yer alan işler hazırlanır ve uygulanır.
Yayın
Teklife giren değişiklikler canlı siteye alınır.
Destek (paket kapsamında)
Paket kapsamındaki ücretsiz teknik destek süresi pakete göre değişir; örneğin Başlangıç Paketi'nde 1 yıl, Profesyonel Pakette 2 yıl, Kurumsal Pakette 3 yıl. Bu desteğin güvenlikle ilgili işleri kapsayıp kapsamadığı ayrıca sorulmalıdır.

Neden Tuba Yazılım?

2024Kuruluş yılı

100+Teslim edilen web sitesi

81 ilUzaktan hizmet

Googleİşletme Profilimiz aşağıda

Merkezimiz İstanbul/Pendik'tedir; 81 ile uzaktan hizmet veriyoruz. Tasarım, içerik, teknik SEO ve Google İşletme Profili kurulumunu tek ekipten yürütürüz. Referanslarımızı inceleyin.

Google İşletme Profilimiz

Müşterilerimizin değerlendirmelerini doğrudan Google Haritalar'daki işletme profilimizde okuyabilirsiniz. Yorumları sitemizde yeniden yayınlamıyoruz; güncel ve eksiksiz hâlleri Google'dadır.

Google İşletme Profilimizi açın →

Sık sorulan sorular

Web sitesi güvenliği nasıl sağlanır?

Tek bir önlemle değil, katmanlı bakımla sağlanır. Resmî kaynakların ortak önerileri: siteyi HTTPS ile sunmak, yazılım ve eklentileri güncel tutmak, kullanıcı verisini çıktıda bağlama uygun kodlamak (XSS), veritabanı sorgularını parametreli yazmak (SQL injection), benzersiz parola ve ikinci doğrulama kullanmak, oturum çerezlerini korumak, düzenli otomatik yedek almak ve günlük kayıtlarını izlemek. Ayrıntılar yukarıdaki bölümlerdedir.

XSS nedir?

OWASP'a göre XSS (Cross-Site Scripting), zararlı betiklerin güvenilen sitelere enjekte edildiği bir enjeksiyon türüdür. Yansıyan ve saklanan olmak üzere iki ana türü vardır; DOM tabanlı XSS üçüncü, daha az bilinen türdür. Sonuçları arasında oturum çerezinin ele geçirilmesi, kullanıcının yönlendirilmesi ve sayfa içeriğinin değiştirilmesi sayılır. Önlemde temel yol, verinin yazıldığı bağlama uygun çıktı kodlamadır.

SQL injection nedir?

OWASP'ın tanımıyla SQL injection, istemciden gelen girdi verisi yoluyla uygulamaya bir SQL sorgusunun enjekte edilmesidir; veritabanındaki verinin okunmasına, değiştirilmesine ya da silinmesine yol açabilir. İlk tercih edilen önlem, girdiyi sorgu metnine eklemek yerine parametreli sorgular (hazır ifadeler) kullanmaktır.

HTTPS neden önemli?

MDN'ye göre HTTPS (TLS) şifreleme, bütünlük ve kimlik doğrulama sağlar; ana savunma araya giren saldırganlara (MITM) karşıdır. HTTPS sitedeki XSS ya da SQL injection açığını kapatmaz. Google'ın sayfa deneyimi belgesi güvenli sunumu bir değerlendirme sorusu olarak sayar, ancak Core Web Vitals dışındaki unsurların tek başına sıralamayı doğrudan yükseltmediğini söyler.

WAF nedir, WAF kurmak yeterli mi?

WAF, uygulama düzeyinde HTTP konuşmasına kurallar uygulayan ve genellikle XSS ile SQL injection gibi yaygın saldırıları ele alan bir güvenlik duvarıdır. Tek başına yeterli sayılmaz: OWASP'ın cheat sheet'leri birincil savunmayı kodda (çıktı kodlama, parametreli sorgu) tanımlar ve WAF'ın uygulamaya göre özelleştirilmesinin emek istediğini, uygulama değiştikçe bakım gerektirdiğini belirtir.

Sitem hacklendi, ne yapmalıyım?

Google'ın sırasına göre önce hack'i doğrulayın ve destek alacağınız kişileri belirleyin, siteyi içerik sunmaz hâle getirip barındırıcınızı haberdar edin, kök nedeni araştırın, yedeğin durumuna göre geri yükleyip temiz kurulumla temizleyin ve Search Console'dan inceleme isteyin. Adımlar yukarıdaki hacklenme bölümünde sıralanmıştır.

Sitemin hacklenip hacklenmediğini nasıl anlarım?

Search Console yardımı, bir sitede güvenlik sorunu olup olmadığını doğrulamak için Güvenlik Sorunları raporunu tek doğru kaynak olarak kabul etmenizi söyler. Google ayrıca site: arama operatörüyle sitenizde beklenmedik sayfa olup olmadığına bakmayı, URL Denetimi aracıyla ya da cURL ile sayfayı Google'ın gördüğü gibi görmeyi önerir; çünkü pek çok saldırgan yalnızca Google'ın görebildiği değişiklikler yapar. Bir hack her zaman görünür olmayabilir. Günlük ve veritabanı kontrolleri ise hack bilindikten sonra kök nedeni araştırmak içindir.

Yedekleme güvenlik için neden gerekli?

Google'ın temizlik rehberine göre güncel ve temiz bir yedek varsa siteyi geri yüklemek mümkündür; yedek yoksa ya da eskiyse toparlama yolu değişir. Rehber, uzun vadede otomatik ve düzenli yedekleme önerir.

Kullanıcı girdisini doğrulamak XSS ve SQL injection'ı çözer mi?

Tek başına çözmez. OWASP XSS için bağlama uygun çıktı kodlamayı öne çıkarır; SQL injection için ilk tercih olarak parametreli sorguları gösterir. İzin verilenler listesiyle doğrulama ise tablo ve sütun adı gibi parametreyle bağlanamayan yerlerde OWASP'ın en uygun savunma saydığı yöntemdir; parametreli sorgunun yerini tutmaz.

Tuba Yazılım güvenlik desteği veriyor mu?

Tuba Yazılım'dan güvenlik konusunda destek istenirse kapsam teklifle netleşir. Teklif için 0216 393 10 07 numaralı telefon ya da WhatsApp hattını veya /teklif-al formunu kullanabilirsiniz.

İlgili sayfalar

Ücretsiz araçlarımız: SEO ve GEO analizi · Yapay zekâ bot erişim testi · Google yorum linki oluşturucu · Fiyat hesaplama

Web Sitesi Güvenliği için ücretsiz teklif alın

İhtiyacınızı dinleyelim, kapsamı ve süreci netleştirip size özel teklif hazırlayalım.