Miks on API-d eriti haavatavad?
Programmiliidesed ühendavad omavahel sise- ja välissüsteeme, käitlevad tundlikke andmeid ning toimivad automatiseeritult — ilma inimese poolse valideerimiseta iga kutse puhul. Traditsioonilised võrguperimeetri kaitsemeetmed ei piisa, kui iga autoriseeritud klient suudab teha tuhandeid päringuid minutis. OWASP API Security Top 10 dokumenteerib korduvaid haavatavusklasse, millest paljud tulenevad mitte koodiprobleemidest, vaid ebapiisavast turvaprojekteerimisest arhitektuuritasemel.
Autentimine ja autoriseerimine — alustala
OAuth2 Authorization Code + PKCE voog on kuldstandard klientrakenduste kaudu ligipääsetavate API-de jaoks. Server-server suhtluse jaoks sobib Client Credentials voog lühiajaliste pääsutokenitega. Olulised vead, mis tuleb kõrvaldada juba projekteerimisetapis: tokenite salvestamine localStorage’s mälus hoidmise asemel, pääsuulatuse valideerimise puudumine iga kutse puhul, JWT tokeni audience välja kontrollimata jätmine ning staatiliste API-võtmete kasutamine ilma rotatsioonimehhanismita.
- Pääsutokenid: maksimaalne eluiga 15–60 minutit
- Värskendamistokenid: salvestatud turvalistes httpOnly küpsistes või turvalises serveripoolses hoidlas
- API-võtmete rotatsioon: kohustuslik, automatiseeritud, ilma seisakuta
- Iga kutse pääsuulatuse kontroll — mitte ainult sisselogimisel
Päringulimiidid kui kaitse kuritarvitamise vastu
Kutsete arvu piiramine ajaühikus kaitseb API-d mitme ohukategooria eest korraga: jõurünnakud autentimisandmetele, andmete kraapimine, äriloogikale suunatud DDoS-rünnakud ning vigaste klientide juhuslik ülekoormamine. Tõhus päringulimiitide juurutamine nõuab granulatsiooni — erinevad limiidid autoriseerimata päringutele, autenditud kasutajatele ja kõrgendatud usaldusega partneritele. Limiite tuleks rakendada IP-aadressi, kasutaja identifikaatori ja API-võtme tasandil korraga.
Tähelepanu väärib nõuetekohane veakodeerimine — kood 429 Too Many Requests peaks sisaldama päist Retry-After, mis võimaldab klientidel korrektselt käituda ja vähendab korduskatseid. Ülemäära ranged limiidid tekitavad kasutajate frustratsiooni ja raskendavad probleemide diagnostikat.
WAF ja API liikluse kontroll
Uue põlvkonna veebirakenduste tulemüür mõistab API struktuuri — kontrollib JSON-i korrektsust, tuvastab väljaväärtuste süstimiskatseid, blokeerib teadaolevaid ekspluateerimismustreid ning jälgib koormusmahtude ja kutsesageduse anomaaliaid. WAF-i konfigureerimine API jaoks nõuab teistsugust lähenemist kui traditsiooniliste veebirakenduste puhul — reeglid peavad arvestama iga lõpp-punkti spetsiifikat, lubatud andmetüüpe ja -mahte ning oodatavaid kasutusmustreid.
Monitooring ja anomaaliate tuvastamine
Ka kõige paremini konfigureeritud API vajab pidevat monitooringut. Anomaaliate tuvastamise süsteemid õpivad tundma tavalisi kasutusmustreid — kellaaegu, tüüpilisi kutsete järjestusi, IP-aadresside jaotust — ning annavad häire kõrvalekallete puhul. Eriti väärtuslik on vigadega 401 ja 403 lõppenud kutsete jälgimine (autoriseerimata juurdepääsu katsed), ebatavaliste vastusemsahtude jälgimine (potentsiaalne andmeleke) ning ressursside loendamist viitavate kutsejärjestuste tuvastamine.
ESKOM.AI projekteerib API turvalisuse arhitektuuri sisseehitatud elemendina, mitte hiljem lisatud kihina. Iga automatiseerimissüsteemi poolt kasutatav API läbib enne tootmisesse jõudmist OWASP API Top 10 kohase haavatavuse hindamise.