GÜVENLIK POLİTİKASI / SECURITY POLICY

TÜRKÇE / TURKISH

---

GÜVENLIK POLİTİKASI

Son Güncelleme: 29 Nisan 2026

1. GİRİŞ

Bu Güvenlik Politikası, Dersin Kelimeleri uygulaması kullanıcılarının kişisel verilerinin ve sistem güvenliğinin nasıl korunduğunu açıklar. Uygulamada güvenlik, en yüksek önceliklerden biridir ve tüm teknik, örgütsel ve yönetimsel düzeyde önlemler alınmıştır.

2. VERI ŞIFRELEMESI VE İLETİM GÜVENLİĞİ

2.1 İletim Sırasında Şifreleme (In Transit)

HTTPS/TLS Protokolü: - Tüm sunucu-istemci iletişimi HTTPS protokolü ile şifrelenmiştir - TLS 1.2 veya üzeri versiyonları kullanılır - SSL/TLS sertifikaları düzenli olarak güncellenmiş ve geçerlidir - Sertifika pinningleme (Certificate Pinning) uygulandığında yerel güvenlik artar

API İletişimi: - POST, PUT, DELETE işlemleri için tüm form verileri şifrelidir - Hassas bilgiler (şifre, token, kişisel veriler) şifreli başlıklar kullanılarak gönderilir - İstek/Yanıt gövdesi (Request/Response Body) JSON formatında şifrelidir

Kimlik Doğrulama Tokenları: - JWT (JSON Web Token) tokenları HTTPS başlıkları aracılığıyla gönderilir - Token geçerliliği sunucu tarafında doğrulanır - Token süresi sınırlanmıştır (30-60 dakika)

2.2 Depolandığında Şifreleme (At Rest)

JWT Tokenları: - iOS: Apple Keychain Services kullanan flutter_secure_storage ile şifrelenir - Android: Android KeyStore ve EncryptedSharedPreferences kullanan flutter_secure_storage ile şifrelenir - Depolama Yönetimi: Sistem şifrelemesi (TEE - Trusted Execution Environment) tarafından korunur

Parolalar: - Sunucu tarafında bcrypt, scrypt veya PBKDF2 gibi güçlü algoritmatlarla şifrelenir - Parola hash fonksiyonları en az 10 işlem turuna sahiptir (salt included) - Parolalar hiçbir zaman uygulamada plain text olarak saklanmaz

Profil Resimleri: - Güvenli sunucu ortamında depolanır - Dosya sistem izinleri ile koruma altınası alınır - CDN üzerinden sunulursa, HTTPS via şifrelidir

SharedPreferences Verileri: - Android 12 ve üzeri: Otomatik olarak şifrelenmiş depolamaya yönlendirilir - iOS: iCloud Keychain veya encrypted SharedPreferences kullanılır - Şifreli anahtar (encryption key) cihazın güvenlik işlemi (TEE) tarafından yönetilir

Veritabanı: - Sunucu veritabanı şifreleme (Database Encryption at Rest) etkindir - Örneğin: MySQL Transparent Data Encryption (TDE), PostgreSQL pgcrypto

3. KİMLİK DOĞRULAMA VE ERIŞIM KONTROLÜ

3.1 Parola Güvenliği

Parola Gereksinimleri: - Minimum uzunluk: 8 karakter - Karmaşıklık: En az bir büyük harf, bir küçük harf, bir rakam, bir özel karakter - Ortak parolaların (top 100.000 parola) kontrolü yapılır - Parola tekrarı (previous password reuse) engellenir

Parola İletişimi: - Şifre alanları UI'da maskelenmiştir (gözükmeyen karakterler) - Parola hiçbir zaman log dosyalarında kaydedilmez - Şifre sıfırlama e-posta bağlantıları tek kullanımlık tokenlerdir

3.2 JWT Token Yönetimi

Token İçeriği: - Kullanıcı ID (UID) - E-posta adresi - Yetki düzeyleri (claims) - Veriliş zamanı (iat) - Sona erme zamanı (exp)

Token Süresi: - Access Token: 30-60 dakika geçerli - Refresh Token: 7-30 gün geçerli (opsiyonel) - Token Rotation: Belirli işlemlerden sonra yenilenir

Token Doğrulama: - Her istek sunucu tarafında doğrulanır - Signature doğrulanır (Secret Key ile) - Expiration zamanı kontrol edilir - İmza geçersiz ise isteğe 401 Unauthorized dönülür

3.3 Çoklu Faktörlü Kimlik Doğrulama (MFA)

