Securizarea API-urilor REST în PHP

Pe scurt: Pentru securitatea API în PHP contează mai ales cinci puncte: doar HTTPS, autentificare la fiecare endpoint nepublic, verificarea autorizării pentru fiecare obiect în parte, limite stricte pentru metodă, tip de conținut și dimensiunea cererii, precum și mesaje de eroare scurte, fără detalii interne. La acestea se adaugă limitarea ratei și un jurnal al evenimentelor relevante pentru securitate. Împotriva vulnerabilităților din interpretorul PHP însuși, precum PHP2Shell, aceasta nu ajută; pentru asta este nevoie de actualizarea PHP.

Interfața din spatele site-ului

Multe companii și-au verificat site-urile în săptămâna de după 21.10.2026. Interfețele din spatele lor au figurat mai rar pe listă. Totuși tocmai acolo au loc procese sensibile: aplicația portalului de clienți preia facturi, sistemul de gestiune a mărfurilor scrie stocurile în magazin, un partener raportează comenzi prin webhook. Adesea, aceste API-uri au fost construite repede, pentru un singur scop, și apoi nu au mai fost privite niciodată.

Un API nu are o interfață care să facă erorile vizibile. O verificare de autorizare lipsă nu o observă nimeni în viața de zi cu zi, atâta timp cât toți clienții interoghează doar ce trebuie. Un atacator încearcă în schimb exact ce nu este prevăzut.

Primul pas este de aceea o inventariere. Ce endpoint-uri există, de fapt? Se găsesc adesea versiuni vechi precum /api/v1/, care nu au fost niciodată dezactivate după trecerea la /v2/, endpoint-uri de test din dezvoltare sau o descriere a interfeței accesibilă public, care enumeră funcții interne. Fiecare endpoint care nu mai este necesar ar trebui dezactivat. Fiecare care rămâne are nevoie de un responsabil.

Securitatea API în PHP: regulile de bază

OWASP REST Security Cheat Sheet rezumă reguli dovedite. Pentru proiectele PHP, ele pot fi traduse într-o listă scurtă:

1. Doar HTTPS. Token-urile și datele de acces nu au voie să fie transmise niciodată necriptate.
2. Fiecare endpoint verifică singur. Autentificarea poate avea loc central, decizia privind accesul se ia la endpoint.
3. Autorizare pe obiect. Nu doar „este autentificat”, ci „are voie exact la această înregistrare”.
4. Stabiliți metodele permise. Ce nu este permis explicit este respins cu 405.
5. Verificați tipul de conținut și dimensiunea. Tip greșit dă 415, cereri prea mari 413.
6. Validați intrările. Tip, lungime, format și interval de valori, pe server.
7. Fără secrete în URL-uri. Token-urile și cheile aparțin în antet, nu în query string.
8. Erori scurte. Fără stacktrace-uri, căi sau mesaje SQL către client.
9. Limitarea ratei. Prea multe cereri primesc răspuns cu 429.
10. Izolați endpoint-urile de administrare. Nu accesibile public sau doar cu autentificare puternică.

Autorizarea pe obiect: cea mai frecventă greșeală

Un exemplu face problema palpabilă. Un endpoint livrează facturi la /api/rechnungen/{id}. Se verifică dacă există un token valid. Nu se verifică dacă factura aparține clientului din token. Cine își mărește cu unu propriul număr de factură o vede pe cea a vecinului.

Soluția este simplă și trebuie totuși implementată la fiecare loc: interogarea însăși restrânge la domeniul autorizat.

<?php
// Permiteți doar metoda GET
if ($_SERVER['REQUEST_METHOD'] !== 'GET') {
    http_response_code(405);
    header('Allow: GET');
    exit;
}

$kundeId = $auth->kundeId();          // din tokenul verificat
$id = filter_var($routeId, FILTER_VALIDATE_INT);
if ($id === false) {
    http_response_code(400);
    exit;
}

// Autorizarea este în interogare: doar facturile proprii
$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);           // nu trădați dacă ID-ul există
    exit;
}

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

Interogarea cu substituenți protejează în același timp împotriva SQL injection, vedeți Prevenirea SQL injection în PHP. Cum pune PHP la dispoziție datele cererii, precum metoda, antetele și corpul, explică Superglobals: $_GET, $_POST, $_FILES și celelalte.

Verificarea corectă a token-urilor

Multe API-uri lucrează cu JSON Web Tokens. Cheat Sheet-ul OWASP indică pentru acestea reguli clare: token-urile trebuie să fie semnate, token-urile nesemnate sunt respinse, iar algoritmul pentru verificare este stabilit pe server, nu preluat din token. Emitentul, destinatarul și timpul de expirare fac, de asemenea, parte din verificare. Folosiți pentru aceasta o bibliotecă întreținută, în loc de implementări proprii.

Token-urile proprii, de exemplu pentru webhook-uri sau linkuri de unică folosință, trebuie să provină dintr-un generator aleatoriu sigur criptografic și să fie comparate în timp constant. Cum se face acest lucru în PHP arată Numere aleatorii și token-uri sigure în PHP.

Stabilirea limitelor: dimensiune, tip și ritm

Un API ar trebui să accepte doar ce așteaptă. Aceasta începe cu tipul de conținut: un endpoint care procesează JSON respinge orice altceva. Dimensiunea maximă a unei cereri o limitați pe mai multe niveluri, în serverul web și în PHP prin post_max_size. Această limită face parte și din măsurile provizorii pe care php.net le-a menționat pentru PHP2Shell. Cum se alege rezonabil descrie Limitarea rezonabilă a post_max_size și upload_max_filesize.

Limitarea ratei protejează împotriva încercării de identificatori și împotriva suprasolicitării. Poate fi implementată în serverul web, într-un proxy din față sau în aplicație. Important este ca limitele să se aplice pe cheie sau pe utilizator, nu doar pe adresă IP.

Pentru API-urile apelate direct din browser se adaugă CORS, adică regulile privind ce site-uri străine au voie să facă cereri. Setați aceste antete doar dacă asemenea apeluri sunt cu adevărat prevăzute și numiți originile permise individual, în loc să permiteți orice origine. Un substituent care permite toate site-urile este, la endpoint-uri cu autentificare, aproape întotdeauna o greșeală.

În sfârșit, jurnalul: autentificările eșuate, token-urile respinse și accesele refuzate aparțin în jurnal, token-urile însele nu. Fără aceste înregistrări, un atac asupra API rămâne invizibil.

Cum ajută PHP SOS concret?

• Inventariem toate interfețele sistemelor dumneavoastră PHP, inclusiv cele uitate și interne, și verificăm care sunt accesibile public.
• Citim logica de autorizare și testăm țintit dacă pot fi accesate înregistrări străine.
• Stabilim limite pentru dimensiune, tip și ritm în serverul web și în PHP și le convenim cu clienții dumneavoastră.
• Pentru o verificare cuprinzătoare din exterior, combinăm aceasta cu audit de securitate și test de penetrare.

Concluzie: Un API este atât de sigur cât este cel mai neglijent endpoint al său. Cine verifică autorizările pe obiect, stabilește limite clare și păstrează erorile scurte închide cele mai frecvente vulnerabilități, cu mult înainte ca cineva să le caute țintit.

Întrebări frecvente

Surse

• OWASP: REST Security Cheat Sheet
• OWASP Top 10
• Manualul PHP
• php.net: avertismente de securitate