Client-side Security

Client-side Security nedir?

Resmî tanım problemi de anlatıyor:

“Websites load third-party scripts for analytics, ads, chat widgets, and payment forms. If an attacker compromises one of these scripts, they can steal visitor data directly from the browser, an attack known as a client-side supply chain attack. Client-side security (formerly Page Shield) gives you visibility into these resources and alerts you when something changes or looks malicious.”

“Client-side security monitors scripts, connections, and cookies loaded by your website visitors. You can set up alert notifications and create content security rules to control which resources are allowed on your pages.”

Bu, 2015’ten beri süren Magecart saldırı ailesine karşı geliştirildi. Cloudflare’in 2021 lansman yazısındaki çerçeveleme: “Starting in 2015, a hacker group named Magecart stole payment credentials from online stores by infecting third-party dependencies with malicious code… The British Airways attack stemmed from the compromise of one of their self-hosted JavaScript files, exposing nearly 500,000 customers’ data to hackers.”

8 Aralık 2021’de genel kullanıma açıldı. Bugün hiçbir özelliği beta etiketi taşımıyor.

Nasıl çalışır?

Beacon yok — yalnızca CSP report-only header’ı

Bu ürünün mimari kararı, onu rakiplerinden ayıran şey.

“Client-side security works by adding Content Security Policy (CSP) HTTP headers to your site’s responses. CSP is a browser-native mechanism that controls which resources a page is allowed to load and where to send reports when a resource violates the policy.”

“Under the hood, Client-Side Security collects these signals using browser reporting… which means you don’t need scanners or app instrumentation to get started, and there is zero latency impact to your web applications. The only prerequisite is that your traffic is proxied through Cloudflare.”

Sayfaya enjekte edilen bir JavaScript yok, /cdn-cgi/ altında bir dosya yok, tarayıcı yok, tarama robotu yok. Sayfada hiçbir şey çalışmıyor.

Bunun somut faydası şu: CSP, HTML ayrıştırma anından itibaren aktiftir. Agent tabanlı rakiplerde “beacon yüklenene kadar geçen süre” bir kör noktadır; burada o pencere yok.

İzleme header’ının tam metni

content-security-policy-report-only: script-src 'unsafe-inline' 'unsafe-eval'; connect-src 'none';
  report-uri https://csp-reporting.cloudflare.com/cdn-cgi/script_monitor/report?<QUERY_STRING>

Advanced eklentisiyle rapor ucunu kendi hostname’ine de çevirebiliyorsun.

Bir kısıt daha: “You cannot turn off the monitoring header while resource monitoring is enabled.”

İki header tipi ve örnekleme farkı

“Cloudflare adds the CSP report-only HTTP header used to monitor webpage resources to a sample of sent responses… Cloudflare does not perform any sampling for these report-only headers related to customer-defined content security rules.”

Örnekleme ve ilk veriye kadar geçen süre

“Cloudflare does not collect data on every single page view. Instead, it uses a sampling approach… This means that domains with lower traffic might take longer to generate initial reports, as these domains need more page views to accumulate enough samples.”

“After enabling client-side resource monitoring and generating some traffic to your application (at least 100 requests), wait approximately one hour.”

Script envanteri

Her script için toplanan alanlar: URL, host, ilk ve son görülme zamanı, ilk görüldüğü sayfa, en fazla 10 sayfa listesi, durum, iç hash, son 10 sürüm, ve Advanced’de ML skorları (js_integrity_score, magecart_score, cryptomining_score, malware_score).

Bir tutarsızlık da var: obfuscation_score ve dataflow_score alanları API örneklerinde hâlâ duruyor, ama 3 Mart 2026 sürüm notu bunları kaldırdığını söylüyor — “The updated GNN and LLM-based detection approach has proven significantly more effective at identifying true positives, making the separate behavior analysis scores redundant.”

Bağlantı envanteri ve gizlilik varsayılanı

Bağlantı, sayfanın yaptığı giden bağlantıdır ve connect-src direktifiyle yakalanır. Script envanterinden farkı: hash yok, ML skoru yok — Cloudflare karşı tarafın kodunu göremiyor.

“When connection targets are reported to Cloudflare, their URIs can sometimes include sensitive data such as session ID. By default, client-side security only checks the domain against malicious threat intelligence feeds. You can choose to let Cloudflare use the full URI… Any sensitive data present in the URI will be logged in clear text, and any user with access to the connection monitor dashboard will be able to view it.”

