Īsi sakot: API drošībai PHP svarīgi ir galvenokārt pieci punkti: tikai HTTPS, autentifikācija katrā nepubliskā galapunktā, atļauju pārbaude katram atsevišķam objektam, stingras robežas pieprasījuma metodei, satura tipam un izmēram, kā arī īsi kļūdu ziņojumi bez iekšējām detaļām. Klāt nāk ātruma ierobežojums un drošībai nozīmīgu notikumu protokols. Pret ievainojamībām pašā PHP interpretatorā, piemēram, PHP2Shell, tas nepalīdz; tam vajadzīgs PHP atjauninājums.
Saskarne aiz vietnes
Daudzi uzņēmumi nedēļā pēc 2026. gada 21. oktobra pārbaudīja savas vietnes. Saskarnes aiz tām retāk bija sarakstā. Tomēr tieši tur notiek sensitīvi procesi: klientu portāla lietotne iegūst rēķinus, preču uzskaites sistēma ieraksta atlikumus veikalā, partneris ziņo par pasūtījumiem ar webhook. Šīs API bieži tika uzbūvētas ātri, vienam mērķim, un pēc tam nekad vairs neapskatītas.
API nav saskarnes, kas padarītu kļūdas redzamas. Trūkstoša atļauju pārbaude ikdienā nevienam nekrīt acīs, kamēr visi klienti vaicā tikai to, ko drīkst. Uzbrucējs turpretī izmēģina tieši to, kas nav paredzēts.
Pirmais solis tāpēc ir inventarizācija. Kādi galapunkti vispār pastāv? Bieži atrodas vecas versijas, piemēram, /api/v1/, kas pēc pārejas uz /v2/ nekad nav izslēgtas, testa galapunkti no izstrādes vai publiski atverams saskarnes apraksts, kas uzskaita iekšējās funkcijas. Katrs galapunkts, kas vairs nav vajadzīgs, jāizslēdz. Katram, kas paliek, vajadzīgs atbildīgais.
API drošība PHP: pamatnoteikumi
OWASP REST Security Cheat Sheet apkopo pierādītus noteikumus. PHP projektiem tos var pārvērst īsā sarakstā:
- Tikai HTTPS. Tokenus un piekļuves datus nekad nedrīkst pārraidīt nešifrētus.
- Katrs galapunkts pārbauda pats. Autentifikācija var notikt centralizēti, lēmums par piekļuvi tiek pieņemts galapunktā.
- Atļauja katram objektam. Nevis tikai „ir pieteicies", bet „drīkst tieši šo ierakstu".
- Noteikt atļautās metodes. Kas nav nepārprotami atļauts, tiek noraidīts ar 405.
- Pārbaudīt satura tipu un izmēru. Nepareizs tips dod 415, pārāk lieli pieprasījumi 413.
- Validēt ievadi. Tips, garums, formāts un vērtību diapazons, servera pusē.
- Nekādu noslēpumu URL. Tokeni un atslēgas pieder galvenei, nevis query string.
- Īsas kļūdas. Nekādu stack trace, ceļu vai SQL ziņojumu klientam.
- Ātruma ierobežojums. Uz pārāk daudziem pieprasījumiem atbild ar 429.
- Norobežot administrēšanas galapunktus. Nav publiski sasniedzami vai tikai ar spēcīgu pieteikšanos.
Objekta atļauja: biežākā kļūda
Piemērs padara problēmu taustāmu. Galapunkts atdod rēķinus zem /api/rechnungen/{id}. Tiek pārbaudīts, vai ir derīgs tokens. Netiek pārbaudīts, vai rēķins pieder tokena klientam. Kas savu rēķina numuru palielina par vienu, redz kaimiņa rēķinu.
Risinājums ir vienkāršs un tomēr jāīsteno katrā vietā: pats vaicājums ierobežo uz atļauto jomu.
<?php
// Atļaut tikai metodi GET
if ($_SERVER['REQUEST_METHOD'] !== 'GET') {
http_response_code(405);
header('Allow: GET');
exit;
}
$kundeId = $auth->kundeId(); // no pārbaudītā tokena
$id = filter_var($routeId, FILTER_VALIDATE_INT);
if ($id === false) {
http_response_code(400);
exit;
}
// Atļauja ir vaicājumā: tikai paša rēķini
$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); // neizpaust, vai ID pastāv
exit;
}
header('Content-Type: application/json');
echo json_encode($rechnung, JSON_THROW_ON_ERROR);
Vaicājums ar vietturiem vienlaikus pasargā no SQL injekcijas, skatiet SQL injekcijas novēršana PHP. Kā PHP nodrošina pieprasījuma datus, piemēram, metodi, galvenes un body, skaidro Superglobals: $_GET, $_POST, $_FILES un citi.
Tokenu pareiza pārbaude
Daudzas API strādā ar JSON Web Tokens. OWASP Cheat Sheet tam nosaka skaidrus noteikumus: tokeniem jābūt parakstītiem, neparakstīti tokeni tiek noraidīti, un pārbaudes algoritms tiek noteikts serverī, nevis pārņemts no tokena. Izdevējs, mērķauditorija un derīguma beigu laiks arī pieder pārbaudei. Šim nolūkam lietojiet uzturētu bibliotēku, nevis paša realizācijas.
Savi tokeni, piemēram, webhook vai vienreizējām saitēm, jāveido no kriptogrāfiski droša nejaušības ģeneratora un jāsalīdzina nemainīgā laikā. Kā tas notiek PHP, rāda Droši gadījuma skaitļi un tokeni PHP.
Katram klientam un katram partnerim dodiet savu atslēgu ar tieši tām tiesībām, kas tam vajadzīgas. Tad aizplūdušu atslēgu var bloķēt atsevišķi, nepārtraucot visus citus pieslēgumus.
Robežu noteikšana: izmērs, tips un temps
API jāpieņem tikai tas, ko tā gaida. Tas sākas ar satura tipu: galapunkts, kas apstrādā JSON, noraida visu pārējo. Pieprasījuma maksimālo izmēru ierobežojiet vairākos līmeņos, tīmekļa serverī un PHP ar post_max_size. Šī robeža pieder arī pie pagaidu pasākumiem, ko php.net nosaucis par PHP2Shell. Kā to saprātīgi izvēlēties, apraksta post_max_size un upload_max_filesize saprātīga ierobežošana.
Ātruma ierobežojums pasargā no identifikatoru izmēģināšanas un no pārslodzes. To var īstenot tīmekļa serverī, priekšā ieslēgtā starpniekserverī vai lietojumprogrammā. Svarīgi, lai robežas darbotos katrai atslēgai vai lietotājam, nevis tikai katrai IP adresei.
API, ko tieši izsauc no pārlūka, klāt nāk CORS, tas ir, noteikumi, kuras svešas vietnes drīkst veikt pieprasījumus. Iestatiet šīs galvenes tikai tad, ja šādi izsaukumi patiešām paredzēti, un atļautās izcelsmes nosauciet atsevišķi, nevis atļaujiet katru izcelsmi. Aizstājējzīme, kas atļauj visas vietnes, galapunktiem ar pieteikšanos gandrīz vienmēr ir kļūda.
Visbeidzot protokols: neveiksmīgas pieteikšanās, noraidīti tokeni un liegtas piekļuves pieder žurnālam, paši tokeni ne. Bez šiem ierakstiem uzbrukums API paliek neredzams.
Kā PHP SOS palīdz konkrēti?
- Mēs apkopojam visas jūsu PHP sistēmu saskarnes, arī aizmirstās un iekšējās, un pārbaudām, kuras ir publiski sasniedzamas.
- Mēs izlasām atļauju loģiku un mērķtiecīgi testējam, vai svešie ieraksti ir atverami.
- Mēs nosakām robežas izmēram, tipam un tempam tīmekļa serverī un PHP un saskaņojam tās ar jūsu klientiem.
- Plašai pārbaudei no ārpuses to apvienojam ar drošības auditu un penetrācijas testu.
Secinājums: API ir tik droša, cik tās nevērīgākais galapunkts. Kas pārbauda atļaujas katram objektam, nosaka skaidras robežas un kļūdas tur īsas, aizver biežākās nepilnības ilgi pirms kāds tās mērķtiecīgi meklē.
Biežāk uzdotie jautājumi
Vai ar API atslēgu pietiek kā aizsardzību?
Sensitīviem datiem nē. API atslēga parasti identificē lietojumprogrammu, nevis lietotāju, un to viegli nodot tālāk. OWASP REST Security Cheat Sheet iesaka API atslēgas neizmantot kā vienīgo aizsardzību sensitīviem resursiem.
Kas ir objekta atļauja un kāpēc tās tik bieži trūkst?
Ar to saprot pārbaudi, vai pieteiktais lietotājs drīkst redzēt vai mainīt tieši šo ierakstu. Tās bieži trūkst, jo izstrādātāji pārbauda tikai to, vai vispār kāds ir pieteicies. Tad pietiek URL nomainīt identifikatoru, lai atvērtu svešus datus.
Vai labi nodrošināta API pasargā no PHP2Shell?
Nē. PHP2Shell ir PHP interpretatorā un iedarbojas skartajos darbības režīmos, vēl pirms jūsu kods vispār darbojas. Pret to palīdz tikai PHP atjauninājums ar pārstartēšanu. Pieprasījumu izmēra robežas tomēr ir lietderīgas un pieder arī pie php.net pagaidu pasākumiem.
Kādus statusa kodus API vajadzētu atdot drošības kļūdu gadījumā?
Ierasti ir 401 bez derīgas pieteikšanās, 403 trūkstošai atļaujai, 405 neatļautai metodei, 413 pārāk lielam pieprasījumam, 415 nepareizam satura tipam un 429 pārāk daudziem pieprasījumiem. Pati atbilde tajā paliek īsa un bez iekšējām detaļām.