Az API biztonság ma már nem csak fejlesztői részletkérdés. A legtöbb modern webes és mobilalkalmazás API-kon keresztül kommunikál: így éri el a felhasználói adatokat, a fizetési szolgáltatót, a CRM-et, a felhős tárhelyet vagy akár egy AI-modellt. Ezek az interfészek sokszor „láthatatlan kapuk” a háttérrendszerek felé – éppen ezért különösen vonzó célpontjai a támadóknak.
Egy jól működő API gyors, dokumentált és könnyen integrálható. Egy nem megfelelően védett API viszont adatszivárgáshoz, jogosulatlan műveletekhez vagy szolgáltatáskimaradáshoz vezethet. A kockázatot növeli, hogy az API-kat gyakran gépek használják, nagy sebességgel, automatizált módon – vagyis egy hiba rövid idő alatt nagy károkat okozhat.
Miért más az API védelem, mint egy hagyományos weboldal védelme?
Egy weboldalnál a felhasználói felület is ad némi kontextust: gombok, űrlapok, navigációs elemek határozzák meg, mit lehet tenni. Egy API esetében viszont a támadó közvetlenül a végpontokat próbálgathatja. Ha például létezik egy /users/1234/invoices végpont, könnyen kipróbálható, hogy a 1234 azonosító lecserélésével hozzá lehet-e férni más felhasználók számláihoz.
Ez az úgynevezett objektumszintű jogosultsági hiba tipikus API-probléma. Nem elég ellenőrizni, hogy a felhasználó be van-e jelentkezve. Azt is vizsgálni kell, hogy valóban jogosult-e az adott erőforrás, például rendelés, dokumentum vagy ügyféladat elérésére.
Az API támadások gyakran nem látványosak. Nem feltétlenül járnak weboldal-leállással vagy nyilvánvaló hibával. Előfordulhat, hogy valaki csendben adatokat kérdez le, automatizáltan próbál jelszavakat, vagy túl sok kéréssel terheli a rendszert. Ezért az API védelemnek nemcsak megelőzésből, hanem naplózásból, monitorozásból és gyors reagálásból is állnia kell.
Hitelesítés és jogosultságkezelés: nem ugyanaz a kettő
A hitelesítés és jogosultságkezelés az API biztonság alapja, de gyakran összemosódik a két fogalom. A hitelesítés azt válaszolja meg, hogy „ki vagy te?”. A jogosultságkezelés pedig azt, hogy „mit tehetsz meg?”.
Egy gyakorlati példa: egy mobilalkalmazás felhasználója sikeresen bejelentkezik, tehát hitelesített. Ettől még nem férhet hozzá más ügyfelek adataihoz, nem módosíthat adminisztrátori beállításokat, és nem hívhat meg belső rendszereknek fenntartott API-végpontokat. Ezeket külön jogosultsági szabályokkal kell korlátozni.
API-k esetében gyakori megoldás a tokenalapú azonosítás, például rövid élettartamú hozzáférési tokenekkel. Fontos, hogy a token ne tartalmazzon indokolatlanul sok jogosultságot, ne legyen korlátlan ideig érvényes, és ne kerüljön naplófájlokba vagy kliensoldali kódban könnyen kinyerhető helyre.
Hasznos gyakorlat a legkisebb jogosultság elve: minden alkalmazás, szolgáltatás és felhasználó csak ahhoz férjen hozzá, amire valóban szüksége van. Egy riportáló rendszernek például jellemzően olvasási jog kell, nem törlési vagy módosítási lehetőség.
Rate limiting: egyszerű eszköz, nagy hatással
A rate limiting azt szabályozza, hogy egy kliens, felhasználó vagy IP-cím adott idő alatt mennyi API-kérést indíthat. Ez nem csodaszer, de sok hétköznapi kockázat ellen hatékony védelmi réteg.
Segíthet például brute force próbálkozásoknál, amikor egy támadó sok jelszót vagy kódot tesztel. Hasznos lehet scraping ellen is, amikor valaki tömegesen próbál adatokat kinyerni. Emellett védi az infrastruktúrát a véletlen túlterheléstől is: egy hibásan megírt integráció akár szándékosság nélkül is rengeteg kérést küldhet.
A jó rate limiting nemcsak globális korlátot jelent. Érdemes külön kezelni az érzékeny végpontokat, például a bejelentkezést, jelszó-visszaállítást, fizetési műveleteket vagy nagy erőforrás-igényű lekérdezéseket. Fontos az is, hogy a rendszer érthető hibaválaszt adjon, például jelezze, ha a kliens túl sok kérést küldött, de ne áruljon el felesleges technikai részleteket.
OWASP API Security: jó kiindulópont a kockázatokhoz
Az OWASP API Security ajánlásai hasznos keretet adnak ahhoz, milyen hibákra érdemes különösen figyelni. Ilyen például a hibás objektumszintű jogosultságkezelés, a túlzott adatszolgáltatás, a nem megfelelő autentikáció, a hiányos erőforrás-korlátozás vagy az API-k nem biztonságos konfigurációja.
A „túlzott adatszolgáltatás” tipikus példa. Ha egy API a felhasználói profil lekérdezésekor visszaadja a teljes adatbázisrekordot, benne belső azonosítókkal, szerepkörökkel vagy technikai mezőkkel, akkor a kliens ugyan lehet, hogy csak a név és e-mail cím mezőt jeleníti meg, de az érzékeny adatok már elhagyták a szervert. API-k esetében a backendnek kell eldöntenie, mi adható ki, nem a frontendnek kell „elrejtenie” a felesleget.
Ugyanilyen fontos a verziók és régi végpontok kezelése. Sok szervezetnél maradnak hátra elfelejtett API-k, amelyeket már nem dokumentálnak, de még elérhetők. Ezek gyakran gyengébb védelmet kapnak, miközben ugyanazokhoz az adatokhoz vezethetnek.
Gyakorlati ellenőrzőlista API biztonsághoz
- Dokumentáld az API-kat: tudd, milyen végpontok léteznek, kik használják őket, és milyen adatokat érnek el.
- Ellenőrizd a jogosultságot minden kérésnél: ne csak a bejelentkezést vizsgáld, hanem az adott objektumhoz való hozzáférést is.
- Használj rate limitinget: különösen érzékeny vagy erőforrás-igényes végpontokon.
- Minimalizáld a válaszokat: csak azt az adatot add vissza, amire a kliensnek ténylegesen szüksége van.
- Naplózz ésszerűen: legyen követhető a gyanús aktivitás, de tokeneket, jelszavakat és érzékeny adatokat ne írj logba.
- Tesztelj negatív eseteket is: például más felhasználó azonosítójával, lejárt tokennel, túl sok kéréssel vagy hiányos paraméterekkel.
Az API biztonság nem egyetlen beállítás vagy termék kérdése, hanem folyamatos mérnöki fegyelem. A jól megtervezett API védelem a fejlesztési folyamat része: már a tervezésnél számol a jogosultságokkal, a terheléssel, a naplózással és a hibakezeléssel. Ha ezek a „láthatatlan kapuk” megfelelő kontrollt kapnak, az alkalmazás nemcsak működőképesebb, hanem ellenállóbb is lesz a valós támadásokkal szemben.
