# Zabezpečenie API REST v PHP

> Zabezpečenie API REST v PHP: autentifikácia, kontrola pre každý objekt, JWT, hranice veľkosti a typu, chybové hlásenia a obmedzenie rýchlosti s kódom.

Zdroj: https://phpsos.de/sk/blog/rest-api-php-absichern/  
Stav: 25.10.2026  
Poskytovateľ: PHP SOS, Núdzová pomoc pri PHP a bezpečnosť serverov. Okamžitá pomoc cez WhatsApp: https://wa.me/491736494914?text=Dobr%C3%BD%20de%C5%88%2C%20PHP%20SOS%2C%20potrebujeme%20pomoc%20s%20na%C5%A1%C3%ADm%20serverom%20s%20PHP.%20Spolo%C4%8Dnos%C5%A5%3A%20%E2%80%A6%20Web%3A%20%E2%80%A6

**Stručne:** Pre bezpečnosť API v PHP rozhoduje predovšetkým päť bodov: len HTTPS, autentifikácia na každom neverejnom koncovom bode, kontrola oprávnenia pre každý jednotlivý objekt, prísne hranice pre metódu, typ obsahu a veľkosť požiadavky a stručné chybové hlásenia bez interných detailov. K tomu pristupuje obmedzenie rýchlosti a protokol bezpečnostne relevantných udalostí. Proti zraniteľnostiam v samotnom interpreteri PHP ako PHP2Shell to nepomôže; na to treba aktualizáciu PHP.

## Rozhranie za webom

Mnohé firmy v týždni po 21. 10. 2026 kontrolovali svoje weby. Rozhrania za nimi boli na zozname zriedkavejšie. Pritom práve tam prebiehajú citlivé procesy: aplikácia zákazníckeho portálu preberá faktúry, skladový systém zapisuje stavy do obchodu, partner hlási zákazky cez webhook. Tieto API sa často stavali narýchlo, na jediný účel, a potom sa už nikdy nepozreli.

API nemá rozhranie, ktoré by chyby zviditeľnilo. Chýbajúca kontrola oprávnenia si v každodennej prevádzke nikto nevšimne, kým všetci klienti dotazujú len to, čo majú. Útočník naopak skúša práve to, čo nebolo zamýšľané.

Prvým krokom je preto inventúra. Aké koncové body vôbec existujú? Často sa nájdu staré verzie ako `/api/v1/`, ktoré sa po prechode na `/v2/` nikdy nevypli, testovacie koncové body z vývoja alebo verejne dostupný opis rozhrania, ktorý uvádza interné funkcie. Každý koncový bod, ktorý sa už nepotrebuje, by sa mal vypnúť. Každý, ktorý zostane, potrebuje zodpovednú osobu.

## Bezpečnosť API v PHP: základné pravidlá

OWASP REST Security Cheat Sheet zhŕňa osvedčené pravidlá. Pre projekty PHP sa dajú preložiť do krátkeho zoznamu:

1. **Len HTTPS.** Tokeny a prístupové údaje sa nikdy nesmú prenášať nešifrovane.
2. **Každý koncový bod kontroluje sám.** Autentifikácia sa môže robiť centrálne, rozhodnutie o prístupe padá na koncovom bode.
3. **Oprávnenie pre každý objekt.** Nielen „je prihlásený“, ale „smie práve tento záznam“.
4. **Určiť povolené metódy.** Čo nie je výslovne povolené, sa odmietne pomocou 405.
5. **Kontrolovať typ obsahu a veľkosť.** Nesprávny typ dá 415, príliš veľké požiadavky 413.
6. **Validovať vstupy.** Typ, dĺžka, formát a rozsah hodnôt, na strane servera.
7. **Žiadne tajomstvá v URL.** Tokeny a kľúče patria do hlavičiek, nie do query stringu.
8. **Stručné chyby.** Žiadne stack trace, cesty ani hlásenia SQL smerom ku klientovi.
9. **Obmedzenie rýchlosti.** Príliš mnoho požiadaviek sa zodpovie pomocou 429.
10. **Odtieniť správcovské koncové body.** Nie sú verejne dostupné alebo len so silným prihlásením.

## Oprávnenie na úrovni objektu: najčastejšia chyba

Príklad robí problém hmatateľným. Koncový bod doručuje faktúry na `/api/rechnungen/{id}`. Kontroluje sa, či existuje platný token. Nekontroluje sa, či faktúra patrí zákazníkovi tokenu. Kto zvýši vlastné číslo faktúry o jedna, uvidí faktúru suseda.

Riešenie je jednoduché a napriek tomu sa musí zaviesť na každom mieste: samotný dotaz obmedzí na oprávnenú oblasť.

