# REST API-k védelme PHP-ban

> REST API-k védelme PHP-ban: hitelesítés, objektumonkénti ellenőrzés, JWT, méret- és típushatárok, hibaüzenetek és sebességkorlátozás példakóddal.

Forrás: https://phpsos.de/hu/blog/rest-api-php-absichern/  
Állapot: 2026. 10. 25.  
Szolgáltató: PHP SOS, PHP-vészhelyzeti segítség és szerverbiztonság. Azonnali segítség WhatsAppon: https://wa.me/491736494914?text=%C3%9Cdv%C3%B6zl%C3%B6m%2C%20PHP%20SOS%21%20Seg%C3%ADts%C3%A9gre%20van%20sz%C3%BCks%C3%A9g%C3%BCnk%20a%20PHP-szerver%C3%BCnkkel.%20C%C3%A9g%3A%20%E2%80%A6%20Weboldal%3A%20%E2%80%A6

**Röviden:** A PHP API-biztonságában főleg öt pont számít: csak HTTPS, hitelesítés minden nem nyilvános végponton, jogosultság-ellenőrzés minden egyes objektumra, szigorú határok a metódusra, a tartalomtípusra és a kérés méretére, valamint rövid hibaüzenetek belső részletek nélkül. Ehhez jön a sebességkorlátozás és a biztonság szempontjából releváns események naplója. A PHP-értelmező magában lévő réseivel szemben, mint a PHP2Shell, ez nem segít; ahhoz a PHP-frissítés kell.

## Az interfész a weboldal mögött

Sok vállalat a 2026. október 21. utáni héten ellenőrizte a weboldalait. A mögöttük lévő interfészek ritkábban kerültek a listára. Pedig éppen ott futnak érzékeny folyamatok: az ügyfélportál alkalmazása számlákat tölt le, a vállalatirányítási rendszer készleteket ír a webshopba, egy partner webhookkal jelent megrendeléseket. Ezeket az API-kat gyakran gyorsan építették, egyetlen célra, és utána soha többé nem nézték meg.

Az API-nak nincs felülete, amely láthatóvá tenné a hibákat. Egy hiányzó jogosultság-ellenőrzés a mindennapokban senkinek sem tűnik fel, amíg minden kliens csak azt kérdezi le, amit kell. A támadó ezzel szemben éppen azt próbálja ki, ami nincs előirányozva.

Az első lépés ezért a leltár. Egyáltalán milyen végpontok léteznek? Gyakran találni régi verziókat, mint a `/api/v1/`, amelyeket a `/v2/`-re való áttérés után soha nem kapcsoltak ki, a fejlesztésből származó tesztvégpontokat, vagy nyilvánosan lekérhető interfészleírást, amely belső funkciókat sorol fel. Minden végpontot, amelyre már nincs szükség, ki kell kapcsolni. Mindegyiknek, amely marad, felelősre van szüksége.

## API-biztonság PHP-ban: az alapszabályok

Az OWASP REST Security Cheat Sheet összefoglalja a bevált szabályokat. A PHP-projektekre ezek egy rövid listára fordíthatók:

1. **Csak HTTPS.** A tokeneket és hozzáférési adatokat soha nem szabad titkosítatlanul átvinni.
2. **Minden végpont maga ellenőriz.** A hitelesítés történhet központilag, a hozzáférésről a végponton döntenek.
3. **Jogosultság objektumonként.** Nem csak „be van jelentkezve”, hanem „pontosan ezt az adatrekordot láthatja”.
4. **Az engedélyezett metódusok rögzítése.** Ami nincs kifejezetten engedélyezve, azt 405-tel elutasítják.
5. **A tartalomtípus és a méret ellenőrzése.** Hibás típus 415-öt ad, túl nagy kérés 413-at.
6. **A bemenetek validálása.** Típus, hossz, formátum és értéktartomány, a szerver oldalán.
7. **Nincsenek titkok az URL-ekben.** A tokenek és kulcsok a fejlécbe valók, nem a lekérdezési stringbe.
8. **Rövid hibák.** Nincs stacktrace, útvonal vagy SQL-üzenet a kliensnek.
9. **Sebességkorlátozás.** A túl sok kérésre 429-cel válaszolnak.
10. **Az adminisztrációs végpontok elzárása.** Nyilvánosan nem elérhetők, vagy csak erős bejelentkezéssel.