Uygulamada şu kimlik doğrulama yöntemleri desteklenir: - E-posta/Parola: İlk faktör - Google Sign-In: OAuth 2.0 (isteğe bağlı) - Apple Sign-In: OAuth 2.0 (iOS için isteğe bağlı) - Biyometrik Kimlik Doğrulama: Parmak izi / Yüz tanıma (cihazda, opsiyonel)

OAuth Güvenliği: - Google ve Apple'ın resmi SDK'ları kullanılır - ID Token sunucu tarafında doğrulanır - State parameter (CSRF koruması) kullanılır - Redirect URI sınırlandırılmıştır

3.4 Oturum Yönetimi

Oturum Kurma: - Login başarılı olunca JWT token oluşturulur - Token cihazda güvenli depolamaya yazılır - Refresh token (varsa) ayrı alanda saklanır

Oturum Sonlandırma: - Logout işleminde token silinir - Sunucu tarafında token blacklist'e eklenebilir - Cihazdan tamamen kaldırılır

Oturum Zaman Aşımı: - Token süresi dolduktan sonra yenileme gerekir - Yenileme başarısız olursa kullanıcı tekrar giriş yapar - 30 gün inaktivite sonrası oturum kapatılabilir

4. AĞDA TRANSMISYON GÜVENLIĞI

4.1 Protokol ve Şifreleme Standartları

HTTPS Yapılandırması: - TLS Version: 1.2 minimum (1.3 tercih) - Cipher Suites: Yalnızca güçlü cipher'lar (AES-256, ChaCha20) - Key Exchange: Forward Secrecy (PFS) etkin (ECDHE, DHE) - Weak ciphers devre dışı (RC4, DES vb.)

HSTS (HTTP Strict Transport Security): - HSTS header etkin: Strict-Transport-Security: max-age=31536000; includeSubDomains - Tarayıcıya HTTPS zorunluluğunu söyler - Man-in-the-middle (MITM) saldırılarını önler

4.2 API İstek Güvenliği

İstek Doğrulama: - Content-Type: application/json doğrulanır - Payload boyutu sınırsı kontrol edilir (örn: max 10 MB) - JSON Schema doğrulaması yapılır

Rate Limiting: - IP başına dakikada maksimum istek sayısı sınırlanır (örn: 100 req/min) - Kullanıcı başına dakikada sınır (örn: 1000 req/min) - Aşılması durumunda 429 Too Many Requests dönülür