```php
<?php
// Povoliť len metódu GET
if ($_SERVER['REQUEST_METHOD'] !== 'GET') {
    http_response_code(405);
    header('Allow: GET');
    exit;
}

$kundeId = $auth->kundeId();          // z overeného tokenu
$id = filter_var($routeId, FILTER_VALIDATE_INT);
if ($id === false) {
    http_response_code(400);
    exit;
}

// Oprávnenie je v dotaze: len vlastné faktúry
$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);           // neprezradiť, či ID existuje
    exit;
}

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

Dotaz so zástupnými znakmi chráni zároveň pred SQL injection, pozri [Ako zabrániť SQL injection v PHP](https://phpsos.de/sk/ratgeber/sql-injection-php/). Ako PHP sprístupňuje údaje požiadavky, ako metódu, hlavičky a telo, vysvetľuje [Superglobals: $_GET, $_POST, $_FILES a spol.](https://phpsos.de/sk/php/superglobals/).

## Správne overovať tokeny

Mnohé API pracujú s JSON Web Tokens. OWASP Cheat Sheet na to uvádza jasné pravidlá: tokeny musia byť podpísané, nepodpísané tokeny sa odmietajú a algoritmus na kontrolu sa určuje na serveri, nepreberá sa z tokenu. K kontrole patrí aj vydavateľ, cieľová skupina a čas platnosti. Použite na to udržiavanú knižnicu namiesto vlastných implementácií.

Vlastné tokeny, napríklad pre webhooky alebo jednorazové odkazy, musia pochádzať z kryptograficky bezpečného generátora náhodných čísel a porovnávať sa v konštantnom čase. Ako na to v PHP, ukazuje [Bezpečné náhodné čísla a tokeny v PHP](https://phpsos.de/sk/blog/sichere-tokens-php/).

> **Tip:**
> Dajte každému klientovi a každému partnerovi vlastný kľúč s presne tými právami, ktoré potrebuje. Uniknutý kľúč sa potom dá zablokovať jednotlivo bez prerušenia všetkých ostatných napojení.

## Stanoviť hranice: veľkosť, typ a tempo

API by malo prijímať len to, čo očakáva. Začína to pri type obsahu: koncový bod, ktorý spracúva JSON, odmieta všetko ostatné. Maximálnu veľkosť požiadavky obmedzte na viacerých úrovniach, vo webservery a v PHP cez `post_max_size`. Táto hranica patrí aj k prechodným opatreniam, ktoré php.net uviedlo k PHP2Shell. Ako ju zmysluplne zvoliť, opisuje [Zmysluplné obmedzenie post_max_size a upload_max_filesize](https://phpsos.de/sk/blog/post-max-size-upload-limits/).

Obmedzenie rýchlosti chráni pred skúšaním identifikátorov a pred preťažením. Dá sa zaviesť vo webservery, vo vyššie umiestnenom proxy alebo v aplikácii. Dôležité je, aby hranice platili pre každý kľúč alebo používateľa a nielen pre každú adresu IP.

Pre API, ktoré sa volajú priamo z prehliadača, pribúda CORS, teda pravidlá, ktoré cudzie weby smú posielať požiadavky. Tieto hlavičky nastavujte len vtedy, ak sú takéto volania skutočne zamýšľané, a povolené pôvody uvádzajte jednotlivo, namiesto povolenia každého pôvodu. Zástupný znak, ktorý povoľuje všetky weby, je pri koncových bodoch s prihlásením takmer vždy chyba.

Nakoniec protokol: neúspešné prihlásenia, odmietnuté tokeny a zamietnuté prístupy patria do logu, samotné tokeny nie. Bez týchto záznamov zostane útok na API neviditeľný.

## Ako konkrétne pomáha PHP SOS?

- Zachytíme všetky rozhrania vašich systémov PHP, aj zabudnuté a interné, a preveríme, ktoré sú verejne dostupné.
- Prečítame logiku oprávnení a cielene otestujeme, či sú cudzie záznamy dostupné.
- Hranice pre veľkosť, typ a tempo nastavíme vo webservery a PHP a odsúhlasíme ich s vašimi klientmi.
- Pre komplexnú kontrolu zvonka to skombinujeme s [bezpečnostným auditom a penetračným testom](https://phpsos.de/sk/leistungen/sicherheitsaudit-penetrationstest/).

**Záver:** API je také bezpečné ako jeho najnedbalejší koncový bod. Kto kontroluje oprávnenia pre každý objekt, stanovuje jasné hranice a drží chyby stručné, uzavrie najčastejšie medzery dávno predtým, než ich niekto cielene hľadá.


## Časté otázky

**Stačí kľúč API ako ochrana?**  
Pre citlivé údaje nie. Kľúč API zvyčajne identifikuje aplikáciu, nie používateľa, a ľahko sa zdieľa ďalej. OWASP REST Security Cheat Sheet radí nepoužívať kľúče API ako jedinú ochranu citlivých zdrojov.

**Čo je oprávnenie na úrovni objektu a prečo tak často chýba?**  
Ide o kontrolu, či smie prihlásený používateľ vidieť alebo meniť práve tento záznam. Často chýba, pretože vývojári kontrolujú len to, či je vôbec niekto prihlásený. Potom stačí zmeniť identifikátor v URL a získať cudzie údaje.

**Chráni dobre zabezpečené API pred PHP2Shell?**  
Nie. PHP2Shell sedí v interpreteri PHP a pôsobí pri dotknutých režimoch prevádzky skôr, než vôbec začne bežať váš kód. Proti tomu pomáha len aktualizácia PHP s reštartom. Limity veľkosti požiadaviek sú napriek tomu zmysluplné a patria aj k prechodným opatreniam od php.net.

**Aké stavové kódy by malo API vracať pri bezpečnostných chybách?**  
Obvyklé sú 401 bez platného prihlásenia, 403 pri chýbajúcom oprávnení, 405 pri nepovolenej metóde, 413 pri príliš veľkej požiadavke, 415 pri nesprávnom type obsahu a 429 pri príliš mnohých požiadavkách. Samotná odpoveď pritom zostáva stručná a bez interných detailov.

## Zdroje

- [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/)
- [Príručka PHP](https://www.php.net/manual/de/)
- [php.net: bezpečnostné hlásenia](https://www.php.net/)