A legtöbb csapat hitelesítési kérdésként kezeli az API-biztonságot. Bevezetik a tokeneket, minden útvonalon ellenőrzik őket, és ezzel késznek tekintik a munkát. Aztán egy tesztelő átír egyetlen számot az URL-ben, és elolvassa egy másik ügyfél számláját.

Éppen ebben a résben, a „hitelesített” és a „jogosult” között lakik a valódi API-incidensek túlnyomó többsége, és ezt egy szkenner nem találja meg megbízhatóan. Az automatizált eszköz lát egy érvényes tokent meg egy 200-as választ, és sikert jelent. Csak az veszi észre, hogy a válaszban valaki más adatai voltak, aki érti az üzleti szabályaidat.

A lényegi különbség: a hitelesítés azt bizonyítja, ki hív. A jogosultságkezelés azt dönti el, hogy pontosan az a hívó mit láthat vagy módosíthat, és ezt minden objektumra, minden kérésnél, az adatrétegben kell érvényesíteni. Szinte minden komoly API-sebezhetőség a második hibája, miközben az első tökéletesen működik.

Objektumszintű jogosultsági hiba, és miért ez vezet a listán

A leggyakoribb súlyos API-hiba egyben a legegyszerűbben leírható is.

A végpontod /api/invoices/48213. A hívó hitelesített, tehát a kezelő lekéri a 48213-as számlát, és visszaadja. Senki nem ellenőrzi, hogy a 48213-as számla egyáltalán ehhez a hívóhoz tartozik-e. Átírod a számot, és megkapod valaki más számláját. Az API pontosan úgy viselkedett, ahogyan megírták; maga a megírás volt hibás.

Ez rosszul skálázódik neked, és kiválóan a támadónak. A sorfolytonos azonosítók lehetővé teszik, hogy valaki egyetlen ciklussal végigjárja a teljes adatállományodat. A kitalálhatatlan azonosítókra váltás valamennyit segít, de nem javítás, mert az azonosítók más végpontokon, exportokon és e-maileken keresztül úgyis kiszivárognak.

A javítás szerkezeti, nem esetleges. A tulajdonviszonyt magában a lekérdezésben kell ellenőrizni: azt a számlát kérd le, amely ehhez az ügyfélhez tartozik és ezt az azonosítót viseli, ahelyett hogy lekérnéd a számlát, és bíznál benne, hogy majd később valami ellenőrzi. Tedd ezt az ellenőrzést az adathozzáférési rétegbe, hogy ne lehessen kifelejteni egy új vezérlőből, amelyet fél év múlva ír meg valaki, aki ezt a bekezdést soha nem olvasta.

Ugyanez a hiba a függvényekre is áll, nemcsak az objektumokra. Ha egy adminisztratív végpontot csak az véd, hogy a felület a hétköznapi felhasználóknak nem hivatkozik rá, akkor egyáltalán nincs védve.

Az API-biztonsági hibák, amelyek tényleg előjönnek

A jogosultságkezelésen túl néhány visszatérő probléma adja a leletek zömét. Az OWASP API Security Top 10 itt a szokásos hivatkozási alap, és az OWASP időről időre átdolgozza, ezért mindig az aktuális kiadást nézd, ne egy összefoglalót.

Több adat visszaadása, mint amennyit a felület mutat. Egy végpont a teljes felhasználói objektumot adja vissza, mert így volt kényelmes, a felület pedig három mezőt jelenít meg belőle. A másik tizenkettő, köztük a jelszó-visszaállító token és a belső kockázati pontszám, továbbra is ott van a válaszban. Aki megnyitja a hálózati fület, megkapja mindet. Szerializálj tudatosan: nevesített mezőkből építsd fel a választ, ahelyett hogy kiöntenél egy modellt.

Tömeges hozzárendelés a bemeneten. Ugyanennek a tükörképe. Egy profilfrissítő végpont elfogad minden beérkező mezőt, és ráírja a rekordra, így a hívó hozzátesz egy "role": "admin" mezőt, és előlépteti magát. Kösd a bemenetet kifejezetten egy engedélyezett mezőlistához, ne vedd át egészben a kérés törzsét.

Korlátozatlan erőforrás-fogyasztás. Korlátok nélkül egyetlen hívó kérhet oldalanként egymillió rekordot, futtathat drága kereséseket ciklusban, vagy indíthat ezerszámra jelszó-visszaállítást. Ez nem csupán rendelkezésre állási kérdés; ahol minden kérés pénzbe kerül neked, például ha egy nyelvi modell áll a végpontod mögött, ott ez a számlád elleni támadás. A kérésszabályozás fogyasztónként és végpontonként való, és a drága műveleteket szorosabban kell fogni, mint az olcsókat.

Leltár és a külső felek megbízhatósága