CSRF Koruması: - CSRF token her form sunuşunda verilir - Token doğrulanır (Request origin'i kontrol edilir) - SameSite cookie attribute kullanılır (SameSite=Strict)

4.3 Firewall ve DDoS Koruması

Firewall Kuralları: - Yalnızca gerekli portlar açık (443/HTTPS, 80/HTTP yönlendirmesi) - SSH erişimi sınırlanmış IP'lerden (admin panel) - Veritabanı erişimi uygulama sunucularından yalnızca

DDoS Koruması: - DDoS mitigation hizmeti (CloudFlare, AWS Shield vb.) - Traffic filtering ve rate limiting - Anomali algılama sistemi

5. KÖTÜye KULLANIM ALGILAMA VE KORUNMA

5.1 Kötüye Kullanım Analizi

Şüpheli Etkinlik Tespiti: - Başarısız giriş denemelerinin izlenmesi (5 başarısız = geçici kilitleme) - Olağandışı lokasyon değişiklikleri - Hızlı API istekleri (rate limiting ile) - Toplu veri indirme denemeleri

Otomatik Tepki: - İllegal IP'ler geçici/kalıcı engellenir - Hesap geçici kilitlenir (15-60 dakika) - Şüpheli e-postalar gözden geçirme için bayrak edilir - Sistemci uyarısı gönderilir

5.2 SQL Injection Koruması

SQL Sorguları: - Tüm sorgular parametreli (Prepared Statements) kullanılır - ORM kütüphaneleri kullanılır (Eloquent, SQLAlchemy vb.) - Girdi doğrulama (Input Validation) yapılır - SQL ifadeleri escaping ile korunur

Veri Doğrulama: - Tip doğrulaması (string, integer, boolean vb.) - Boş değer (null) kontrolleri - Regex pattern matching - Whitelist yöntemi (izin verilenler)

5.3 Injection Saldırılarına Karşı Koruma

XSS (Cross-Site Scripting) Koruması: - Çıktı HTML encoding'e tabi tutulur - JavaScript template literals escape edilir - İçerik Security Policy (CSP) header'ları kullanılır - User-generated content sanitization yapılır

Komut Injection Koruması: - System komutları çalıştırılmaz user input ile - Shell_exec, Exec vb. fonksiyonlar kısıtlanır - Parametreler escaping yapılır

6. İNDİRİLEN VERİ VE DOSYA GÜVENLIĞI

6.1 Dosya Yüklemesi (Upload)

Profil Resimleri: - Dosya türü kontrolü: JPEG, PNG, WebP yalnızca - Dosya boyutu sınırı: 5 MB maksimum - Gerçek dosya imzası doğrulanır (magic bytes) - Virüs tarama yapılır (ClamAV vb.)

Depolama: - Yüklenen dosyalar web root dışında saklanır - Dosya adları rasgele oluşturulur (example: abc123def456.jpg) - Orijinal dosya adı sunucuda tutulmaz

Sunulması: - Dosyalar doğrudan URL'den indirilmez - Dosya sunumu authorized endpoint'ten geçer - Access control yapılır (sadece sahip görebilir)

6.2 Resim Önbelleğe Alınması

Cihazda Depolama: - cached_network_image plugin öncellekler resimler - Önbellek dizini uygulama private alanında - İçerik HTTPS kaynağından doğrulanır

Önbellek Yönetimi: - Maksimum önbellek boyutu sınırlanır (100 MB) - Eski dosyalar otomatik silinir (7 gün) - Logout sonrası cache temizlenebilir

7. TERCÜ TARAF ENTEGRASYONLARI GÜVENLIĞI

7.1 Firebase Cloud Messaging (FCM)

Token Güvenliği: - FCM token uygulamada güvenli depolamaya yazılır - Token sunucuya HTTPS ile gönderilir - Token süresi dolduktan sonra otomatik yenilenir - Kullanıcı çıkış yapınca token silinir

Notification Güvenliği: - Notification içeriği şifreli kanal üzerinden gönderilir - Notification yükü maksimum boyut sınırı vardır - Sensitive veriler notification'da gönderilmez - Başlık ve gövde sadece uyarı/bilgi içerir

7.2 OAuth Sağlayıcıları (Google, Apple)

Google Sign-In Güvenliği: - Resmi Google SDK kullanılır - Web Client ID ile doğrulama yapılır - ID Token signature doğrulanır - nonce parameter (replay saldırısı önleme) kullanılır

Apple Sign-In Güvenliği: - Sign in with Apple resmi SDK kullanılır - Private Email Relay desteklenir - JWT signature doğrulanır - Ecosystem ecosystem authentication kullanılır

7.3 Bağımsız Audit

• Üçüncü taraf OAuth sağlayıcıları kendi güvenlik denetimine tabidir
• Bağlantılar HTTPS ile korunur
• Token'lar güvenli storage'da tutulur

8. BUG BOUNTY VE GÜVENLİK AÇILIŞTIRMASI

8.1 Güvenlik Açı Bildirimi

Güvenlik açığını bulursanız, sorumlu şekilde bildirin:

İletişim: - E-posta: bilgi@365gunarapca.com - Konu: [SECURITY] - Bulduğunuz Açık

Bildirim İçermelidir: - Açığın açıklaması - Etki ve ciddiyet (Low, Medium, High, Critical) - Proof of Concept (opsiyonel) - İlgili URL veya endpoint

Yanıt Süreleri: - Critical: 24 saat içinde - High: 48 saat içinde - Medium: 7 gün içinde - Low: 14 gün içinde

8.2 Sorumlu Açıklama (Responsible Disclosure)

Politika: - Açığı herkese açık hale getirmeden önce bize bildiriniz - Açığın düzeltilmesi için makul zaman verin (minimum 30 gün) - Açığın detaylarını kamuya açıklamayın - Sorumlu bildireni kredi ve/veya ödülü alır

Onay: - Açık alınca, onay e-postası gönderilir - Düzeltme progresini bilgilendiririz - Yayından sonra açığı kamuya açılır (36+ ay sonra)

9. VERI İHLALİ VE İNCİDENT YÖNETİMİ

9.1 İhlal Bildirimi Prosedürü

Bir veri ihlali meydana gelirse:

1. Tespit Aşaması (1-2 saat): - Anormal aktivite tespit edilir - İhlal kapsamı ve türü belirlenir - Etkilenen veriler tanımlanır

2. Zarar Sınırlandırma (2-6 saat): - Etkilenen hesaplar geçici kilitlenir - Saldırı kaynağı yalıtılır - Backup'lardan restore yapılır (opsiyonel) - Firewall kuralları güncellenir

3. Soruşturma Aşaması (1-7 gün): - Sistem log'ları analiz edilir - Saldırı yöntemi belirlenir - Tekrar olması için başka zafiyetler aranır - Ön rapor hazırlanır

4. Bildirim Aşaması (72 saat içinde): - Etkilenen kullanıcılara e-posta gönderilir - Neler olduğu açıklanır - Alınan önlemler anlatılır - İletişim bilgileri verilir

5. Kamuya Duyuru (gerekirse): - KVKK Kurulu'na bildirim yapılır - Medya basın açıklaması (ciddi durumda) - Proje yönetimi güncellenir

9.2 Etkilenen Kullanıcı Bildirimi

Bildirim İçeriği: - İhlalin türü (örn: Unauthorized access to user data) - İhlal tarihi ve saati - Etkilenen veriler (örn: Kullanıcı adı, e-posta) - Etkilenen kullanıcı sayısı - Alınan koruyucu önlemler - Kullanıcıların yapması gereken (şifre değiştirme vb.) - İletişim bilgileri

Bildirim Kanalları: - E-posta (birincil) - Uygulama içi bildirim (ikincil) - SMS (kritik durumlarda)

9.3 İncident Raporu

Olay soruşturmasından sonra: - Kapsamlı rapor hazırlanır - Kök sebep analizi yapılır - Önleme ve düzeltme önerileri sunulur - Sistem hardening yapılır

10. YAZILIM GÜVENLİĞİ VE BAĞIMLILIK YÖNETİMİ

10.1 Kod Gözden Geçirme

Kod Review Süreci: - Tüm kod değişiklikleri en az 2 kişi tarafından gözden geçirilir - Güvenlik açıkları için kontrol edilir - Test coverage kontrol edilir (minimum %80) - Code style ve best practices kontrol edilir

Otomatik Tarama: - SAST (Static Application Security Testing) araçları kullanılır - Linting ve code analysis araçları (SonarQube vb.) - Dependency vulnerability scanning

10.2 Bağımlılık Yönetimi

Güncellemeler: - Tüm dependencies düzenli olarak güncellenecektir - Güvenlik patchleri ivedilikle uygulanır - Breaking changes testi yapılır - Staging ortamında test edilir

Vulnerability Tarama: - npm audit, cargo audit, pip audit vb. araçlar kullanılır - Bilinen zafiyetler tarandı - CVSS skoru yüksek olan patchler hemen uygulanır

10.3 Sürüm Kontrolü

Git Güvenliği: - .git dizini sunucuda gözükmez - Credentials (SSH keys, tokens) .gitignore'da - Commit mesajları kontrol edilir - Force push koruması vardır

11. SUNUCU VE ALTYAPI GÜVENLİĞİ

11.1 İşletim Sistemi Güvenliği

Linux Hardening: - Kernel security patches uygulanmıştır - Gereksiz servisler devre dışı - SELinux veya AppArmor etkin (opsiyonel) - Firewall kuralları katı

Dosya Sistem İzinleri: - Web root'un başında olan dosyalar 644 (rw-r--r--) - Dizinler 755 (rwxr-xr-x) - Şifreli dosyalar 600 (rw-------) - Cron scripts 700 (rwx------)

11.2 Sunucu Erişimi

SSH Güvenliği: - SSH anahtarı (key-based) kullanılır (şifre yok) - Root login devre dışı - Varsayılan port 22 kullanılmaz - Failed login attempt sınırı - IP whitelist (opsiyonel)

Sudo Kullanımı: - Sudo yalnızca belirli komutlar için (sudoers dosyası) - Sudo aktivitesi log'lanır - Passwordless sudo (trusted hosts için opsiyonel)

11.3 Sistem Monitoring ve Logging

Log Dosyaları: - Tüm sistem ve uygulama log'ları merkezi yerde toplanır - Log dosyaları 90 gün saklanır - Log dosyaları yazma koruması vardır - Düzenli log rotasyonu yapılır

Monitoring: - Sistem durumu monitoring (CPU, Memory, Disk) - Ağ trafik monitoring - Başarısız login denemelerinin monitoring - Anormal aktivite uyarısı

11.4 Yedekleme ve Afet Kurtarma

Yedekleme: - Günlük veritabanı yedeklemesi yapılır - Yedeklemeler coğrafi olarak dağılmış yerlerde tutulur - Yedeklemeler şifrelidir ve çevrimdışı saklanır - Restore süresi yönetiminin kontrol altında

Afet Kurtarma (DR): - DR planı hazırlanmıştır (hizmet kesinti 4 saatin altında) - RTO (Recovery Time Objective): 4 saat - RPO (Recovery Point Objective): 1 saat - Düzenli DR drilleri yapılır

12. UYGULAMADA GÜVENLIK ÖZELLIKLERI

12.1 Yerel Depolama Güvenliği

Secure Storage Kullanımı: - JWT tokens flutter_secure_storage ile saklanır - SharedPreferences Android 12+ için şifrelenmiş - Cihaz kilidinin açılması gerekir (optional enforcement)

Geçici Bellek: - Hassas veriler (şifre, token) RAM'de sadece işlem süresi kadar kalır - Kullanılıp bittikten sonra memory silinir - String buffer'ları üzerine yazılır

12.2 Uygulama Koruması

Code Obfuscation: - Release build'inde code obfuscate edilir - ProGuard (Android) / Code Obfuscation (iOS) kullanılır - String encryption (sensitive string'ler) - API key'ler encrypted ve runtime'da decrypt edilir

