API Guvenlik Rehberi: Guvenli API Gelistirme

API Guvenligi Nedir ve Neden Onemlidir?

API'ler (Application Programming Interface), modern yazilim mimarisinin temel yapi taslarini olusturur. Mobil uygulamalardan web servislerine, ucuncu parti entegrasyonlardan mikro servis iletisimine kadar her noktada API'ler veri alisverisini saglar. Ancak bu yayginlik, API'leri saldirganlarin oncelikli hedefi haline getirir. 2026 yilinda OWASP verilerine gore, web uygulamalarindaki guvenlik ihlallerinin buyuk cogunlugu API katmanindaki acikliklar uzerinden gerceklesmektedir.

API guvenligi, yalnizca yetkisiz erisimi engellemekle sinirli degildir. Veri butunlugunu korumak, kullanici gizliligini saglamak, hizmet surekliligini garantilemek ve yasal uyumluluk gereksinimlerini karsilamak da API guvenliginin kapsamina girer. Bu rehberde, API guvenliginin temel ayaklarini detayli sekilde inceleyecek ve uygulamali oneriler sunacagiz.

Kimlik Dogrulama Yontemleri

API guvenliginin ilk ve en kritik adimi, istegi gonderen tarafin kimligini dogrulamaktir. Farkli senaryolar icin farkli kimlik dogrulama yontemleri tercih edilir.

JWT (JSON Web Token)

JWT, istemci ve sunucu arasinda guvenli bilgi tasimak icin kullanilan acik bir standarttir (RFC 7519). Uc parcadan olusur: Header (algoritma bilgisi), Payload (kullanici verileri ve claims) ve Signature (dogrulama imzasi). Token, Base64 ile kodlanir ve nokta ile ayrilir.

• Avantajlari: Durumsuz (stateless) yapisi sayesinde sunucu tarafinda oturum saklamaya gerek yoktur. Olceklenebilirlik icin idealdir.
• Access Token ve Refresh Token: Access token kisa omurlu (15-30 dakika) tutulmali, refresh token ile yenilenmelidir. Refresh token'lar guvenli sekilde saklanmali ve tek kullanimlik olmalidir.
• Guvenlik onlemleri: Token'lari HttpOnly cookie'lerde saklayin, HS256 yerine RS256 veya ES256 algoritmasini tercih edin, token icerisine hassas veri koymaktan kacinin.
• Token iptali: JWT'nin durumsuz dogasi token iptalini zorlastirir. Blacklist mekanizmasi veya kisa omurlu token stratejisi uygulanayin.

OAuth 2.0

OAuth 2.0, ucuncu parti uygulamalarin kullanici adina kaynaklara erisimini yetkilendirmek icin kullanilan bir cevrecidir. Kullanicinin sifresini paylasmadan sinirli erisim izni verilmesini saglar. Dort temel akis (grant type) vardir:

1. Authorization Code Grant: Web uygulamalari icin en guvenli akistir. Yetkilendirme kodu sunucu tarafinda access token ile degistirilir. PKCE (Proof Key for Code Exchange) ile birlikte kullanilmasi sart kosulmustur.
2. Client Credentials Grant: Makine-makine iletisiminde kullanilir. Kullanici etkilesimi yoktur; istemci kendi kimlik bilgileriyle token alir.
3. Device Authorization Grant: Giris yapisi sinirli cihazlar (smart TV, IoT) icin tasarlanmistir.
4. Implicit Grant (Kullanimdan Kaldirilan): Guvenlik riskleri nedeniyle artik onerilmemektedir. Yerine Authorization Code + PKCE kullanilmalidir.

API Anahtarlari (API Keys)

API anahtarlari, istegi gonderen uygulamayi tanimlamak icin kullanilan basit bir yontemdir. Genellikle istek basliginda (X-API-Key) veya sorgu parametresinde gonderilir. API anahtarlari tek basina yeterli bir guvenlik katmani degildir; kimlik dogrulama degil, istemci tanimlama amaclidir.