Dokumentálatlan és elfelejtett végpontok. A kettes verzió él és dokumentált, az egyes verzió még mindig fut a régi jogosultsági logikával, és egy éles adatokat tartalmazó teszt-API elérhető az internetről. A támadók pontosan ezt keresik. Vezess leltárt minden üzembe helyezett API-ról, minden verzióról és minden környezetről, és tudatosan vonj ki dolgokat a forgalomból, ne elhanyagolással.

A meghívott rendszerek megbízása. A te API-d más API-kat hív, és azok válaszai a te adatbázisodba és a te megjelenítésedbe kerülnek. Ellenőrizd, ami visszajön, ahelyett hogy biztonságosnak feltételeznél egy partnert. A kívülről érkező válasz is bemenet, minden ebből következő ellenőrzési kötelezettséggel együtt. A külső API-k integrálásáról szóló útmutatónk ugyanennek a kapcsolatnak a megbízhatósági oldalát járja körül.

A hitelesítés helyes felépítése

A hitelesítést a legtöbb csapat nagyjából eltalálja, ezért itt azokról a részletekről van szó, amelyek végül mégis tönkreteszik.

Használj rövid élettartamú hozzáférési tokent frissítéssel, ne hosszú életű kulcsokat, amelyek soha nem járnak le. Egy kiszivárgott, örökké érvényes hitelesítő adat tartós kompromittálódás; egy tizenöt perc múlva lejáró pedig olyan incidens, amelynek van vége.

Szűkítsd a tokenek hatókörét. Egy riportáló integrációnak kiadott token ne tudjon felhasználót létrehozni. A hatókörökkel ezt központilag érvényesítheted, ahelyett hogy minden egyes kezelő figyelmére hagyatkoznál.

Ellenőrizd rendesen a tokeneket, ami mindenekelőtt azt jelenti, hogy ne fogadd el azt az algoritmust, amelyet maga a token állít magáról. Rögzítsd az elvárt aláíró algoritmust, ellenőrizd a kibocsátót és a címzettet, és nézd meg a lejáratot. Vannak könyvtárak, amelyek ezt alapból megteszik; a házilag írt ellenőrzés az, ahol a hibák laknak.

Forgasd a hitelesítő adatokat ütemezetten, és adj a fogyasztóidnak módot arra, hogy leállás nélkül váltsanak, jellemzően úgy, hogy az átállás alatt két kulcs is érvényes. Ha a csere kiesést okoz, senki nem fogja elvégezni.

Végül: hitelesítő adat soha ne kerüljön URL-be. A lekérdezési paraméterek a szerver naplóiba, a böngészőelőzményekbe, a proxy naplóiba és a hivatkozó fejlécekbe is bekerülnek. Használj fejlécet.

Mit talál valójában egy behatolásteszt

Az automatikus vizsgálat és a kézi tesztelés más dolgokat talál meg, és mindkettőre szükséged van, más-más okból.

A szkennerek jók az ismert sebezhető függőségekben, a hiányzó biztonsági fejlécekben, a rosszul beállított TLS-ben és a kézenfekvő injektálásokban. Futtasd őket folyamatosan a build folyamatodban, mert olcsók, és elkapják a visszaeséseket. A szerverbiztonsági audit ellenőrzőlistánk megmutatja, mit néznek meg ilyenkor az infrastruktúra oldalán.

Amire viszont nem képesek, az az üzleti gondolkodás. Egy tesztelő rájön, hogy a kedvezménykódos végpont többször is hívható, és így a kedvezmények egymásra rakhatók, hogy egy fizetős funkció ingyenes csomagból is elérhető, ha közvetlenül az API-t hívjuk, vagy hogy egy már feladott rendelés lemondása készletellenőrzés nélkül indít visszatérítést. Ezek azok a leletek, amelyek valódi pénzbe kerülnek, és csak akkor kerülnek elő, ha valaki érti, mire való az API-d.

Egy API esetében külön kérd, hogy a teszt terjedjen ki a szerepkörök közötti jogosultsági vizsgálatra: a tesztelő két különböző ügyfél hitelesítő adatait tartja a kezében, és módszeresen próbálja elérni az egyik fiók adatait a másik tokenjével. Ez az egyetlen gyakorlat többet talál, mint az összes többi együttvéve. A behatolástesztek típusairól szóló áttekintésünk elmagyarázza, mekkora hozzáférést érdemes adni a tesztelőnek, és a dokumentáció meg a hozzáférés átadása sokkal jobb eredményt hoz, mint a vakteszt.

Ami a keretet illeti, az API-ra fókuszáló tesztelés jellemzően nagyjából £3,000-től indul egy kicsi, jól dokumentált API esetében, és £15,000-ig vagy annál magasabbra megy egy nagy, több szerepkört és integrációt tartalmazó felületnél. A behatolásteszt költségeiről szóló útmutatónk lebontja, mi mozgatja ezt a sávot.

Naplózz annyit, hogy nyomozni is lehessen

Egy incidens és egy katasztrófa között többnyire az a különbség, hogy vissza tudod-e állítani, mi történt.

