Zabezpečení API REST v PHP

Stručně: Pro bezpečnost API v PHP jsou rozhodující hlavně pět bodů: jen HTTPS, ověřování u každého neveřejného koncového bodu, kontrola oprávnění pro každý jednotlivý objekt, přísné limity pro metodu, typ obsahu a velikost požadavku a stručná chybová hlášení bez interních podrobností. K tomu přistupuje omezení četnosti požadavků a protokol bezpečnostně relevantních událostí. Proti zranitelnostem v samotném interpretu PHP jako PHP2Shell to nepomůže; k tomu je potřeba aktualizace PHP.

Rozhraní za webem

Mnoho firem zkontrolovalo v týdnu po 21. 10. 2026 své weby. Rozhraní za nimi bývala na seznamu méně často. Přitom právě tam probíhají citlivé procesy: aplikace zákaznického portálu stahuje faktury, systém řízení zboží zapisuje stavy zásob do e-shopu, partner hlásí zakázky přes webhook. Tato API se často stavěla rychle, pro jediný účel, a poté už se na ně nikdo nepodíval.

API nemá povrch, který by chyby zviditelnil. Chybějící kontrola oprávnění si v běžném provozu nikdo nevšimne, dokud všichni klienti dotazují jen to, co mají. Útočník naproti tomu zkouší přesně to, co není zamýšleno.

Prvním krokem je proto inventura. Jaké koncové body vůbec existují? Často se najdou staré verze jako /api/v1/, které se po přechodu na /v2/ nikdy nevypnuly, testovací koncové body z vývoje nebo veřejně dostupný popis rozhraní, který vypisuje interní funkce. Každý koncový bod, který se už nepotřebuje, by se měl vypnout. Každý, který zůstane, potřebuje odpovědnou osobu.

Bezpečnost API v PHP: základní pravidla

OWASP REST Security Cheat Sheet shrnuje osvědčená pravidla. Pro projekty v PHP je lze převést do krátkého seznamu:

1. Jen HTTPS. Tokeny a přístupové údaje se nikdy nesmějí přenášet nešifrovaně.
2. Každý koncový bod kontroluje sám. Ověření může probíhat centrálně, rozhodnutí o přístupu padá na koncovém bodě.
3. Oprávnění pro každý objekt. Nejen „je přihlášen“, ale „smí právě tento záznam“.
4. Stanovit povolené metody. Co není výslovně povoleno, se odmítne pomocí 405.
5. Kontrolovat typ obsahu a velikost. Chybný typ dá 415, příliš velké požadavky 413.
6. Validovat vstupy. Typ, délka, formát a rozsah hodnot, na straně serveru.
7. Žádná tajemství v URL. Tokeny a klíče patří do hlaviček, ne do query stringu.
8. Stručné chyby. Žádné stack trace, cesty ani hlášení SQL klientovi.
9. Omezení četnosti. Na příliš mnoho požadavků se odpovídá 429.
10. Odstínit administrační koncové body. Nedostupné veřejně nebo jen se silným přihlášením.

Oprávnění k objektu: nejčastější chyba

Příklad problém zhmotní. Koncový bod doručuje faktury pod /api/rechnungen/{id}. Kontroluje se, zda je přítomen platný token. Nekontroluje se, zda faktura patří zákazníkovi z tokenu. Kdo zvýší vlastní číslo faktury o jedna, uvidí fakturu souseda.

Řešení je jednoduché a přesto se musí uplatnit na každém místě: samotný dotaz se omezí na oprávněnou oblast.

<?php
// Povolit pouze metodu GET
if ($_SERVER['REQUEST_METHOD'] !== 'GET') {
    http_response_code(405);
    header('Allow: GET');
    exit;
}

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

// Oprávnění je součástí dotazu: jen vlastní faktury
$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);           // neprozradit, zda ID existuje
    exit;
}

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

Dotaz se zástupnými symboly chrání zároveň před SQL injection, viz Prevence SQL injection v PHP. Jak PHP poskytuje data požadavku jako metodu, hlavičky a tělo, vysvětluje stránka Superglobals: $_GET, $_POST, $_FILES a spol..

Správná kontrola tokenů

Mnoho API pracuje s JSON Web Tokens. OWASP Cheat Sheet k tomu uvádí jasná pravidla: tokeny musí být podepsané, nepodepsané tokeny se odmítají a algoritmus pro kontrolu se stanoví na serveru, nepřebírá se z tokenu. Ke kontrole patří také vydavatel, cílová skupina a doba vypršení. Používejte k tomu udržovanou knihovnu místo vlastních implementací.

Vlastní tokeny, například pro webhooky nebo jednorázové odkazy, musí pocházet z kryptograficky bezpečného generátoru náhody a porovnávat se v konstantním čase. Jak na to v PHP, ukazuje článek Bezpečná náhodná čísla a tokeny v PHP.

Stanovení hranic: velikost, typ a tempo

API by mělo přijímat jen to, co očekává. Začíná to u typu obsahu: koncový bod, který zpracovává JSON, odmítne vše ostatní. Maximální velikost požadavku omezte na několika úrovních, ve webserveru a v PHP přes post_max_size. Tento limit patří i k přechodným opatřením, která php.net k PHP2Shell uvedlo. Jak ho smysluplně zvolit, popisuje článek Rozumné omezení post_max_size a upload_max_filesize.

Omezení četnosti chrání před zkoušením identifikátorů a před přetížením. Lze ho zavést ve webserveru, v předřazené proxy nebo v aplikaci. Důležité je, aby limity platily pro každý klíč nebo uživatele, a ne jen pro každou adresu IP.

U API, která se volají přímo z prohlížeče, přistupuje CORS, tedy pravidla, které cizí weby smějí posílat požadavky. Tyto hlavičky nastavujte jen tehdy, když jsou takové požadavky skutečně zamýšleny, a povolené původy uvádějte jednotlivě, místo abyste povolili každý původ. Zástupný znak, který povoluje všechny weby, je u koncových bodů s přihlášením téměř vždy chyba.

Nakonec protokol: neúspěšná přihlášení, odmítnuté tokeny a odepřené přístupy patří do logu, samotné tokeny ne. Bez těchto záznamů zůstane útok na API neviditelný.

Jak konkrétně pomáhá PHP SOS?

• Zaznamenáme všechna rozhraní vašich systémů v PHP, i zapomenutá a interní, a zkontrolujeme, která jsou veřejně dostupná.
• Přečteme logiku oprávnění a cíleně otestujeme, zda lze načíst cizí záznamy.
• Nastavíme limity velikosti, typu a tempa ve webserveru a v PHP a odsouhlasíme je s vašimi klienty.
• Pro komplexní kontrolu zvenčí to kombinujeme s bezpečnostním auditem a penetračním testem.

Závěr: API je tak bezpečné jako její nejledabilejší koncový bod. Kdo kontroluje oprávnění pro každý objekt, stanoví jasné hranice a drží chyby stručné, uzavře nejčastější mezery dlouho předtím, než je někdo cíleně hledá.

Časté dotazy

Zdroje

• OWASP: REST Security Cheat Sheet
• OWASP Top 10
• Příručka PHP
• php.net: bezpečnostní oznámení