## Objektumjogosultság: a leggyakoribb hiba

Egy példa kézzelfoghatóvá teszi a problémát. Egy végpont számlákat szolgáltat a `/api/rechnungen/{id}` alatt. Azt ellenőrzik, hogy érvényes token van-e. Azt nem ellenőrzik, hogy a számla a token ügyfeléhez tartozik-e. Aki a saját számlaszámát eggyel megnöveli, a szomszédét látja.

A megoldás egyszerű, és mégis minden helyen meg kell valósítani: maga a lekérdezés korlátoz a jogosult területre.

```php
<?php
// Csak a GET metódust engedélyezni
if ($_SERVER['REQUEST_METHOD'] !== 'GET') {
    http_response_code(405);
    header('Allow: GET');
    exit;
}

$kundeId = $auth->kundeId();          // az ellenőrzött tokenből
$id = filter_var($routeId, FILTER_VALIDATE_INT);
if ($id === false) {
    http_response_code(400);
    exit;
}

// A jogosultság a lekérdezésben van: csak a saját számlák
$stmt = $pdo->prepare('SELECT nummer, betrag, datum FROM rechnungen WHERE id = ? AND kunde_id = ?');
$stmt->execute([$id, $kundeId]);
$rechnung = $stmt->fetch(PDO::FETCH_ASSOC);

if (!$rechnung) {
    http_response_code(404);           // nem elárulni, hogy létezik-e az azonosító
    exit;
}

header('Content-Type: application/json');
echo json_encode($rechnung, JSON_THROW_ON_ERROR);
```