Naplózd a hitelesítési eseményeket, a jogosultsági elutasításokat és minden állapotváltoztató műveletet, mindegyiket a hívó azonosságával, a célobjektummal és egy összerendelő azonosítóval együtt. A jogosultsági elutasítások különösen jó korai jelzések: egy jogszerű integráció szinte egyet sem termel, tehát ha hirtelen özönlenek, akkor valaki tapogatózik.

Magukat az érzékeny értékeket ne naplózd. A naplófájlba került token, kártyaadat vagy személyes adat egy körülhatárolt biztonsági eseményből bejelentendő incidenst csinál.

Riassz a mintázatokra, ne a mennyiségre. Egyetlen hívó, aki sok különböző objektumazonosítón termel jogosultsági hibát, éppen felderítést végez, és ezért érdemes valakit felébreszteni. Az összesített hibaarány nem ilyen jelzés.

Őrizd meg a naplókat elég sokáig ahhoz, hogy hasznosak legyenek. A kompromittálódásokra gyakran hetekkel a kezdet után derül fény, és harminc napnyi napló sokszor kevés a belépési pont megtalálásához.

Azt az API-t teszteld, amelyet valóban kiadtál

A Mecanik alkalmazásbiztonsági tesztelést végez, kifejezetten azokra a jogosultsági és üzleti logikai hibákra fókuszálva, amelyeket az automata eszközök nem látnak meg, beleértve a fiókok közötti tesztelést valódi hitelesítő adatokkal, több szerepkörön át.

A specifikációdból és a dokumentációdból dolgozunk, nem találgatjuk a felületet, és ennek mellékhatásaként kerülnek elő a dokumentálatlan végpontok meg az elcsúszott régi verziók. Ahol a munka az infrastruktúrára és a hálózatra is kiterjed, ott a behatolásteszt-szolgáltatásaink fedik le a terepet. Ha pedig az API-d egy webalkalmazás mögött áll, a webhelybiztonsági auditról szóló útmutatónk megmutatja, hogyan kapcsolódik össze a két vizsgálat. Ha pedig még csak tervezed az API-t, az egyedi API-fejlesztés költségeiről szóló útmutatónk leírja, hol a helye az engedélyezésnek, a kérésszám-korlátozásnak és a naplózásnak már az építés közben, ahelyett hogy utólag kerülnének be.

Küldd el a specifikációt és a szerepkörök leírását, és megmondjuk, hol sűrűsödik a kockázat.

Kapcsolódó bejegyzések: WordPress feltörve: kártevő eltávolítása és mentés , GDPR műszaki megfelelés brit fejlesztőknek 2026-ban , Cloudflare Zero Trust: útmutató a vállalati hozzáférés-biztonsághoz , Behatolastesztes UK - Mire szamithat 2026-ban .

Gyakran ismételt kérdések

Mi a leggyakoribb API-biztonsági sebezhetőség? Az objektumszintű jogosultsági hiba, amikor egy hitelesített hívó egy azonosító átírásával eléri más felhasználó adatait. A hitelesítés helyesen működik, de semmi nem ellenőrzi, hogy a kért objektum a hívóhoz tartozik-e. A tulajdonviszonyt ezért magában a lekérdezésben kell érvényesíteni.

Elég védelmet ad-e önmagában az API-kulcs? Önmagában nem. A soha le nem járó, hosszú életű kulcsok bármely szivárgást tartós kompromittálódássá tesznek. Használj rövid élettartamú hozzáférési tokent frissítéssel, szűkítsd a hatókörét arra, amire a fogyasztónak tényleg szüksége van, támogasd a leállás nélküli cserét, és mindig fejlécben küldd, ne URL-ben.

Meg tudja-e védeni egy API-t az automatikus vizsgálat? Nem, bár érdemes folyamatosan futtatni. A szkennerek megtalálják az ismert sebezhető függőségeket, a hiányzó fejléceket és a kézenfekvő injektálásokat. Az üzleti szabályaidról viszont nem tudnak gondolkodni, ezért kimarad az egymásra rakott kedvezmény, az ingyenes csomagból elérhető fizetős funkció és a fiókok közötti adathozzáférés.

Mennyibe kerül egy API behatolásteszt? Jellemzően nagyjából £3,000-től indul egy kicsi, jól dokumentált API esetében, és £15,000-ig vagy feljebb megy egy nagy, több szerepkört és integrációt tartalmazó felületnél. Az árat a végpontok száma, az elkülönülő szerepkörök száma, valamint az mozgatja, hogy kapunk-e dokumentációt és hozzáférést.

Mit naplózzon egy API biztonsági célból? A hitelesítési eseményeket, a jogosultsági elutasításokat és minden állapotváltoztató műveletet, mindegyiket a hívó azonosságával, a célobjektummal és egy összerendelő azonosítóval. Tokent és személyes adatot soha ne naplózz. Riassz, ha egyetlen hívó sok különböző azonosítón termel jogosultsági hibát, mert az felderítésre utal.