• API anahtarlarini URL parametresi yerine HTTP basliginda gonderin; URL'ler loglarda gorunur.
• Her istemci icin ayri anahtar uretin ve izinleri sinirlandirin.
• Anahtarlari duzenli olarak rotate edin (donemsel yenileyin).
• Sunucu tarafinda anahtarlari hash'leyerek saklayin, duz metin olarak depolamayin.
• Kullanim disi kalan anahtarlari hemen iptal edin.

Rate Limiting (Hiz Sinirlandirma)

Rate limiting, belirli bir zaman diliminde bir istemciden gelen istek sayisini sinirlandirarak API'nizi kotu niyetli kullanim, DDoS saldirilari ve kaynak tuketimi gibi tehditlere karsi korur.

• Sabit Pencere (Fixed Window): Belirli bir zaman diliminde (ornegin dakikada 100 istek) sabit bir sinir uygular. Uygulamasi basittir ancak pencere sinirinda burst trafikten etkilenebilir.
• Kayar Pencere (Sliding Window): Zamani kayan bir pencere ile izler, daha adil bir dagilim saglar.
• Token Bucket: Istemciye belirli sayida "jeton" verilir; her istekte bir jeton harcanir ve jetonlar sabit hizda yenilenir. Burst trafik ve duzenli trafik arasinda denge kurar.
• Leaky Bucket: Istekler sabit bir hizda islenir; fazla istekler siraya alinir veya reddedilir.

Rate limiting uygularken X-RateLimit-Limit, X-RateLimit-Remaining ve X-RateLimit-Reset basliklarini yanita ekleyin. Limit asildiginda 429 Too Many Requests durum kodu dondurun ve istemciye ne zaman tekrar deneyebilecegini bildiren Retry-After basligini ekleyin.

Girdi Dogrulama (Input Validation)

API'lere gelen her veri potansiyel bir tehdit tasir. Girdi dogrulama, SQL injection, XSS (Cross-Site Scripting), komut enjeksiyonu ve diger enjeksiyon saldirilarina karsi ilk savunma hattinizdir.

• Sema dogrulamasi: Gelen JSON verisini bir semaya karsi dogrulayin. Zod, Joi veya JSON Schema gibi kutuphaneler kullanin. Beklenen alanlarin tipini, uzunlugunu, formatini ve zorunlulugunu kontrol edin.
• Beyaz liste yaklasimi: Bilinen ve gecerli degerleri kabul edin; bilinmeyen her seyi reddedin. Kara liste yaklasimi (bilinen kotuyu engellemek) her zaman atlanabilir.
• Parametrize sorgular: Veritabani sorgularinda kullanici girdilerini asla dogrudan birlestirmeyin. Parametrize sorgular veya ORM kullanin.
• Icerik tipi kontrolu: Content-Type basligini kontrol edin ve yalnizca beklenen formatlari kabul edin.
• Boyut sinirlamasi: Istek govdesine (request body) makul bir boyut siniri koyun. Buyuk dosya yuklemelerini ayri bir endpoint uzerinden yonetin.
• Cikti kodlamasi: API yanitlarinda kullanici girdisini yansitirken uygun kodlama uygulayin; ozellikle HTML icerigi donduruyorsaniz XSS riskine karsi onlem alin.

CORS (Cross-Origin Resource Sharing)

CORS, tarayicilarin farkli kokenlerden (origin) gelen istekleri kontrol etmesini saglayan bir guvenlik mekanizmasidir. Yanlis yapilandirilan CORS politikalari, yetkisiz web sitelerinin API'nize erisimini mumkun kilar.

• Origin beyaz listesi: Access-Control-Allow-Origin basliginda joker karakter (*) kullanmayin. Yalnizca guvenilen domainleri beyaz listeye alin.
• Preflight istekleri: Tarayicilar, belirli istek turlerinde once bir OPTIONS istegi gonderir. Bu istegi dogru sekilde yanitlayin ve gereksiz bilgi sizintisini onleyin.
• Kimlik bilgileri: Access-Control-Allow-Credentials: true ayarini yalnizca gerekli oldugunda kullanin ve bu durumda * origin kullanmayin.
• Izin verilen basliklar ve metodlar: Access-Control-Allow-Methods ve Access-Control-Allow-Headers degerlerini mumkun oldugunca daralttin.
• Onbellek suresi: Access-Control-Max-Age ile preflight yanitlarini onbellege alin; gereksiz OPTIONS isteklerini azaltin.