A helyőrzőkkel végzett lekérdezés egyúttal véd az SQL-injection ellen is, lásd [SQL-injection megelőzése PHP-ban](https://phpsos.de/hu/ratgeber/sql-injection-php/). Hogy a PHP hogyan teszi elérhetővé a kérésadatokat, például a metódust, a fejléceket és a törzset, azt a [Szuperglobálisok: $_GET, $_POST, $_FILES és társaik](https://phpsos.de/hu/php/superglobals/) magyarázza el.

## A tokenek helyes ellenőrzése

Sok API JSON Web Tokenekkel dolgozik. Az OWASP Cheat Sheet erre egyértelmű szabályokat nevez meg: a tokeneknek aláírtnak kell lenniük, az aláíratlan tokeneket elutasítják, és az ellenőrzés algoritmusát a szerveren határozzák meg, nem a tokenből veszik át. A kiállító, a célközönség és a lejárati idő szintén az ellenőrzéshez tartozik. Ehhez gondozott könyvtárat használjon saját megvalósítások helyett.

A saját tokeneknek, például a webhookokhoz vagy az egyszeri linkekhez, kriptográfiailag biztonságos véletlenszám-generátorból kell származniuk, és állandó időben kell összehasonlítani őket. Hogy ez PHP-ban hogyan megy, azt a [Biztonságos véletlenszámok és tokenek PHP-ban](https://phpsos.de/hu/blog/sichere-tokens-php/) mutatja.

> **Tipp:**
> Minden kliensnek és minden partnernek adjon saját kulcsot pontosan azokkal a jogokkal, amelyekre szüksége van. Így egy kiszivárgott kulcs egyedileg letiltható anélkül, hogy az összes többi csatlakozást megszakítaná.

## Határok megszabása: méret, típus és tempó

Egy API csak azt fogadja el, amit vár. Ez a tartalomtípussal kezdődik: egy JSON-t feldolgozó végpont minden mást elutasít. A kérés maximális méretét több szinten korlátozza, a webszerverben és a PHP-ban a `post_max_size` segítségével. Ez a határ a php.net által a PHP2Shellről megnevezett átmeneti intézkedések közé is tartozik. Hogyan választhatja meg értelmesen, azt a [A post_max_size és az upload_max_filesize értelmes korlátozása](https://phpsos.de/hu/blog/post-max-size-upload-limits/) írja le.

A sebességkorlátozás védi az azonosítók végigpróbálgatása és a túlterhelés ellen. Megvalósítható a webszerverben, egy előtét-proxyban vagy az alkalmazásban. Fontos, hogy a határok kulcsonként vagy felhasználónként érvényesek legyenek, és ne csak IP-címenként.

A közvetlenül a böngészőből hívott API-knál a CORS is hozzájön, vagyis az a szabályrendszer, hogy mely idegen weboldalak intézhetnek kéréseket. Csak akkor állítsa be ezeket a fejléceket, ha ilyen hívások valóban elő vannak irányozva, és az engedélyezett eredeteket egyenként nevezze meg ahelyett, hogy minden eredetet megengedne. Egy olyan helyettesítő karakter, amely minden weboldalt engedélyez, a bejelentkezéssel rendelkező végpontoknál szinte mindig hiba.

Végül a napló: a sikertelen bejelentkezések, az elutasított tokenek és a megtagadott hozzáférések a logba tartoznak, maguk a tokenek nem. Ezek a bejegyzések nélkül egy API elleni támadás láthatatlan marad.

## Hogyan segít konkrétan a PHP SOS?

- Felmérjük a PHP-rendszerei összes interfészét, az elfelejtetteket és a belsőket is, és ellenőrizzük, melyek érhetők el nyilvánosan.
- Elolvassuk a jogosultsági logikát, és célzottan teszteljük, hogy idegen adatrekordok lekérhetők-e.
- A méret, a típus és a tempó határait a webszerverben és a PHP-ban állítjuk be, és egyeztetjük a klienseivel.
- A kívülről végzett átfogó ellenőrzéshez ezt a [biztonsági audittal és penetrációs teszttel](https://phpsos.de/hu/leistungen/sicherheitsaudit-penetrationstest/) kombináljuk.

**Összegzés:** Egy API annyira biztonságos, mint a legelhanyagoltabb végpontja. Aki objektumonként ellenőrzi a jogosultságokat, egyértelmű határokat szab, és rövidre fogja a hibákat, lezárja a leggyakoribb réseket, jóval azelőtt, hogy valaki célzottan keresné őket.


## Gyakori kérdések

**Elég az API-kulcs védelemként?**  
Érzékeny adatokhoz nem. Az API-kulcs többnyire egy alkalmazást azonosít, nem egy felhasználót, és könnyen továbbadják. Az OWASP REST Security Cheat Sheet azt tanácsolja, hogy az API-kulcsot ne használják az érzékeny erőforrások egyedüli védelmeként.

**Mi az objektumjogosultság, és miért hiányzik olyan gyakran?**  
Azt az ellenőrzést jelenti, hogy a bejelentkezett felhasználó pontosan ezt az adatrekordot láthatja vagy módosíthatja-e. Gyakran azért hiányzik, mert a fejlesztők csak azt ellenőrzik, hogy egyáltalán be van-e jelentkezve valaki. Ekkor elég egy azonosítót megváltoztatni az URL-ben ahhoz, hogy idegen adatokat hívjanak le.

**Véd a PHP2Shell ellen egy jól védett API?**  
Nem. A PHP2Shell a PHP-értelmezőben van, és az érintett üzemmódokban azelőtt hat, hogy az Ön kódja egyáltalán futna. Ez ellen csak a PHP-frissítés segít újraindítással. A kérések méretkorlátai ettől még értelmesek, és a php.net átmeneti intézkedései közé is tartoznak.

**Milyen állapotkódokat adjon egy API biztonsági hibáknál?**  
Szokásos a 401 érvényes bejelentkezés nélkül, a 403 hiányzó jogosultságnál, a 405 nem engedélyezett metódusnál, a 413 túl nagy kérésnél, a 415 hibás tartalomtípusnál és a 429 túl sok kérésnél. A válasz maga közben rövid marad, belső részletek nélkül.

## Források

- [OWASP: REST Security Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/REST_Security_Cheat_Sheet.html)
- [OWASP Top 10](https://owasp.org/www-project-top-ten/)
- [PHP kézikönyv](https://www.php.net/manual/de/)
- [php.net: biztonsági közlemények](https://www.php.net/)