Debuggability Devre Dışı: - Production build'inde debugger devre dışı - Console log'ları production'da minimize - Network interceptor'lar sadece dev build'inde

12.3 Biyometrik Güvenlik

Parmak İzi / Yüz Tanıma: - Cihazın native biyometrik API'si kullanılır - Biyometrik veri cihazda kalır (asla sunucuya gönderilmez) - Başarısız deneme sınırı vardır - Fallback şifre koruması vardır

13. PERSONELİN EĞİTİMİ VE SORUMLULUĞU

13.1 Güvenlik Eğitimi

• Tüm personel OWASP Top 10 eğitimi alır
• Secure coding practices eğitimi yapılır
• Veri koruma ve gizlilik eğitimi (yıllık)
• Sosyal mühendislik farkındalık eğitimi

13.2 Erişim Kontrolü

• Personele minimum gerekli erişim (least privilege)
• Ayrılma sonrasında erişim hemen kesilir
• Yazılı NDA imzalı
• Audit log'ları personel erişimini kaydeder

14. TREHLİK DEĞERLENDİRMESİ

14.1 Tehdit Modeli

Tanımlanan Tehditler: - Unauthorized Access: Hesap hacklenme, credential stuffing - Data Breach: Veritabanı saldırısı, insider threat - Man-in-the-Middle: Network kesintisi, proxy saldırısı - Malware: Trojan, spyware, ransomware - Social Engineering: Phishing, pretexting - Denial of Service: DDoS, resource exhaustion