Bu bir ödün: bağlantılarda kötü amaçlı URL kontrolü ancak tam URI’ye geçince çalışıyor, ama o zaman oturum kimliği gibi veriler düz metin olarak loglanıyor. KVKK açısından bilinçli karar verilmesi gereken bir ayar.

Çerez envanteri

Çerezler CSP ile toplanmıyor: “Cloudflare also monitors ingress and egress HTTP traffic for cookies, whether set by origin servers or by the visitor’s browser.”

Temel alanlar (Business ve üstü): tip, domain, path, ilk/son görülme, host, sayfalar. Advanced’de ek alanlar: Max age, Expires, Lifetime, HTTP only, Secure, Same site.

Önemli kısıt: “Except for Domain and Path, standard cookie attributes are only available for first-party cookies, where Cloudflare detected the set-cookie HTTP response header in HTTP traffic.”

Durum değerleri saklama süresini belirliyor

“All scripts and connections considered malicious will appear in the Monitors dashboard, regardless of their status.”

Engellenen script’ler için ayrı kural: “A blocked script is only removed after it has not been detected for 30 consecutive days.”

İçerik güvenlik kuralları

İki aksiyon var ve sıralaması bir metodoloji:

“Log: Cloudflare reports any resources not covered by the rule as rule violations without blocking them. Use this action to validate a new content security rule before deploying it.”

“Allow: Cloudflare blocks any resources not explicitly allowed by the rule and logs them as rule violations. Switch to this action after validating a rule with the Log action to avoid blocking essential application resources.”

İzlenen direktifler yalnızca iki tane: script-src ve connect-src. Kuralda kullanabildiğin ama izlenmeyen direktifler: default-src, img-src, style-src, font-src, object-src, media-src, child-src, form-action, worker-src, base-uri, manifest-src, frame-src, frame-ancestors, upgrade-insecure-requests.

Kötü amaçlı tespit — üç mekanizma

Analiz iki katmanlı ve ikinci katmanın etkisi ölçülmüş:

“Every script is first evaluated by the GNN. If the GNN predicts the script as benign, the detection pipeline terminates immediately. … If the GNN flags the script as potentially malicious… the script is forwarded to an open-source LLM hosted on Cloudflare Workers AI for a second opinion. … we currently use gpt-oss-120b”

“the secondary LLM validation layer reduced false positives by nearly 3x: dropping the already low ~0.3% FP rate down to ~0.1%. When evaluating unique scripts, the impact is even more dramatic: the FP rate plummets a whopping ~200x, from ~1.39% down to just 0.007%.”

Ayrıca: “Cloudflare uses open-source models for this analysis. Customer data is not used to train these models.”

Skorlama:

“The analysis assigns a JS integrity score between 1 and 99 to each script version. Lower scores indicate higher risk: a score of 1 means definitely malicious, and 99 means definitely not malicious.”

“Cloudflare classifies a script as malicious when its score falls below the threshold, which is currently set to 10.”

“Şüpheli” diye bir ara kademe yok — sınıflandırma ikili ve eşikten türetiliyor. Ve API’de doğrudan verilmiyor: “The malicious script classification… is not directly available in the API. To determine this classification, compare the script’s js_integrity_score value with the classification threshold.”

Uyarılar

“Malicious resource alerts will only include resources with an Active status.”

Hedefler: “notification email, webhooks, and connected notification services.” PagerDuty güncel dokümanlarda adıyla geçmiyor — yalnızca 2021 bloglarında var, o yüzden bu sayfada iddia edilmemiştir.

Kapsamlı (scoped) uyarılar Advanced’e özel ve bir ön koşulu var: “Requires content security rules configured in those zones… Rule violations do not trigger these alerts.”

Ne zaman kullanılır, ne zaman kullanılmaz

Kullanılır

• Ödeme sayfan varsa. PCI DSS v4’ün 6.4.3 ve 11.6.1 maddeleri tam olarak bu alanı düzenliyor ve 31 Mart 2025’ten beri yürürlükte.
• Üçüncü taraf script’lerin varsa ve sayılarını bilmiyorsan. Cloudflare’in ölçümü: kurumsal bir zone’da ortalama 2.200 script.
• Gecikme eklemek istemiyorsan. Beacon olmadığı için sayfa performansına etkisi yok.
• Envanter istiyorsan, engelleme değil. Ücretsiz planda bile script izleme çalışıyor.

