Hogyan biztonságosítasz egy REST API-t (hitelesítés, jogosultságkezelés, szállítás)?

Question

IT Interview Practice · Accepted Answer

Egy REST API biztonságossá tétele azt jelenti, hogy minden kérésnél három kérdésre válaszolsz: **ki vagy** (authentication), **mit szabad tenned** (authorization), és **privát-e a csatorna** (transport). Mivel a REST **stateless**, a credentialeknek minden kéréssel utazniuk kell, nem pedig egy server-sessionben élniük.

## Szállítás: mindig HTTPS

Minden alábbi **TLS/HTTPS**-t feltételez. Nélküle a tokenek és API key-ek plaintextben utaznak, és lehallgathatók. Ez nem alku tárgya — egy HTTP-n átküldött bearer token egy kiszivárgott token.

## Hitelesítési lehetőségek

**API key-ek** — egy statikus titok egy headerben. Egyszerű; jó server-to-server-hez és egy *alkalmazás* azonosításához, nem egy user-éhez. Önmagukban gyengék (nincs lejárat, nincs scope), hacsak nem párosítod többel.
```http
GET /data HTTP/1.1
Authorization: Bearer sk_live_a1b2c3...
```

**OAuth 2.0** — a **delegált** hozzáférés szabványa ("engedd, hogy az X app elolvassa az adataimat a jelszavam nélkül"). Az app egy flow-n (pl. Authorization Code) keresztül szerez egy **access tokent**, és bearer tokenként küldi el. Így működik a "Sign in with Google" és a harmadik feles integrációk.

**JWT (JSON Web Token)** — egy gyakori *formátum* a tokenekhez: egy aláírt, önmagában teljes token, amely claimeket hordoz (user id, szerepkörök, lejárat). A server ellenőrzi az aláírást — nincs szükség adatbázis-lekérdezésre, ami illik a stateless REST-hez.
```text
header.payload.signature   (base64url)
payload: { "sub": "42", "scope": "orders:read", "exp": 1737800000 }
```

## Jogosultságkezelés: scope-ok és szerepkörök

A hitelesítés bizonyítja az identitást; a **jogosultságkezelés** dönti el a hozzáférést. A tokenek **scope-okat** (`orders:read`, `orders:write`) vagy szerepköröket hordoznak; a server endpointonként ellenőrzi őket, és `403 Forbidden`-t ad vissza, ha nem elegendők (szemben a `401`-gyel a hiányzó/érvénytelen auth esetén).

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

## Egyéb alapvetések

```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
```

## Miért fontos

A biztonság az, ahol egy kis hiba adatszivárgássá válik, ezért az interjúztatók ezzel nézik meg, hogy strukturáltan gondolkodsz-e róla, nem pedig buzzwordöket sorolsz. A jel, amit keresnek, hogy **szétválasztod a három réteget** — transport (HTTPS, mindig), authentication (az identitás stateless bizonyítása bearer tokenekkel/JWT/OAuth-tal) és authorization (scope-ok és least privilege) —, és nem mosod össze őket, pl. helyesen használva a `401`-et a "nincs hitelesítve", a `403`-at a "hitelesítve, de nincs engedélyezve" esetére. Az erős válaszok tudatában vannak a gyakorlati kompromisszumoknak: a JWT-k kényelmesek és statelessek, de nehezen visszavonhatók lejáratuk előtt (ezért rövid élettartam plusz refresh tokenek), az API key-ek appokat azonosítanak, nem usereket, és az OAuth kifejezetten azért létezik, hogy a felhasználók ne adják át a jelszavukat harmadik feleknek. Ha ezt a REST statelessségéhez kötöd — credentialek minden kérésen, nincs server-session —, az megmutatja, hogy érted, *miért* néz ki úgy az API-biztonság, ahogy.

Szállítás: mindig HTTPS

Hitelesítési lehetőségek

Jogosultságkezelés: scope-ok és szerepkörök

Egyéb alapvetések

Miért fontos

Kapcsolódó kérdések