14.2 Risk Değerlendirmesi

Tehditler şiddet ve olasılığa göre değerlendirilir: - Critical: Immediate action required - High: Fix within 30 days - Medium: Fix within 90 days - Low: Fix within 1 year

15. YASAL UYUM

15.1 Uluslararası Standartlar

• ISO 27001: Bilgi güvenliği yönetim sistemi (uyumlu)
• OWASP Top 10: Web uygulama güvenliği tehditleri (ele alınan)
• PCI-DSS: Ödeme kartı güvenliği (uygun, kart işlemi yok)

15.2 Veri Koruma Kanunları

• KVKK (Türkiye): Kişisel Verileri Koruma Kanunu uyumlu
• GDPR (AB): Avrupa Birliği veri koruma yönetmeliği uyumlu
• COPPA: ABD çocuklar online gizlilik kanunu uyumlu

16. GÜVENLIK İLETİŞİM VE RAPORLAMA

Güvenlik Soruları: - Email: bilgi@365gunarapca.com

Düzenli Bilgilendirmeler: - Aylık güvenlik özeti (iç) - Üçer aylık dış denetim raporu - Yıllık güvenlik değerlendirmesi

---

ENGLISH / İNGİLİZCE

---

SECURITY POLICY

Last Updated: April 29, 2026

1. INTRODUCTION

This Security Policy describes how personal data and system security of Dersin Kelimeleri application users are protected. Security is one of the highest priorities in the application, and measures have been taken at all technical, organizational, and administrative levels.

2. DATA ENCRYPTION AND TRANSMISSION SECURITY

2.1 Encryption in Transit

HTTPS/TLS Protocol: - All server-client communication is encrypted with HTTPS protocol - TLS 1.2 or higher versions are used - SSL/TLS certificates are regularly updated and valid - Certificate pinning increases local security when implemented

API Communication: - All form data for POST, PUT, DELETE operations is encrypted - Sensitive information (passwords, tokens, personal data) is sent using encrypted headers - Request/Response body is encrypted in JSON format

Authentication Tokens: - JWT (JSON Web Token) tokens are sent through HTTPS headers - Token validity is verified on the server side - Token duration is limited (30-60 minutes)

2.2 Encryption at Rest

JWT Tokens: - iOS: Encrypted with flutter_secure_storage using Apple Keychain Services - Android: Encrypted with flutter_secure_storage using Android KeyStore and EncryptedSharedPreferences - Storage Management: Protected by system encryption (TEE - Trusted Execution Environment)