Kullanılmaz — dürüst sınırlar

Inline script kapsamı gerekiyorsa. Ürün inline kodu göremiyor. Gerçek bir CSP yönetim ürünü inline script’leri hash’ler veya nonce verir; bu ürün ikisini de yapmıyor.

Çalışma zamanı davranış analizi gerekiyorsa. Sınıflandırma statik — parse ağacı üzerinde GNN, ardından kaynak kodun LLM incelemesi. Sandbox yok, DOM API araya girme yok, form alanı okumalarının takibi yok. Agent tabanlı rakipler kart alanına addEventListener eklendiğini ve sızdırılan yükü görüyor; bu ürün bir URL ve bir bağlantı hostu görüyor.

Sızdırılan veriyi görmen gerekiyorsa. Gövdeler asla yakalanmıyor. Sızıntının olduğunu ve nereye gittiğini öğreniyorsun; ne gittiğini asla.

Tam kapsam gerekiyorsa. Örneklenmiş çalışıyor; JS agent’ı %100 sayfa görüntülemede çalışır.

Beşten fazla kural gerekiyorsa. Üst katmanda bile beş kural, 6.000 karakter.

SaaS platformuysan. “There is currently no way to scope a content security rule to the root zone only, excluding custom hostnames.” Yönetmediğin hostname’ler için yüksek hacimde uyarı alırsın.

Cloudflare’in kararına itiraz mekanizması arıyorsan. “external tools may not confirm the detection you got from Cloudflare, since the machine learning (ML) model being used is Cloudflare-specific technology.” Yanlış pozitif düşünüyorsan yol hesap ekibinden geçiyor.

Somut örnekler

İzlemeyi açmak

curl "https://api.cloudflare.com/client/v4/zones/$ZONE_ID/page_shield" \
  --request PUT \
  --header "X-Auth-Email: $CLOUDFLARE_EMAIL" \
  --header "X-Auth-Key: $CLOUDFLARE_API_KEY" \
  --json '{ "enabled": true }'

API yolunun hâlâ page_shield olduğuna dikkat — ürün adı değişti, yol değişmedi.

Yeni enjekte edilmiş script’i bulmak

curl "https://api.cloudflare.com/client/v4/zones/$ZONE_ID/page_shield/scripts?status=infrequent&per_page=100" \
  --header "X-Auth-Email: $CLOUDFLARE_EMAIL" \
  --header "X-Auth-Key: $CLOUDFLARE_API_KEY"

status=infrequent filtresi kritik: “By default, the response will only include scripts with active status when you do not specify a status filter parameter.” Yeni enjekte edilmiş bir script henüz üç rapora ulaşmadığı için varsayılan listede görünmez.

Log modunda bir içerik güvenlik kuralı

curl "https://api.cloudflare.com/client/v4/zones/$ZONE_ID/page_shield/policies" \
  --request POST \
  --header "X-Auth-Email: $CLOUDFLARE_EMAIL" \
  --header "X-Auth-Key: $CLOUDFLARE_API_KEY" \
  --json '{
    "description": "Odeme sayfasi - once log modunda",
    "action": "log",
    "expression": "http.host eq \"odeme.ornek.com.tr\"",
    "enabled": "true",
    "value": "script-src odeme.ornek.com.tr cdnjs.cloudflare.com https://www.google-analytics.com/analytics.js '\''self'\''"
  }'

Bu izin listesinin anlamı, dokümanın kendi açıklamasıyla: odeme.ornek.com.tr üzerindeki script’ler (ama ornek.com.tr üzerindekiler değil), cdnjs.cloudflare.com üzerindekiler, tam URL’siyle belirtilen Google Analytics script’i, ve aynı origin’deki tüm script’ler. “All other scripts would trigger a rule violation, but those scripts would not be blocked.”

İhlalleri GraphQL ile çekmek

query PageShieldReports($zoneTag: String!, $start: Time!, $end: Time!) {
  viewer {
    zones(filter: { zoneTag: $zoneTag }) {
      pageShieldReportsAdaptiveGroups(
        limit: 100
        orderBy: [datetime_ASC]
        filter: { datetime_geq: $start, datetime_leq: $end }
      ) {
        count
        dimensions { policyID datetime url urlHost host resourceType pageURL action }
      }
    }
  }
}

