Documentation Index
Fetch the complete documentation index at: https://docs.apinizer.com/llms.txt
Use this file to discover all available pages before exploring further.
Genel Bakış
Amacı Nedir?
API Proxy (API Vekil Sunucusu)çağrılarında gelen isteklerin başlık, parametre ve gövde içeriklerini tarayarak kötü amaçlı ifadelerin sisteminize ulaşmasını engeller.- Hassas veya kişisel verilerin backend sistemlerine iletilmeden önce anonimleştirilmesini ya da tamamen çıkarılmasını sağlar.
- Regülasyon uyumluluğu için isteklerdeki politikaya aykırı içerikleri tespit edip merkezi şekilde yönetilebilir hale getirir.
- Önceden tanımlı filtre kurallarıyla tutarlı bir güvenlik katmanı oluşturarak manual hataları azaltır.
Çalışma Prensibi
- İstek Gelişi: API Gateway’e gelen her HTTP/HTTPS isteği için, istemin kaynak IP adresi tespit edilir.
- Politika Kontrolü: İçerik Filtresi politikası aktif ise, sistem aşağıdaki sırayla kontrol yapar:
- Condition (koşul) tanımlı mı? Varsa koşul sağlanıyor mu?
- Politika aktif mi (active=true)?
- Variable kullanılıyor mu yoksa Apinizer default mı?
- İçerik İnceleme Kuralları: Tanımlı her filtre kuralı için header, parametre ve gövde alanları regex tabanlı taranır; gövde için isteğe bağlı XPath veya JSONPath ile hedef alan izole edilir.
- Karar Verme:
- Eşleşme Var:
BLOCKseçilmişse istek 403 yanıtıyla sonlandırılır;DELETEseçilmişse eşleşen değer başlıktan, parametreden veya gövdeden çıkarılarak akış devam eder. - Eşleşme Yok: İstek orijinal biçimiyle bir sonraki politikaya iletilir.
- Eşleşme Var:
- Hata İşleme: Politika kuralına uymayan istekler için özelleştirilebilir HTTP durum kodu ve hata mesajı döndürülür.
Özellikler ve Yetenekler
Temel Özellikler
- Regex Tabanlı Kural Motoru: Kural ifadeleri ile başlık, parametre veya gövdede geçen şüpheli içerikler yakalanır ve işlendiği alanlardan kaldırılır ya da engellenir.
- Çoklu Uygulama Alanı Seçimi: Aynı kuralın header, query parametresi ve gövde üzerinde eş zamanlı uygulanmasını destekleyerek tutarlı koruma sağlar.
- İçerik Yolu Hedefleme: Gövde kontrollerinde XPath veya JSONPath ile belirli node/alanlar seçilebilir, böylece hedefe yönelik filtreleme yapılır.
- Aktif/Pasif Durum Kontrolü: Politikanın aktif veya pasif durumunu kolayca değiştirme (active/passive toggle). Pasif durumda politika uygulanmaz ancak yapılandırması saklanır.
- Koşul Bazlı Uygulama: Query Builder ile karmaşık koşullar oluşturarak politikanın ne zaman uygulanacağını belirleme (örn: sadece belirli endpoint’lere veya header değerlerine göre).
İleri Düzey Özellikler
- Ön Tanımlı Kural Kütüphanesi: Hazır filtre kuralları listesinden seçim yaparak doğrulanmış regex ifadelerini politikaya hızla ekleme.
- İçerik Dönüşüm Testi: XPath/JSONPath ifadelerini Test Transformation modalı ile canlı veride doğrulama ve gerektiğinde iyileştirme.
- Kural Düzeyinde Eylem Seçimi: Her kural için
BLOCKveyaDELETEkararı belirlenerek farklı alanlara farklı davranış atama. - Export/Import Özelliği: Politika yapılandırmasını ZIP dosyası olarak export etme. Farklı ortamlara (Development, Test, Production) import etme. Versiyon kontrolü ve yedekleme imkanı.
- Policy Group ve Proxy Group Desteği: Birden fazla politikayı Policy Group içinde yönetme. Proxy Group’lara toplu politika atama. Merkezi güncelleme ve deploy işlemleri.
- Deploy ve Versiyonlama: Politika değişikliklerini canlı ortama deploy etme. Hangi API Proxy’lerde kullanıldığını görme (Policy Usage). Proxy Group ve Policy Group kullanım raporları.
Kullanım Senaryoları
| Senaryo | Durum | Çözüm (Politika Uygulaması) | Beklenen Davranış / Sonuç |
|---|---|---|---|
| SQL Injection Engelleme | Parametrelerde union select gibi kalıplar görülebilir | ruleValue = (?i)union.+select, paramActive = true, action = BLOCK | Kural eşleştiğinde istek 403 ile reddedilir ve backend korunur |
| Kredi Kartı Maskesi | JSON gövdesinde kart numarası taşınıyor | JSONPath $..cardNumber, regex \\b\\d{12,19}\\b, action = DELETE | Kart numarası gövdeden çıkarılır, istek kalan verilerle devam eder |
| Zararlı Header Temizliği | X-Forwarded-For başlığında yasak IP listesi var | headerActive = true, regex yasak blok, action = DELETE | Header silinir, kayıt altına alınır |
| XML Script Engelleme | XML isteğinde <script> tag’i gönderiliyor | XPath ile ilgili node seçilir, regex <script> ve altı, action = BLOCK | İstek anında bloklanır ve özel hata mesajı döner |
| DLP - Kimlik Numarası | İstek gövdesinde TC kimlik numarası paylaşılıyor | JSONPath $..identityNo, regex \\b\\d{11}\\b, action = DELETE | Kimlik numarası çıkarılır; loglarda temizlenmiş içerik görünür |
| Bot İzi Kaldırma | trackingId parametresi sistemler arası taşınmasın | Parametre seçimi, regex .+, action = DELETE | Parametre tamamen silinir, backend gereksiz veriyi görmez |
| Coğrafi Kısıtlı Mesaj | Belirli coğrafyadan gelen isteklerde hassas alan temizlensin | Condition ile ülke bazlı koşul, gövde yolu seçimi, action = DELETE | Sadece koşulu sağlayan isteklerde alan kaldırılır |
Politika Parametrelerini Yapılandırma
Bu adımda, kullanıcı yeni bir politika oluşturabilir ya da mevcut politika parametrelerini yapılandırarak erişim kurallarını belirleyebilir.Yeni İçerik Filtresi Politikası Oluşturma
Yapılandırma Adımları
| Adım | Açıklama / İşlem |
|---|---|
| Adım 1: Oluşturma Sayfasına Gitme | - Sol menüden Development → Global Settings → Global Policies → Content Filtering bölümüne gidin. - Sağ üstteki [+ Create] butonuna tıklayın. |
| Adım 2: Temel Bilgileri Girme | Policy Status (Politika Durumu): Aktif/Pasif durumu gösterir. Yeni politikalar varsayılan olarak aktiftir. Name (İsim) Zorunlu: Örnek: Production_ContentFilter- Benzersiz isim girin, boşlukla başlamaz. - Sistem otomatik kontrol eder. Yeşil tik: kullanılabilir. Kırmızı çarpı: mevcut isim. Description (Açıklama): Örnek: “Giriş isteklerinden hassas veriyi temizler.” - Maks. 1000 karakter. - Politikanın amacını açıklayın. |
| Adım 3: Variable Kullanımı | - Sayfanın üst kısmındaki işlem butonları alanında, [<> Variable] butonunu kullanarak dinamik değer seçebilirsiniz. - Context/global variable ifadeleri sayesinde politika parametrelerini sabit değer yerine değişken tabanlı yönetebilirsiniz. - Bu kullanım, değişen değerlerde manuel güncelleme ihtiyacını azaltır ve operasyonel kolaylık sağlar. - Detaylı bilgi için Dinamik Değişkenler sayfasını inceleyebilirsiniz. |
| Adım 4: Filtre Kuralı Tanımlama | - Rule Name: İnsan tarafından okunabilir kural adı belirleyin. - Rule Expression: Regex ifadesini girin veya hazır listeden seçin. - Apply On: Header, Parameter ve Body seçeneklerini işaretleyerek kuralın etki alanını belirleyin. |
| Adım 5: Gövde İçeriği Hedefini Belirleme | - Body seçiliyse ilgili XPath veya JSONPath’i tanımlayın. - XML/JSON radyo butonları ile içerik tipini seçin. - Code editor içinde yolu düzenleyin. |
| Adım 6: Eylem ve Test Seçimi | - BLOCK ile isteği sonlandırın, DELETE ile içeriği temizleyin.- Gerekirse [Choose] ile hazır kural seçin. - [Test Data Transformation] ile XPath/JSONPath ifadesini doğrulayın. |
| Adım 7: Koşul Tanımlama (İsteğe Bağlı) | - Condition sekmesine geçin. - Koşullar, politikanın hangi durumda aktif olacağını belirler. Örnekler: - Ortam bazlı: Header = X-Environment, Operator = Equals, Value = production- API Key bazlı: Header = X-API-Key, Starts With = PROD-- Endpoint bazlı: Path = /api/admin/*Koşul tanımlamazsa politika her zaman aktif |
| Adım 8: Hata Mesajı Özelleştirme (İsteğe Bağlı) | - Error Message Customization sekmesine gidin. - Erişim reddedildiğinde dönecek mesajı özelleştirin. Varsayılan: { "statusCode": 403, "message": "[Default hata mesajı]" }Özel: { "statusCode": 403, "errorCode": "[CUSTOM_ERROR_CODE]", "message": "[Özel mesaj]" } |
| Adım 9: Kaydetme | - Sağ üstteki [Save] butonuna tıklayın. Kontrol Listesi: - Benzersiz isim - Zorunlu alanlar dolu - En az bir filtre kuralı mevcut Sonuç: - Politika listeye eklenir. - API’lere bağlanabilir. - Global politikaysa otomatik uygulanır. |
Politikayı Silme
Bu politikanın silme adımları ve kullanımdayken uygulanacak işlemler için Politika Nedir? sayfasındaki Politikayı Silme bölümüne bakabilirsiniz.Politikayı Dışa/İçe Aktarma
Bu politikanın dışa aktarma (Export) adımları ve kullanılabilecek seçenekler için Politika Nedir? sayfasındaki Politikayı Dışa/İçe Aktarma bölümüne bakabilirsiniz.Politikayı API’ye Bağlama
Bu politikanın API’lere nasıl bağlanacağına ilişkin süreç için Politika Yönetimi sayfasındaki Politikayı API’ye Bağlama bölümüne bakabilirsiniz.İleri Düzey Özellikler
| Özellik | Açıklama ve Kullanım Adımları |
|---|---|
| Regex Şablon Yönetimi | - Politika düzenleme ekranında kural listesine gidin. - [Choose] bağlantısıyla hazır regex’i seçin veya manuel girin. - Kaydetmeden önce test edip onaylayın. |
| XPath/JSONPath Doğrulama | - Body seçeneğini aktif edin ve içerik tipini belirleyin. - Code editor’de yolu tanımlayın. - [Test Data Transformation] ile ifadenin doğru değer döndürdüğünü doğrulayın. |
| Kural Bazlı Eylem Ayrımı | - Her kural için BLOCK veya DELETE seçeneğini belirleyin.- Bloklanan kurallar için hata mesajını Error Message sekmesinden özelleştirin. - Delete seçeneği kullanılan kuralların log’larını gözden geçirin. |
Best Practices
Yapılması Gerekenler ve En İyi Uygulamalar
| Kategori | Açıklama / Öneriler |
|---|---|
| Regex Yönetimi | Kötü: Tüm saldırıları tek bir geniş regex ile yakalamaya çalışmak. İyi: Saldırı tipine göre ayrı regex’ler tanımlamak. En İyi: Hazır şablonları baz alıp proje ihtiyaçlarına göre küçük eklemeler yapmak. |
| İçerik Yolu Tanımları | Kötü: Gövdeyi tamamen hedef almak. İyi: Kritik alanlar için XPath/JSONPath belirlemek. En İyi: Hem path hem regex kullanıp minimum kapsamda maksimum koruma sağlamak. |
| Eylem Seçimi | Kötü: Her kuralı BLOCK yapmak ve hatalı pozitiflerde istekleri kesmek.İyi: Silinebilir alanlar için DELETE, riskli durumlar için BLOCK seçmek.En İyi: Delete sonrası log izleme ve gerektiğinde blok moduna geçiş planlamak. |
| Ön İzleme ve Test | Kötü: Üretime almadan test yapmamak. İyi: Geliştirme ortamında test verileriyle denemek. En İyi: Test Transformation aracı ve pre-prod trafik shadowing ile doğrulama yapmak. |
| Politika Koşulları | Kötü: Politikayı her isteğe uygulamak. İyi: Ortam veya endpoint bazlı koşullar tanımlamak. En İyi: Riskli endpoint’ler için dar kapsamlı koşullar, düşük riskli alanlar için hafif kurallar belirlemek. |
Güvenlik En İyi Uygulamaları
| Güvenlik Alanı | Açıklama / Uyarılar |
|---|---|
| DLP Koruması | Hassas veri (kimlik, kart, IBAN) regex’lerini düzenli olarak güncelleyin ve Delete modunda saklayın. |
| Header Sağlamlığı | Zincir proxy’lerde gelen başlıklarda güvenilmeyen değerleri filtreleyin, delete sonrası loglayın. |
| Regex Performansı | ReDoS’a yol açabilecek kompleks regex’lerden kaçının; gerekirse atomic gruplar kullanın. |
| Hata Mesajı İçeriği | Block durumunda dönen mesajlarda iç yapıyı ifşa etmeyin; genel ama takip edilebilir kodlar kullanın. |
| Log Hijyenini Koruma | Delete edilen içerikleri loglamayın; anonimleştirilmiş maskeleri tercih edin. |
Kaçınılması Gerekenler
| Kategori | Açıklama / Uyarılar |
|---|---|
| Aşırı Genel Regex | Neden kaçınılmalı: Yanlış pozitiflere yol açarak meşru trafiği durdurur. Alternatif: Spesifik saldırı imzaları kullanın. |
| Path Tanımlamamak | Neden kaçınılmalı: Tüm gövdeyi silme riskini artırır. Alternatif: XPath/JSONPath ile noktasal alanı hedefleyin. |
| Koşulsuz Global Uygulama | Neden kaçınılmalı: Düşük riskli endpointlerde gereksiz yük oluşturur. Alternatif: Query Builder ile hedefli koşullar tanımlayın. |
| Test Etmeden Deploy | Neden kaçınılmalı: Üretimde blokaj veya veri kaybı yaşanır. Alternatif: Test aracında regex/path kombinasyonunu doğrulayın. |
Performans İpuçları
| Kriter | Öneri / Etki |
|---|---|
| Regex Karmaşıklığı | Öneri: Non-greedy desenler ve sınırlı lookaround kullanın. Etki: CPU kullanımını azaltır, throughput artar. |
| Kural Sayısı | Öneri: Kuralları risk seviyesine göre gruplandırın, gereksiz kopyaları temizleyin. Etki: İstek başına değerlendirme süresi kısalır. |
| Body İşleme | Öneri: Mümkün olduğunca path ile alt içerikleri seçin. Etki: Büyük gövdelerde parse maliyeti azalır. |
| Koşul Kullanımı | Öneri: Politikanın çalışmadığı durumları koşulla hariç tutun. Etki: Gereksiz regex çalıştırmaları engellenir. |
| Log ve İzleme | Öneri: Delete edilen alanları sayısal metrik olarak toplayın, tam içeriği loglamayın. Etki: I/O yükü düşer, gizlilik korunur. |
Sık Sorulan Sorular (SSS)
| Kategori | Soru | Cevap |
|---|---|---|
| Genel | İçerik Filtresi Politikası hangi tür verileri denetler? | Header, query parametreleri ve JSON/XML gövdeleri regex tabanlı olarak taranır. Body için isteğe bağlı XPath/JSONPath hedeflenebilir. |
| Genel | Politika global ve local farklı çalışır mı? | Davranış aynıdır; global politika tüm proxy’lere uygulanabilirken local politika yalnızca belirlenen API Proxy (API Vekil Sunucusu) üzerinde çalışır. |
| Teknik | Regex ifadesi olarak hangi standart kullanılır? | Java regular expression söz dizimi kullanılır; Pattern.compile() ile derlenir ve Matcher.find() ile eşleşme aranır. |
| Teknik | DELETE eylemi body’de nasıl uygulanıyor? | Path tanımlıysa ilgili node silinir, tanımsızsa gövde boş string’e çekilir ve istek devam eder. |
| Kullanım | Hata mesajı nasıl özelleştirilir? | Error Message sekmesinde durum kodu, mesaj ve hata kodu alanları düzenlenebilir; bloklanan kural adı parametre olarak kullanılabilir. |
| Kullanım | Hazır filtre kuralları nereden geliyor? | Admin → Predefined Filter Rules bölümünde yönetilen global kural kütüphanesinden çekilir ve seçim dialogunda listelenir. |