Passwords: - Encrypted on the server side with strong algorithms like bcrypt, scrypt, or PBKDF2 - Password hash functions have at least 10 computation rounds (with salt) - Passwords are never stored in plain text in the application

Profile Pictures: - Stored in a secure server environment - Protected with file system permissions - Served via HTTPS if through CDN

SharedPreferences Data: - Android 12 and higher: Automatically directed to encrypted storage - iOS: Uses iCloud Keychain or encrypted SharedPreferences - Encryption key is managed by the device's security process (TEE)

Database: - Server database encryption at rest is enabled - For example: MySQL Transparent Data Encryption (TDE), PostgreSQL pgcrypto

3. AUTHENTICATION AND ACCESS CONTROL

3.1 Password Security

Password Requirements: - Minimum length: 8 characters - Complexity: At least one uppercase, one lowercase, one digit, one special character - Common passwords are checked (top 100,000 passwords) - Password reuse prevention is enforced

Password Communication: - Password fields are masked in the UI (hidden characters) - Passwords are never logged in log files - Password reset email links are single-use tokens

3.2 JWT Token Management

Token Content: - User ID (UID) - Email address - Permission levels (claims) - Issue time (iat) - Expiration time (exp)

Token Duration: - Access Token: Valid for 30-60 minutes - Refresh Token: Valid for 7-30 days (optional) - Token Rotation: Renewed after certain operations

Token Verification: - Each request is verified on the server side - Signature is verified (with Secret Key) - Expiration time is checked - Invalid signature returns 401 Unauthorized

3.3 Multi-Factor Authentication (MFA)

The application supports the following authentication methods: - Email/Password: First factor - Google Sign-In: OAuth 2.0 (optional) - Apple Sign-In: OAuth 2.0 (optional, iOS) - Biometric Authentication: Fingerprint / Face recognition (on-device, optional)

OAuth Security: - Official SDKs from Google and Apple are used - ID Token is verified on the server side - State parameter (CSRF protection) is used - Redirect URI is restricted

3.4 Session Management

Session Creation: - JWT token is created upon successful login - Token is written to secure storage on the device - Refresh token (if any) is stored separately

Session Termination: - Token is deleted during logout - Token can be added to server-side blacklist - Completely removed from device

Session Timeout: - After token duration expires, renewal is required - Failed renewal requires user to log in again - Inactivity for 30 days may trigger session termination

4. NETWORK TRANSMISSION SECURITY

4.1 Protocol and Encryption Standards

HTTPS Configuration: - TLS Version: Minimum 1.2 (1.3 preferred) - Cipher Suites: Only strong ciphers (AES-256, ChaCha20) - Key Exchange: Forward Secrecy (PFS) enabled (ECDHE, DHE) - Weak ciphers disabled (RC4, DES, etc.)

HSTS (HTTP Strict Transport Security): - HSTS header enabled: Strict-Transport-Security: max-age=31536000; includeSubDomains - Tells browser to enforce HTTPS - Prevents man-in-the-middle (MITM) attacks

4.2 API Request Security

Request Validation: - Content-Type: application/json is validated - Payload size is checked for limits (e.g., max 10 MB) - JSON Schema validation is performed

Rate Limiting: - Maximum requests per minute per IP (e.g., 100 req/min) - Per-user limits per minute (e.g., 1000 req/min) - Exceeded limits return 429 Too Many Requests

CSRF Protection: - CSRF token is provided with each form submission - Token is validated (request origin is checked) - SameSite cookie attribute is used (SameSite=Strict)

4.3 Firewall and DDoS Protection

Firewall Rules: - Only necessary ports are open (443/HTTPS, 80/HTTP redirect) - SSH access restricted to limited IPs (admin panel) - Database access only from application servers

DDoS Protection: - DDoS mitigation service (CloudFlare, AWS Shield, etc.) - Traffic filtering and rate limiting - Anomaly detection system

5. ABUSE DETECTION AND PROTECTION

5.1 Abuse Analysis

Suspicious Activity Detection: - Monitoring failed login attempts (5 failed = temporary lock) - Unusual location changes - Rapid API requests (with rate limiting) - Bulk data download attempts

Automatic Response: - Illegal IPs are temporarily/permanently blocked - Account is temporarily locked (15-60 minutes) - Suspicious emails are flagged for review - System administrator alert is sent

5.2 SQL Injection Protection

SQL Queries: - All queries use parameterized statements (Prepared Statements) - ORM libraries are used (Eloquent, SQLAlchemy, etc.) - Input validation is performed - SQL statements are protected with escaping

Data Validation: - Type validation (string, integer, boolean, etc.) - Null value checks - Regex pattern matching - Whitelist method (permitted values only)

5.3 Protection Against Injection Attacks