Dataset adı hâlâ pageShieldReportsAdaptiveGroups. İhlaller son 30 gün için sorgulanabiliyor.

Logpush ile SIEM’e aktarmak

page_shield_events dataset’i şu alanları taşıyor: Action (log veya allow), CSPDirective, Host, PageURL, PolicyID, ResourceType (script, connection veya izlenmeyen tipler için other), Timestamp, URL, URLHost.

Advanced eklentisiyle 4 Logpush işi hakkın oluyor.

Demo 1: Yeni bir script’in envantere düşmesini ölçmek

Bu demo bir sayı üretiyor: senin sitende bir script’in fark edilmesi ne kadar sürüyor.

Adım 1 — İzlemeyi aç ve başlangıç envanterini kaydet

Panelde Security → Settings → Client-side abuse → Continuous script monitoring açık olmalı.

Security → Settings → Client-side abuse ekranı; Continuous script monitoring açık, raporlama ucu ve veri işleme seçenekleri

curl -s "https://api.cloudflare.com/client/v4/zones/$ZONE_ID/page_shield/scripts?per_page=100" \
  --header "Authorization: Bearer $CF_API_TOKEN" \
  | python3 -c 'import sys,json;[print(s["url"],s["status"]) for s in json.load(sys.stdin)["result"]]' \
  | sort > /tmp/envanter-once.txt
wc -l /tmp/envanter-once.txt

API'den alınan mevcut script listesi ve toplam sayısı; Web assets → Client-side resources ekranının karşılık gelen görünümü

Adım 2 — İzleme header’ının gerçekten gönderildiğini doğrula

curl -sSI https://ornek.com.tr/ | grep -i 'content-security-policy-report-only'

curl -I çıktısında content-security-policy-report-only başlığı; script-src 'unsafe-inline' 'unsafe-eval' ve csp-reporting.cloudflare.com rapor ucu

Adım 3 — Test sayfasına yeni bir üçüncü taraf script ekle

Kendi test sayfana, daha önce hiç kullanmadığın bir CDN’den bir script ekle:

<script src="https://cdn.jsdelivr.net/npm/canvas-confetti@1.9.3/dist/confetti.browser.min.js"></script>

Zamanı not et.

Adım 4 — Trafik üret ve saymaya başla

Resmî eşik en az 100 istek. Kendi sayfana:

for i in $(seq 1 150); do curl -s -o /dev/null https://ornek.com.tr/test-sayfa; done
date -u +%H:%M:%S

Adım 5 — Envanteri düzenli aralıklarla yokla

while true; do
  echo -n "$(date -u +%H:%M:%S)  "
  curl -s "https://api.cloudflare.com/client/v4/zones/$ZONE_ID/page_shield/scripts?status=infrequent&per_page=100" \
    --header "Authorization: Bearer $CF_API_TOKEN" \
    | grep -c 'jsdelivr' || echo 0
  sleep 300
done

Yoklama döngüsünün çıktısı; script'in ilk kez göründüğü zaman damgası ve adım 3'teki eklenme saatiyle arasındaki fark

Bu farkın kendisi demonun sonucudur. Resmî beklenti “yaklaşık bir saat”, ama senin trafik hacminde gerçekte ne kadar sürdüğünü ancak böyle öğrenirsin.

Adım 6 — Panelde script detayını incele

Web assets → Client-side resources → script detayı; Last seen, First seen at, Seen on host, Seen on pages ve varsa sürüm listesi

Adım 7 — Bağlantı envanterini de kontrol et (Business ve üstü)

Client-side resources → Connections sekmesi; sayfanın yaptığı giden bağlantılar, host'lar ve ilk/son görülme zamanları

Bu demoda ölçülenler: script eklenmesi ile envantere düşmesi arasındaki süre · o süre boyunca üretilen istek sayısı · header’ın kaç istekte bir göründüğü · script detayındaki alanların doluluğu · bağlantı envanterinin script envanterinden farkı.

Demo 2: Bir kuralı log modunda doğrulayıp allow moduna geçirmek

Bu, Cloudflare’in kendi önerdiği prosedürün uygulanmasıdır ve üretimde bir kuralı canlıya almanın tek güvenli yoludur.

Adım 1 — Mevcut script’lerden izin listesini türet