HTTPS ve Iletisim Guvenligi

HTTPS, istemci ile sunucu arasindaki tum iletisimi sifreleyerek ortadaki adam (man-in-the-middle) saldirilarina karsi koruma saglar. 2026 yilinda HTTP kullanan bir API kabul edilemez bir guvenlik acigi olusturur.

• TLS 1.3 kullanin: Eski TLS surumlerini (1.0, 1.1) ve SSL'i devre disi birakin. TLS 1.3, daha hizli el sikisma ve daha guclu sifreleme sunar.
• HSTS (HTTP Strict Transport Security): Tarayicinin yalnizca HTTPS uzerinden baglanti kurmasini zorunlu kilar. Strict-Transport-Security basligini tum yanitlara ekleyin.
• Sertifika sabitleme (Certificate Pinning): Mobil uygulamalarda sunucu sertifikasini sabitleyerek sahte sertifika kullanimini engelleyin.
• Dahili iletisim: Mikro servisler arasi iletisimde de TLS kullanin (mTLS — mutual TLS). Ic agda bile sifrelenmemis iletisim risk tasir.

Ek Guvenlik Katmanlari

Temel guvenlik onlemlerinin otesinde, asagidaki ek katmanlar API guvenliginizi guclendirir:

• API Gateway: Tum API trafiginizi merkezi bir noktadan yonetin. Kimlik dogrulama, rate limiting, loglama ve izleme islemlerini gateway katmaninda yapin.
• Loglama ve izleme: Tum API isteklerini loglayin. Anormal trafik kaliplarini tespit eden alarm sistemleri kurun. IP adresi, kullanici kimligi, endpoint, durum kodu ve yanit suresi gibi verileri kaydedin.
• Versiyon yonetimi: API surumlerini yonetin ve eski surumleri belirli bir sure sonra devre disi birakin. Eski surumlerdeki guvenlik aciklari yamalanamayabilir.
• Yetkilendirme granulerligi: Kimlik dogrulama sonrasinda, kullanicinin talep ettigi kaynaga erisim izni olup olmadigini kontrol edin. En az yetki ilkesini (principle of least privilege) uygulayin.
• Hassas veri maskeleme: API yanitlarinda gereksiz hassas veri donmekten kacinin. Sifre hash'leri, dahili kimlikler ve kisisel verileri filtreleyin.

OWASP API Security Top 10

OWASP, API'lere ozgu en yaygin guvenlik risklerini su sekilde siralar:

API Guvenlik Kontrol Listesi

Uygulamanizi yayina almadan once asagidaki kontrol listesini gozden gecirin:

1. Tum endpoint'lerde kimlik dogrulama ve yetkilendirme kontrolleri var mi?
2. JWT token'lari kisa omurlu mu ve refresh mekanizmasi dogru calisiyor mu?
3. Rate limiting tum endpoint'lerde aktif mi?
4. Tum girdiler dogrulanip temizleniyor mu?
5. CORS politikasi dogru yapilandirilmis mi?
6. HTTPS zorunlu mu ve TLS 1.3 kullaniliyor mu?
7. API yanitlarinda gereksiz hassas veri donuyor mu?
8. Hata mesajlari hassas bilgi sizdiriyor mu?
9. API loglari merkezi bir sistemde toplanip izleniyor mu?
10. Guvenlik taramalari ve penetrasyon testleri duzenli yapiliyor mu?

Sonuc:API guvenligi, tek bir onlemle saglanacak bir sey degildir; derinlemesine savunma (defense in depth) yaklasimi ile katmanli bir guvenlik stratejisi olusturulmaldir. Kimlik dogrulama, yetkilendirme, girdi dogrulama, iletisim sifreleme ve izleme gibi katmanlarin her biri birbirini tamamlar. API'lerinizi tasarim asamasindan itibaren guvenlik odakli (security by design) gelistirin ve duzenli guvenlik degerlendirmeleri ile surekli iyilestirin.