Bir REST API'yi nasıl güvenli kılarsınız (kimlik doğrulama, yetkilendirme, taşıma)?

Question

IT Interview Practice · Accepted Answer

Bir REST API'yi güvenli kılmak, her istekte üç soruyu yanıtlamak demektir: **sen kimsin** (authentication), **ne yapmana izin var** (authorization) ve **kanal özel mi** (transport). REST **stateless** olduğu için, credential'lar bir server session'ında yaşamak yerine her istekle birlikte gitmelidir.

## Taşıma: her zaman HTTPS

Aşağıdaki her şey **TLS/HTTPS** varsayar. O olmadan, token'lar ve API key'ler düz metin (plaintext) olarak gider ve dinlenebilir (sniff). Bu pazarlık konusu değildir — HTTP üzerinden bir bearer token, sızdırılmış bir token'dır.

## Kimlik doğrulama seçenekleri

**API key'ler** — bir header'daki statik bir sır. Basit; server-to-server için ve bir user'ı değil bir *uygulamayı* tanımlamak için iyidir. Daha fazlasıyla eşleştirilmedikçe tek başlarına zayıftır (son kullanma yok, scope yok).
```http
GET /data HTTP/1.1
Authorization: Bearer sk_live_a1b2c3...
```

**OAuth 2.0** — **yetki devri (delegated)** ile erişim için standart ("App X'in verilerimi şifrem olmadan okumasına izin ver"). Uygulama bir akış (ör. Authorization Code) aracılığıyla bir **access token** alır ve onu bir bearer token olarak gönderir. "Sign in with Google" ve üçüncü taraf entegrasyonları böyle çalışır.

**JWT (JSON Web Token)** — token'lar için yaygın bir *format*: claim'ler (user id, rol'ler, son kullanma) taşıyan, imzalı, kendi kendine yeten bir token. Server imzayı doğrular — veritabanı araması gerekmez, bu da stateless REST'e uyar.
```text
header.payload.signature   (base64url)
payload: { "sub": "42", "scope": "orders:read", "exp": 1737800000 }
```

## Yetkilendirme: scope'lar ve rol'ler

Authentication kimliği kanıtlar; **authorization** erişime karar verir. Token'lar **scope**'lar (`orders:read`, `orders:write`) ya da rol'ler taşır; server bunları endpoint başına kontrol eder ve yetersiz olduklarında `403 Forbidden` döndürür (eksik/geçersiz auth için `401`'e karşılık).

```text
No/invalid token         → 401 Unauthorized
Valid token, no scope    → 403 Forbidden
```

## Diğer temel gereklilikler

```text
✓ Short-lived access tokens + refresh tokens (limit blast radius if leaked)
✓ Rate limiting (429) to blunt brute-force and abuse
✓ Validate/sanitize all input; never trust the client
✓ Principle of least privilege on scopes
```

## Neden önemli

Güvenlik, küçük bir hatanın bir ihlale dönüştüğü yerdir, bu yüzden mülakatçılar bunu, buzzword'leri ezberden okumak yerine yapısal olarak akıl yürütüp yürütmediğinizi görmek için kullanır. Aradıkları sinyal, **üç katmanı ayırdığınız** — transport (HTTPS, her zaman), authentication (kimliği stateless biçimde, bearer token/JWT/OAuth ile kanıtlamak) ve authorization (scope'lar ve least privilege) — ve bunları birbirine karıştırmadığınız, ör. "kimlik doğrulanmamış" için doğru şekilde `401`'i, "kimlik doğrulanmış ama izinli değil" için `403`'ü kullandığınızdır. Güçlü cevaplar pratik ödünleşimlerin farkındalığını gösterir: JWT'ler kullanışlı ve stateless'tır ama son kullanma tarihinden önce iptal edilmesi zordur (bu yüzden kısa ömürler artı refresh token'lar), API key'ler user'ları değil app'leri tanımlar ve OAuth tam da kullanıcıların şifrelerini üçüncü taraflara vermemesi için vardır. Bunu REST'in statelessness'ına bağlamak — her istekte credential, server session yok — API güvenliğinin *neden* böyle göründüğünü anladığınızı gösterir.

Taşıma: her zaman HTTPS

Kimlik doğrulama seçenekleri

Yetkilendirme: scope'lar ve rol'ler

Diğer temel gereklilikler

Neden önemli

İlgili sorular