curl -s "https://api.cloudflare.com/client/v4/zones/$ZONE_ID/page_shield/scripts?per_page=100" \
  --header "Authorization: Bearer $CF_API_TOKEN" \
  | python3 -c 'import sys,json;print(" ".join(sorted({s["host"] for s in json.load(sys.stdin)["result"]})))'

Mevcut script'lerin benzersiz host listesi; içerik güvenlik kuralının izin listesinin temeli

Adım 2 — Log modunda kuralı oluştur

Yukarıdaki POST .../page_shield/policies çağrısını "action": "log" ile kullan.

Security rules → Content security rules ekranı; kuralın log modunda ve etkin olduğu

Adım 3 — İkinci bir CSP header’ının eklendiğini doğrula

curl -sSI https://odeme.ornek.com.tr/ | grep -ci 'content-security-policy-report-only'

curl çıktısı; iki ayrı content-security-policy-report-only başlığı — biri izleme, biri kural

Kural header’ı örneklenmiyor, her eşleşen yanıta ekleniyor. İzleme header’ı ise örneklenmiş. İkisini yan yana görmek bu farkı somutlaştırıyor.

Adım 4 — İhlalleri izle

Yedi gün boyunca panelde ve GraphQL’de ihlalleri topla.

Content security rules ekranındaki kural satırı ve son yedi günün ihlal grafiği (sparkline)

pageShieldReportsAdaptiveGroups sorgusunun çıktısı; ihlal eden URL'ler, host'lar ve sayfa adresleri

Her ihlal ya izin listesine eklenecek meşru bir kaynaktır ya da gerçekten oraya ait olmayan bir şey. Bu ayrımı yapmak yedi günün asıl işi.

Adım 5 — Reklam engelleyici gürültüsünü tanı

İhlal listesinde reklam engelleyicilerin yönlendirdiği yerel kaynaklara ait, seyrek görünen kayıtlar

Resmî açıklama: reklam engelleyici uzantılar bu alan adlarına giden istekleri engelliyor veya yerel bir kaynağa yönlendiriyor, bu da ihlal raporu üretiyor. “Because only visitors with these extensions installed trigger this behavior, the violation reports are sparse compared to your site’s overall traffic volume.” Seyreklik, bunları gerçek sorunlardan ayırt etmenin ipucu.

Adım 6 — Allow moduna geçir ve engellemeyi tarayıcıda gör

curl "https://api.cloudflare.com/client/v4/zones/$ZONE_ID/page_shield/policies/$POLICY_ID" \
  --request PUT --header "Authorization: Bearer $CF_API_TOKEN" \
  --json '{"action":"allow", ...}'

Sonra izin listesinde olmayan bir script’i test sayfana ekle ve tarayıcı konsolunu aç.

DevTools konsolunda 'Refused to load the script ... because it violates the following Content Security Policy directive' hatası

Content security rules ihlal listesinde aynı script'in allow aksiyonlu kaydı

Adım 7 — Geri alma provası

curl "https://api.cloudflare.com/client/v4/zones/$ZONE_ID/page_shield/policies/$POLICY_ID" \
  --request PUT --header "Authorization: Bearer $CF_API_TOKEN" \
  --json '{"action":"log", ...}'

Kuralın tekrar log moduna döndüğü ve engellenen script'in yeniden yüklendiği; tarayıcı konsolunda artık uyarı olduğu, hata olmadığı

Geri alma bir tık uzaklıkta — ama denenmemiş bir geri alma prosedürü, prosedür sayılmaz.

Bu demoda ölçülenler: log modunda yedi günde biriken ihlal sayısı · meşru ve şüpheli ihlallerin oranı · reklam engelleyici kaynaklı gürültünün payı · allow moduna geçişten sonra engellenen kaynak sayısı · geri alma süresi.

Fiyatlandırma

Plan tablosu — en önemli tablo

Fiyat

cloudflare.com/plans/application-services/ sayfasında birebir:

“Client-Side Security — Defend against client-side attacks that target vulnerable JavaScript dependencies. — $0.099 per 1k requests”

Ölçüm birimi HTTP isteği, 1.000 başına. Tahmin yöntemi de açıklanmış: “Before committing, we will estimate the cost based on your last month’s HTTP requests, so you know exactly what to expect.”