XSS (Cross-Site Scripting) Protection: - Output is subject to HTML encoding - JavaScript template literals are escaped - Content Security Policy (CSP) headers are used - User-generated content sanitization is performed

Command Injection Protection: - System commands are not executed with user input - Shell_exec, Exec functions are restricted - Parameters are escaped

6. DOWNLOADED DATA AND FILE SECURITY

6.1 File Upload

Profile Pictures: - File type check: JPEG, PNG, WebP only - File size limit: 5 MB maximum - Real file signature is verified (magic bytes) - Virus scanning is performed (ClamAV, etc.)

Storage: - Uploaded files are stored outside web root - File names are randomly generated (example: abc123def456.jpg) - Original file name is not kept on server

Serving: - Files are not downloaded directly from URL - File serving goes through authorized endpoint - Access control is enforced (only owner can view)

6.2 Image Caching

On-Device Storage: - cached_network_image plugin caches images - Cache directory is in application private area - Content is verified from HTTPS source

Cache Management: - Maximum cache size is limited (100 MB) - Old files are automatically deleted (7 days) - Cache can be cleared after logout

7. THIRD-PARTY INTEGRATIONS SECURITY

7.1 Firebase Cloud Messaging (FCM)

Token Security: - FCM token is written to secure storage in the application - Token is sent to server via HTTPS - Token is automatically renewed after expiration - Token is deleted when user logs out

Notification Security: - Notification content is sent through encrypted channels - Notification payload has maximum size limit - Sensitive data is not sent in notifications - Title and body contain only alerts/information

7.2 OAuth Providers (Google, Apple)

Google Sign-In Security: - Official Google SDK is used - Verification is done with Web Client ID - ID Token signature is verified - Nonce parameter is used (replay attack prevention)

Apple Sign-In Security: - Official Sign in with Apple SDK is used - Private Email Relay is supported - JWT signature is verified - Ecosystem authentication is used

7.3 Independent Audit

• Third-party OAuth providers are subject to their own security audits
• Connections are protected with HTTPS
• Tokens are stored in secure storage

8. BUG BOUNTY AND SECURITY DISCLOSURE

8.1 Security Vulnerability Reporting

If you find a security vulnerability, please report it responsibly:

Contact: - Email: bilgi@365gunarapca.com - Subject: [SECURITY] - Your Finding

Report Should Include: - Description of the vulnerability - Impact and severity (Low, Medium, High, Critical) - Proof of Concept (optional) - Relevant URL or endpoint

Response Times: - Critical: Within 24 hours - High: Within 48 hours - Medium: Within 7 days - Low: Within 14 days

8.2 Responsible Disclosure

Policy: - Report the vulnerability to us before making it public - Allow reasonable time for the fix to be implemented (minimum 30 days) - Do not disclose vulnerability details to the public - Responsible reporter receives credit and/or reward

Confirmation: - Acknowledgment email is sent upon receipt - We will update you on fix progress - Vulnerability is disclosed to public after release (36+ months later)

9. DATA BREACH AND INCIDENT MANAGEMENT

9.1 Breach Notification Procedure

If a data breach occurs:

1. Detection Phase (1-2 hours): - Abnormal activity is detected - Breach scope and type are determined - Affected data is identified

2. Damage Containment (2-6 hours): - Affected accounts are temporarily locked - Attack source is isolated - Restore from backups is performed (if needed) - Firewall rules are updated

3. Investigation Phase (1-7 days): - System logs are analyzed - Attack method is determined - Other vulnerabilities are searched - Preliminary report is prepared

4. Notification Phase (within 72 hours): - Affected users are notified via email - What happened is explained - Measures taken are described - Contact information is provided

5. Public Disclosure (if necessary): - Notification is made to KVKK Authority - Press release is issued (if serious) - Project management is updated

9.2 Affected User Notification

Notification Content: - Type of breach (e.g., Unauthorized access to user data) - Date and time of breach - Data affected (e.g., Username, email) - Number of affected users - Protective measures taken - What users should do (e.g., change password) - Contact information

Notification Channels: - Email (primary) - In-app notification (secondary) - SMS (in critical cases)

9.3 Incident Report

After incident investigation: - Comprehensive report is prepared - Root cause analysis is performed - Prevention and remediation recommendations are provided - System hardening is performed

10. SOFTWARE SECURITY AND DEPENDENCY MANAGEMENT

10.1 Code Review

Code Review Process: - All code changes are reviewed by at least 2 people - Checked for security vulnerabilities - Test coverage is verified (minimum 80%) - Code style and best practices are checked

