Naslov zvuči kao mamac, ali je nažalost točan: golema većina probijenih API-ja ne padne zbog genijalnog napada, nego zbog propusta toliko osnovnih da ih napadač otkrije za nekoliko minuta, često potpuno automatizirano. Ovaj tekst pokazuje kako ti propusti izgledaju i kako se od njih zaštititi — namijenjen developerima koji žele provjeriti vlastite API-je, ne onima koji bi dirali tuđe. Testirajte isključivo sustave koje posjedujete ili za koje imate izričito dopuštenje; neovlašten pristup tuđem sustavu je kazneno djelo, bez obzira na to koliko je "lako".

Zašto su API-ji omiljena meta

Web stranica barem ima korisničko sučelje koje sakriva svoju unutrašnjost. API je gola logika: predvidljive rute, strukturirani odgovori, jasni podaci. Napadaču ne treba probijati vizual — samo šalje zahtjeve i čita što se vrati. A automatizirani skeneri rade to nad tisućama API-ja istovremeno, tražeći poznate obrasce nemara.

Četiri klasične rupe (i kako ih zatvoriti)

1. Nema autorizacije na razini objekta (najčešća od svih)

Endpoint provjeri da ste prijavljeni, ali ne i da baš vi smijete vidjeti baš taj podatak. GET /api/racuni/1043 vraća vaš račun — pa napadač promijeni broj u 1044 i dobije tuđi. Ova rupa (u struci poznata kao IDOR / broken object level authorization) godinama je na vrhu liste najčešćih API propusta, i uzrok je nekih od najvećih curenja podataka.

Obrana: svaki dohvat objekta mora provjeriti pripada li objekt prijavljenom korisniku — na serveru, za svaki zahtjev, bez iznimke. Nasumični identifikatori (UUID) pomažu, ali nisu zamjena za provjeru vlasništva.

2. Tajne i preopširni odgovori

API koji na GET /api/korisnik/me vrati cijeli redak iz baze — uključujući hash lozinke, interne oznake i tuđe podatke ugniježđene "za svaki slučaj" — poklanja napadaču više nego što treba. Isto vrijedi za API ključeve u frontend kodu (o čemu smo pisali zasebno): ono što stigne u preglednik, javno je.

Obrana: vraćajte samo polja koja klijent stvarno treba (eksplicitna serializacija, ne "cijeli objekt"). Tajne žive na serveru, u environment varijablama.

3. Nema rate limitinga

Prijava bez ograničenja broja pokušaja poziva na probijanje lozinki grubom silom; endpoint za slanje SMS-a bez limita poziva na basnoslovan račun i zloupotrebu. Izostanak rate limitinga ne otvara vrata sam po sebi, ali svaku drugu slabost čini višestruko iskoristivijom.

Obrana: ograničite broj zahtjeva po korisniku/IP-u i endpointu, s pojačanim limitom na osjetljivim rutama (prijava, reset lozinke, slanje poruka). Gotova rješenja postoje za svaki framework.

4. Slijepo povjerenje ulazu

Podaci iz zahtjeva ubačeni izravno u upit baze (SQL injection) ili odgovor (XSS) klasika su stara desetljećima koja i dalje ruši API-je. "Ali podatke šalje moja aplikacija" nije obrana — napadač šalje zahtjeve izravno, zaobilazeći vaš frontend.

Obrana: parametrizirani upiti uvijek, validacija i tipizacija ulaza na ulazu (sheme poput Zod/JSON Schema), escapanje na izlazu. Nikad ne vjerujte da će podatak doći "kroz vaš UI".

Kako sami provjeriti vlastiti API (defenzivno)

  • Prođite vlastite endpointe s tuđim ID-em dok ste prijavljeni kao korisnik A: vidite li podatke korisnika B? Ako da — imate rupu #1.
  • Pogledajte što odgovori stvarno sadrže u alatima za razvoj preglednika: ima li polja koja klijent nikad ne koristi? Rupa #2.
  • Uključite automatsko skeniranje u CI (npr. OWASP ZAP, provjere ovisnosti) — uhvati poznate obrasce prije produkcije.
  • Vodite se OWASP API Security Top 10 kao popisom za obilazak — to je konsenzus struke o tome gdje se najčešće gubi.

Zaključak

"Lako je hakirati loše zaštićen API" istina je koja radi u oba smjera: isto što ga čini lakom metom čini ga i lakim za zaštititi. Nijedna od četiri rupe ne traži kriptografa da se zatvori — traži disciplinu da se provjeri vlasništvo, ograniči izlaz, postavi rate limit i ne vjeruje ulazu. Poslijepodne provedeno u prolasku vlastitih endpointa s ovim popisom vjerojatno je najisplativiji sigurnosni posao koji ćete napraviti ovaj mjesec. Radite ga na svome — i naći ćete prije nego što nađe netko drugi.