30 Mart 2026’dan beri self-servis: “Client-Side Security Advanced (formerly Page Shield add-on) is now available to self-serve customers.” Aynı tarihte alan adı tabanlı tehdit istihbaratı da ücretsiz katmana açıldı.

Limitler

Lisanslama ve hukuki çerçeve

Hizmet tescillidir ve Cloudflare Hizmet Şartları’na tabidir.

PCI DSS v4 — 6.4.3 ve 11.6.1

Cloudflare bu ürünü açıkça PCI DSS v4’ün istemci tarafı gereksinimlerine bağlıyor:

“You can use Cloudflare’s client-side security for PCI DSS v4’s client-side security requirements (items 6.4.3 and 11.6.1).”

“Note: To help with PCI DSS requirements, you must have Client-Side Security Advanced.”

Ve yürürlük tarihi: “Both of these requirements become effective on March 31, 2025.”

SaaS işleten okuyucular için ek bir uyumluluk zorluğu var: kapsamlı uyarılarda 'self' kullanmak tüm custom hostname’lerde tetikleniyor ve Cloudflare bunun “makes it difficult to isolate the scope of your own compliance audits (for example, the specific pages where you collect cardholder data)” dediğini kabul ediyor. Önerilen çözüm, kural ifadesini kart verisi topladığın yollarla sınırlamak.

KVKK açısından üç nokta

Birincisi, bağlantı URI’si ayarı. Varsayılan “yalnızca host” kalırsa Cloudflare tam URL’yi saklamıyor. “Tam URI”ye geçersen oturum kimliği gibi veriler düz metin olarak loglanıyor ve panel erişimi olan herkes görebiliyor. Bu, bilinçli karar verilmesi gereken bir ayar.

İkincisi, ziyaretçi tarayıcısı rapor gönderiyor. CSP ihlal raporları ziyaretçinin tarayıcısından csp-reporting.cloudflare.com adresine gidiyor. Rapor, ziyaret edilen sayfanın URL’sini ve yüklenen kaynağın URL’sini içeriyor. Bu bir veri işleme faaliyetidir ve aydınlatma metninde değerlendirilmelidir.

Üçüncüsü, çerez envanteri. Ürün ziyaretçi tarayıcısının kurduğu çerezleri de envanterliyor. Çerez adları ve öznitelikleri toplanıyor — değerleri değil, ama isimlendirme bile bilgi taşıyabilir.

Modellerin eğitimi

“Cloudflare uses open-source models for this analysis. Customer data is not used to train these models.”

Bu cümle, veri işleyen sözleşmene dayanak yapılabilir.

Sık yapılan hatalar

Panel hash’ini SRI hash’i sanmak. İç tanımlayıcıdır; kuralda çalışmaz.

Yeni script’i status=infrequent filtresi olmadan aramak. Üç rapora ulaşmamış script varsayılan listede görünmez.

Log modunu atlayıp doğrudan allow’a geçmek. Resmî öneri en az yedi gün log.

Aynı anda birden fazla allow kuralı çalıştırmak. “the most restrictive policy wins” ve beklenmedik engellemeler başlar.

Nonce direktifi kullanmaya çalışmak. Desteklenmiyor; hash kullanılmalı.

Transform Rules ile yol eşleştirmesini bozmak. “URL Rewrite Rules run early in the request lifecycle, while content security rules are evaluated later, during response phases.” Kural ifadesinde http.request.uri.path yerine raw.http.request.uri.path kullanılmalı.

Response Header Transform Rule’da CSP için “Add” işlemi kullanmak. İki header birden çıkar ve en kısıtlayıcı olan kazanır. Set static veya Set dynamic kullanılmalı.

Yönlendirme hedeflerinin raporlanmasını beklemek. Tasarım gereği raporlanmıyor; Google Ads dokümanda örnek olarak veriliyor.

Reklam engelleyici gürültüsünü gerçek ihlal sanmak. Seyrek görünmeleri ayırt edici ipucu.

Inline script’lerin envantere düşmesini beklemek. İzleme header’ı onlara izin veriyor.

300 KB üstü bundle’ların kod analizinden geçtiğini varsaymak. Geçmiyorlar.

Advanced eklentisi olmadan içerik güvenlik kuralı yazmaya çalışmak. Enterprise’da bile kural kotası sıfır.

API’nin yeniden adlandırıldığını sanmak. page_shield yolları, policies alt kaynağı ve eski rol adları aynen duruyor.