Automated Scanning: - SAST (Static Application Security Testing) tools are used - Linting and code analysis tools (SonarQube, etc.) - Dependency vulnerability scanning

10.2 Dependency Management

Updates: - All dependencies are regularly updated - Security patches are applied immediately - Breaking changes are tested - Tested in staging environment

Vulnerability Scanning: - npm audit, cargo audit, pip audit tools are used - Known vulnerabilities are scanned - High CVSS score patches are applied immediately

10.3 Version Control

Git Security: - .git directory is not visible on server - Credentials (SSH keys, tokens) are in .gitignore - Commit messages are reviewed - Force push protection is in place

11. SERVER AND INFRASTRUCTURE SECURITY

11.1 Operating System Security

Linux Hardening: - Kernel security patches are applied - Unnecessary services are disabled - SELinux or AppArmor is enabled (optional) - Firewall rules are strict

File System Permissions: - Files at web root have 644 (rw-r--r--) - Directories have 755 (rwxr-xr-x) - Encrypted files have 600 (rw-------) - Cron scripts have 700 (rwx------)

11.2 Server Access

SSH Security: - SSH key-based authentication is used (no password) - Root login is disabled - Default port 22 is not used - Failed login attempt limit is set - IP whitelist is optional

Sudo Usage: - Sudo is only for specific commands (sudoers file) - Sudo activity is logged - Passwordless sudo for trusted hosts (optional)

11.3 System Monitoring and Logging

Log Files: - All system and application logs are collected centrally - Logs are retained for 90 days - Log files have write protection - Regular log rotation is performed

Monitoring: - System health monitoring (CPU, Memory, Disk) - Network traffic monitoring - Failed login attempt monitoring - Anomaly activity alerts

11.4 Backup and Disaster Recovery

Backup: - Daily database backups are performed - Backups are stored in geographically distributed locations - Backups are encrypted and stored offline - Restore time is under management control

Disaster Recovery (DR): - DR plan is prepared (service downtime under 4 hours) - RTO (Recovery Time Objective): 4 hours - RPO (Recovery Point Objective): 1 hour - Regular DR drills are conducted

12. APPLICATION SECURITY FEATURES

12.1 Local Storage Security

Secure Storage Usage: - JWT tokens are stored with flutter_secure_storage - SharedPreferences are encrypted on Android 12+ - Device unlock can be required (optional enforcement)

Temporary Memory: - Sensitive data (passwords, tokens) remain in RAM only during processing - Cleared from memory after use - String buffers are overwritten

12.2 Application Protection

Code Obfuscation: - Code is obfuscated in release build - ProGuard (Android) / Code Obfuscation (iOS) is used - String encryption for sensitive strings - API keys are encrypted and decrypted at runtime

Debugging Disabled: - Debugger is disabled in production build - Console logs are minimized in production - Network interceptors are only in dev build

12.3 Biometric Security

Fingerprint / Face Recognition: - Device's native biometric API is used - Biometric data remains on device (never sent to server) - Failed attempt limit is set - Fallback password protection is available

13. PERSONNEL TRAINING AND RESPONSIBILITY

13.1 Security Training

• All personnel receive OWASP Top 10 training
• Secure coding practices training is provided
• Data protection and privacy training (annual)
• Social engineering awareness training

13.2 Access Control

• Personnel receive minimum necessary access (least privilege)
• Access is immediately revoked upon departure
• Written NDA is signed
• Audit logs record personnel access

14. THREAT ASSESSMENT

14.1 Threat Model

Identified Threats: - Unauthorized Access: Account hacking, credential stuffing - Data Breach: Database attack, insider threat - Man-in-the-Middle: Network interception, proxy attack - Malware: Trojan, spyware, ransomware - Social Engineering: Phishing, pretexting - Denial of Service: DDoS, resource exhaustion

14.2 Risk Assessment

Threats are evaluated based on severity and likelihood: - Critical: Immediate action required - High: Fix within 30 days - Medium: Fix within 90 days - Low: Fix within 1 year

15. LEGAL COMPLIANCE

15.1 International Standards

• ISO 27001: Information security management system (compliant)
• OWASP Top 10: Web application security threats (addressed)
• PCI-DSS: Payment card security (compliant, no card processing)

15.2 Data Protection Laws

• KVKK (Turkey): Personal Data Protection Law compliant
• GDPR (EU): European Union data protection regulation compliant
• COPPA: US Children's Online Privacy Protection Act compliant

16. SECURITY COMMUNICATION AND REPORTING

Security Questions: - Email: bilgi@365gunarapca.com

Regular Notifications: - Monthly security summary (internal) - Quarterly external audit report - Annual security assessment

---

End of Security Policy / Güvenlik Politikası Sonu