Son güncelleme: Ağustos 2026

Teknik

Req 11.6.1: Ödeme sayfasındaki yetkisiz değişikliği tespit etmek

PCI DSS 4.x'in en çok yanlış anlaşılan maddelerinden biri. Kısaca: ödeme sayfanızın tarayıcıya ulaşan hâlinde bir şey değişirse bunu fark etmeniz ve birinin haberdar olması gerekiyor. CSP yazmış olmak tek başına bu maddeyi karşılamıyor.

Madde ne diyor

11.6.1, ödeme sayfasının tüketici tarayıcısında aldığı hâlinde — hem HTTP başlıklarında hem sayfa içeriğinde — yetkisiz değişiklik, ekleme ve silmeleri tespit edip personeli uyaran bir mekanizma kurulmasını ister. Mekanizma, alınan başlıkları ve sayfayı değerlendirecek şekilde yapılandırılmalı ve en az haftada bir çalışmalıdır — ya da 12.3.1'e göre yaptığınız hedefli risk analizinde gerekçelendirdiğiniz frekansta.

Dikkat edilecek üç ayrıntı:

• "Tüketici tarayıcısında alındığı hâli" — sunucudaki dosyayı kontrol etmek yetmez. Araya giren bir CDN, bir etiket yöneticisi ya da üçüncü taraf bir script sayfayı sunucudan sonra değiştirebilir.
• Başlıklar da kapsamda. Content-Security-Policy'nin sessizce gevşetilmesi de bir değişikliktir ve tespit edilmelidir.
• Uyarı üretmek zorunlu. Kayıt tutmak tek başına yeterli değil; birinin haberi olmalı.

Bu madde neden var: e-skimming

Saldırgan sunucunuza hiç girmeden kart verisi çalabilir. Ödeme sayfanızın yüklediği üçüncü taraf bir script — bir analitik kütüphanesi, bir sohbet aracı, sürümü sabitlenmemiş bir CDN bağımlılığı — ele geçirilir ve forma girilen kart numarasını saldırganın sunucusuna gönderen birkaç satır eklenir. Sunucu logları temiz görünür, dosya bütünlüğü kontrolü bir şey yakalamaz, çünkü değişiklik sizin altyapınızda değil.

Bu saldırı ailesi Magecart adıyla biliniyor ve on binlerce siteyi etkiledi. 11.6.1 ile 6.4.3, standardın buna verdiği cevap.

6.4.3 ile ilişkisi

İki madde birbirini tamamlar ve karıştırılmamalı:

Madde	Odak	Soru
6.4.3	Önleme ve yönetim	Sayfada hangi scriptler var, hangisi yetkili, bütünlüğü nasıl güvence altında, gerekçesi ne?
11.6.1	Tespit ve uyarı	Bir şey değiştiğinde bunu fark ediyor muyuz, kim haberdar oluyor?

6.4.3 envanteri ve yetkilendirmeyi, 11.6.1 sürekli gözü sağlar. Denetçi ikisini ayrı ayrı sorar; birini karşılayıp diğerini atlamak sık görülen bir hata.

Uygulamada ne kurulmalı

1. Script envanteri ve gerekçe kaydı

Ödeme sayfasında çalışan her script için kaynak, gerekçe ve yetkilendirme kaydı tutun. "Pazarlama ekibi istemişti" bir gerekçedir; kaydı yoksa denetimde gerekçe sayılmaz. Envanterde olmayan bir kaynak belirdiğinde bu bir bulgudur.

2. Content-Security-Policy — ama tek başına değil

CSP, izin verilmeyen kaynakların yüklenmesini engeller; bu 6.4.3 tarafına yazılır. Ancak CSP'nin kendisi de bir yapılandırmadır ve değiştirilebilir. report-uri ya da report-to ile ihlal raporlarını toplamak, tespit tarafına gerçek katkı sağlar: tarayıcı, politika dışı bir kaynağı görürse size bildirir.

Sık yapılan hata: script-src içine 'unsafe-inline' ya da geniş bir joker eklemek. Bu, politikayı büyük ölçüde işlevsiz bırakır ve denetimde fark edilir.

3. Subresource Integrity (SRI)

Üçüncü taraf scriptlere integrity özniteliği eklemek, dosyanın içeriği değiştiğinde tarayıcının onu çalıştırmamasını sağlar. Sürümü sabitlenmemiş bir CDN bağımlılığı için SRI kullanılamaz — bu yüzden sürüm sabitlemek de bir güvenlik kararıdır.

4. Başlık ve içerik farkı izleme

Sayfayı dışarıdan, gerçek bir tarayıcı gibi çekip alınan başlıkları ve script listesini referans bir hâlle karşılaştırın. Fark çıktığında uyarı üretin. Frekans en az haftalık; daha sık istiyorsanız gerekçeye ihtiyacınız yok, daha seyrek istiyorsanız 12.3.1 risk analizi şart.

5. İnceleme ve onay akışı

Uyarı üretmek yetmez; kimin baktığı ve ne karar verdiği kayıt altında olmalı. Denetçinin sorduğu tipik soru: "Şubat ayındaki şu sapmayı kim inceledi, sonucu neydi?"

Denetimde en sık düşülen hatalar

• Sadece sunucudaki dosyayı kontrol etmek. Madde tarayıcının aldığı hâli soruyor.
• Yalnızca CSP yazıp tespit mekanizması kurmamak. Önleme ≠ tespit.
• Frekansı gerekçesiz seçmek. Haftalıktan seyrek her seçim 12.3.1 risk analizi ister.
• Uyarının kime gittiğinin belli olmaması. Ortak bir posta kutusuna düşen ve kimsenin sahiplenmediği uyarı, denetimde çalışan bir kontrol sayılmaz.
• Kanıtın yıla yayılmaması. Denetim haftasında alınan tek ekran görüntüsü, kontrolün yıl boyunca çalıştığını göstermez.

Özet

11.6.1 teknik olarak zor bir madde değil; zor olan, kontrolün yıl boyunca çalıştığını ve her sapmanın bir sahibi olduğunu gösterebilmek. Mekanizmayı kurduktan sonra asıl iş, üretilen uyarıların kaybolmadığı bir akış kurmaktır.