Partner API Authorization Testovi za AI API portale prodavača

Partner API za portale prodavača mora pretpostaviti da se svaki ID objekta u zahtjevu može kopirati, pogoditi, reproducirati, zabilježiti drugom integracijom ili proći kroz pogrešan alat za osoblje. Osnovni problem nije u tome jesu li korisnički ID-ovi neprozirni. Problem je dokazuje li svaka radnja da pozivatelj, partnerski račun, ciljni zakupac, objekt, vlasništvo i stanje odobrenja pripadaju zajedno.

Ovo je najvažnije u AI API portalu prodavača jer API obično izlaže objekte kontrolne razine visokog utjecaja: kupce na nižem nivou, virtualne API ključeve, novčanike, kreditne prilagodbe, izvoze korištenja, odredišta web-dojavnika, korisnike osoblja i hitna zamrzavanja. Jedna nedostajuća provjera autorizacije može omogućiti jednom korisniku da pročita upotrebu drugog korisnika, dopustiti tokenu osoblja da premješta kredite među zakupcima ili dopustiti da token za automatizaciju opozove ključ koji nikada ne bi trebao vidjeti.

Činjenica: OWASP API Security 2023 navodi razinu oštećenog objekta Authorization kao API1 i razinu svojstva oštećenog objekta Authorization kao API3. U praktičnom smislu, provjere na razini objekta odgovaraju "može li ovaj pozivatelj djelovati na ovom objektu?" dok provjere na razini svojstva odgovaraju "može li ovaj pozivatelj postaviti ili pročitati ovo polje?" Obje su prvorazredne brige za Partner API dizajn.

Definirajte Authorization ugovor prije pisanja testova

Authorization testovi su korisni samo ako testiraju protiv eksplicitnog ugovora o politici. Započnite s matricom koja opisuje koji akter može učiniti koju radnju na kojoj meti, pod kojim uvjetima. Nemojte se oslanjati na nazive krajnjih točaka ili uloge korisničkog sučelja kao pravila.

Korisna matrica ima ove stupce:

• Vrsta aktera: vlasnik partnera, administrator partnera, financijski operater, operater podrške, token automatizacije, korisnički administrator, korisnički korisnik samo za čitanje.
• Račun partnera: račun preprodavača ili agencije koji posjeduje odnos s klijentom na nižoj razini.
• Ciljni zakupac: korisnički račun nizvodno koji se stvara, naplaćuje, pregledava, obustavlja ili briše.
• Vrsta objekta: korisnik, virtualni ključ, novčanik, unos u glavnu knjigu, izvješće o upotrebi, krajnja točka web-dojavnika, korisnik osoblja, profil cijena, mapiranje pružatelja usluga.
• Akcija: kreiraj, čitaj, popis, ažuriraj, opozovi, nadoplati, povrat novca, izvoz, zamrzni, odmrzni.
• Monetarna vlast: mijenja li radnja stanje, kreditno ograničenje, maržu, status namire, stanje fakture ili ograničenja potrošnje.
• Stanje odobrenja: je li zahtjev unaprijed odobren, čeka li se odobrenje, dvostruko je odobren, istekao ili samo hitno.

Na primjer, operateru podrške može se dopustiti pregled metapodataka o maskiranom ključu korisnika i zamrzavanje ključa tijekom incidenta, ali ne i stvaranje kredita, promjena kataloga cijena, izvoz potpunih podataka o upotrebi ili odmrzavanje ključa bez odobrenja. Financijski operater može stvoriti kreditnu prilagodbu za kupca u vlasništvu istog partnera, ali samo unutar konfiguriranog iznosa i tek nakon što postoji zapis o odobrenju.

Preporuka: napišite matricu kao verzionirani artefakt, zatim neka svaki naziv testa autorizacije upućuje na red ili pravilo. Kada se pravilo promijeni, razlika bi trebala prikazivati i promjenu ugovora i probnu promjenu.

Upotrijebite reference objekta vezane za stanara

Neprozirni ID-ovi smanjuju rizik nabrajanja, ali ne dokazuju autorizaciju. ID virtualnog ključa, ID novčanika, ID unosa u glavnu knjigu, ID izvoza upotrebe ili token kursora mora se razriješiti unutar očekivane granice partnera i stanara.

Siguran uzorak traženja je:

resolve object where
  object.id = request.object_id
  and object.partner_id = actor.partner_id
  and object.customer_id = request.customer_id
  and actor has action_scope for object_type/action
  and object.state allows action

Opasan uzorak je:

object = find_by_id(request.object_id)
if actor.has_scope("keys:revoke"):
  revoke(object)

Druga verzija dopušta posjedovanje opsega, a ne ovlasti nad ciljem. Ne uspijeva kada valjani token za partnera A dostavi ID ključa od partnera B ili kada operater za korisnika A pošalje ID novčanika od korisnika B.

Vezivanje stanara trebalo bi pokrivati više od očitih objekata. Uključite tokene pokazivača za izvješća o korištenju, ID-ove izvoznih poslova, ID-ove krajnjih točaka web-dojavnika, ID-ove odobrenja, ključeve idempotencije i ID-ove podešavanja glavne knjige. Ti se objekti često čine "unutarnjima", upravo zbog toga postaju slabe točke.

Izradite minimalni testni uređaj za više stanara

Koristite namjerno malu opremu koja olakšava izražavanje pogrešnog pristupa. Cilj nije velika količina podataka. Cilj je jasno razdvajanje.

Partner P1
  Staff: p1_owner, p1_support, p1_finance
  Token: p1_full_token, p1_support_token, p1_finance_token
  Customer C1A
    Key K1A
    Wallet W1A
    Usage cursor U1A
    Ledger entry L1A
  Customer C1B
    Key K1B
    Wallet W1B
    Usage cursor U1B
    Ledger entry L1B

Partner P2
  Staff: p2_owner
  Token: p2_full_token
  Customer C2A
    Key K2A
    Wallet W2A
    Usage cursor U2A
    Ledger entry L2A

Ovaj uređaj vam omogućuje testiranje dvije klase kvarova. Prvo, pristup među klijentima istog partnera, gdje pozivatelj s P1 pokušava dodirnuti C1B dok djeluje na C1A. Drugo, pristup među partnerima, gdje token P1 pokušava dodirnuti objekte P2.

Preporuka: pokrenite istu postavku protiv javnog partnera API i pozadine portala prodavača. Ograničenja korisničkog sučelja ne štite izravne API klijente, pozadinske poslove, razvojne alate preglednika ili ugrožene integracijske tokene.

Testirajte razinu objekta Authorization na svakoj krajnjoj točki visokog utjecaja

Za svaku krajnju točku koja prihvaća ID objekta izradite najmanje jedan pozitivan test i nekoliko negativnih testova. Pozitivni testovi dokazuju da je uređaj valjan. Negativni testovi dokazuju da granica postoji.

Stvaranje i traženje korisnika

Stvaranje kupca obično izgleda bezopasno jer ciljni stanar još ne postoji. I dalje treba autorizaciju jer pozivatelj može pokušati kreirati kupce pod drugim partnerom, dodijeliti zabranjeni profil cijena ili postaviti interne metapodatke.

Test slučajevi:

• Vlasnik partnera može stvoriti klijenta pod istim partnerom.
• Token za automatizaciju s opsegom pružanja usluga korisniku može stvoriti korisnika pod istim partnerom.
• Token samo za podršku ne može stvoriti kupca.
• P1 token ne može stvoriti korisnika s partner_id=P2.
• Token na razini kupca ne može navesti istovjetne klijente.

Stvaranje, opoziv i rotacija ključa

Ključne radnje životnog ciklusa imaju velik utjecaj jer daju pristup vremenu izvođenja i mogu prekinuti radna opterećenja proizvodnje. Kontrolne razine pružatelja obično izlažu administrativne objekte kao što su projekti, radni prostori, računi usluga, članovi i API ključevi putem API-ja. Sloj pristupnika ili preprodavača trebao bi s istom pažnjom postupati sa svojim vlastitim virtualnim ključevima.

Test slučajevi:

• P1 automatizacija može stvoriti K1A samo za C1A kada njegov token uključuje opseg pisanja ključa.
• P1 podrška ne može stvoriti K1A ako je uloga podrške samo za čitanje za ključeve.
• P1 podrška može zamrznuti K1A samo ako je hitno zamrzavanje u opsegu.
• P1 podrška ne može opozvati K1B kada kontekst zahtjeva kaže C1A.
• P1 puni token ne može opozvati K2A.
• Administrator korisnika za C1A ne može rotirati, otkriti ili opozvati K1B.

Za timove koji implementiraju Partner API automatizaciju, važan test nije samo "ima li ovaj token mogućnost pisanja ključeva?" To je "ima li ovaj token ključ za pisanje za ovog partnera, ovog kupca, ovaj ključ, ovo stanje i ovu operaciju?"

Dopune kredita i promjene novčanika

Radnje kretanja novca zahtijevaju strože testove od običnih ažuriranja. Nadoplata kredita može biti sintaktički ispravna, ali i dalje biti neovlaštena jer novčanik pripada drugom zakupcu, iznos premašuje ovlaštenje, zapis odobrenja cilja drugog korisnika ili je ključ idempotencije prvi put korišten za drugu operaciju.

Testni slučajevi:

• P1 Finance može nadopuniti W1A unutar svog ograničenja iznosa nakon odobrenja.
• P1 Finance ne može nadopuniti W1B korištenjem odobrenja stvorenog za W1A.
• P1 Finance ne može nadopuniti W2A.
• P1 podrška ne može nadopuniti nijedan novčanik.
• Token za automatizaciju ne može promijeniti kreditno ograničenje osim ako nema izričit opseg kretanja novca.
• Ponovni ključ idempotencije ne može preusmjeriti prethodnu W1A dopunu na W1B.

Preporuka: tretirajte ključeve idempotencije kao opseg partner plus operacija plus ciljni stanar plus normalizirano tijelo zahtjeva. Ponovni pokušaj trebao bi biti siguran, ali ne bi trebao postati kanal kolizije među zakupcima.

Izvješća o korištenju i kursori izvoza

Izvješća o korištenju lako je nedovoljno zaštititi jer su samo za čitanje. U sustavima preprodavača podaci o korištenju mogu otkriti imena kupaca, radna opterećenja, izbore modela, troškove, identifikatore krajnjih korisnika i komercijalne marže. Cursor tokeni i izvozni ID-ovi također moraju biti vezani za zakupca.

Test slučajevi:

• C1A administrator može čitati segmente upotrebe C1A.
• C1A administrator ne može čitati korištenje C1B promjenom customer_id.
• P1 analitički token samo za čitanje može izvesti upotrebu za P1 korisnike samo ako je prisutan opseg izvoza.
• P1 token ne može nastaviti izvoz P2 upotrebe s kopiranim kursorom.
• Pokazivač kreiran za izvješće na razini ključa ne može se ponovno upotrijebiti za dohvaćanje korištenja cijelog stanara osim ako nije izričito dopušteno.

Ako portal izlaže AI API mjerenje upotrebe korisnika, testirajte i prikaze sažetka i izvoze koji se mogu preuzeti. Putovi izvoza često zaobilaze isti kontroler ili kôd pravila koji koriste interaktivne stranice.

Test Property-Level Authorization on PATCH and Update Endpoints

Broken Object Property Level Authorization pojavljuje se kada je pozivatelju dopušteno ažuriranje objekta, ali također može postaviti polja koja bi trebala biti interna, privilegirana ili u vlasništvu drugog tijeka rada.

Za API-je partnera osjetljiva polja često uključuju:

• partner_id, customer_id i polja nadređenog vlasništva.
• provider_project_id, provider_workspace_id i upstream ključne reference.
• pricing_catalog_version, margin_tier i nadjačavanja popusta.
• wallet_balance, credit_limit, settlement_status i stanje fakture.
• fraud_status, risk_score i oznake usklađenosti.
• role, scopes i oznake za zaobilaženje odobrenja.

Koristite popise dopuštenih, a ne popise zabrane. Na primjer, krajnja točka ažuriranja korisničkog profila može dopustiti display_name, billing_email i metadata.external_reference. Trebao bi odbiti ili ignorirati margin_tier, credit_limit i provider_project_id, čak i ako pozivatelj može ažurirati objekt korisnika.

PATCH /partner/customers/C1A
{
  "display_name": "Acme Support Team",
  "margin_tier": "internal_zero_margin",
  "provider_project_id": "provider-project-owned-by-C1B"
}

Očekivani rezultat trebao bi biti deterministički. Preferiraj pogrešku provjere valjanosti koja identificira nedopuštena polja bez otkrivanja osjetljivih internih vrijednosti. Nemojte tiho prihvaćati povlaštena polja i zatim ih ignorirati osim ako vaš API ugovor već dosljedno koristi taj uzorak.

Učinite odbijanja nenabrajajućim

Negativni testovi trebali bi provjeriti statusne kodove i oblik odgovora. Ako P1 token zahtijeva K2A, odgovor ne bi trebao otkriti postoji li K2A pod drugim partnerom.

Uobičajeno pravilo je:

• Koristite 401 kada pozivatelj nije autentificiran.
• Koristite 403 kada je pozivatelj autentificiran, ali mu nedostaje opseg radnje u vlastitoj granici.
• Koristite 404 ili generički odgovor nije pronađeno kada je objekt izvan granica pozivatelja i postojanje ne bi trebalo biti otkriveno.

Točna konvencija može varirati, ali ponašanje mora biti dosljedno. Tijelo odbijanja treba izbjegavati poruke kao što su "ključ pripada drugom korisniku" ili "novčanik postoji pod partnerom P2." Te su informacije korisne napadačima i rijetko korisne legitimnim klijentima.

Kompromis: generička odbijanja otežavaju otklanjanje pogrešaka programerima partnera. Riješite to s ID-ovima zahtjeva, strukturiranim revizijskim zapisnicima i alatom za podršku, a ne curenjem informacija o postojanju više zakupaca u javnim API pogreškama.

Zabilježite Authorization odluku, neosjetljive podatke

Authorization testovi bi također trebali potvrditi da odbijanja proizvode korisne interne dokaze. Trebate dovoljno detalja da rekonstruirate što se dogodilo tijekom incidenta bez pohranjivanja neobrađenih upita, tajni ili nepotrebnih podataka o korisnicima.

Polja dnevnika trebaju uključivati:

• request_id i ID korelacije praćenja.
• actor_id, vrsta glumca, ID tokena i predložak uloge.
• partner_id od autentificiranog aktera.
• Traženi ciljni stanar i riješeni ciljni stanar, kada je razrješenje dopušteno.
• Vrsta objekta i radnja.
• Verzija pravila i rezultat odluke.
• Šifra razloga odbijanja, kao što je missing_scope, tenant_mismatch, approval_required ili field_not_allowed.

Nemojte zapisivati potpune API ključeve, tajne uzlaznog davatelja usluga, upite, neobrađene korisne podatke o korištenju ili puni izvozni sadržaj. Za odbijene zahtjeve među zakupcima, pazite da interni zapisnici budu kontrolirani pristupom; javni odgovor može biti generički dok sigurnosni tim još uvijek ima dovoljno dokaza.

Automatizirajte svežanj u CI i staging

Testni svežanj trebao bi se izvoditi na tri mjesta: jedinični testovi za funkcije pravila, integracijski testovi za API krajnje točke i probne provjere protiv implementirane pozadine portala prodavača. Svaki sloj hvata različite kvarove.

Praktična CI struktura:

authz-tests/
  fixtures/
    partners.json
    customers.json
    roles.json
    tokens.json
  matrix/
    keys.yaml
    wallets.yaml
    usage_exports.yaml
    customers.yaml
  tests/
    test_keys_authz.ts
    test_wallet_authz.ts
    test_usage_authz.ts
    test_patch_allowlists.ts

Svaki redak matrice trebao bi definirati aktera, zahtjev, očekivanu odluku i očekivano ponašanje bez nabrajanja.

- name: p1_support_cannot_revoke_p2_key
  actor: p1_support_token
  method: POST
  path: /partner/customers/C2A/keys/K2A/revoke
  expected_status: 404
  expected_error_code: not_found
  expected_audit_reason: tenant_mismatch

Dodajte varijante stila mutacije koje mijenjaju jedan po jedan identifikator: ID korisnika, ID ključa, ID novčanika, ID odobrenja, kursor, ključ idempotencije i ID krajnje točke web-dojavnika. Ovi testovi su po dizajnu ponavljajući. Ponavljanje je prihvatljivo kada dokazuje da svaki identifikator ima neovisno područje djelovanja.

Operativni kontrolni popis

Prije slanja krajnje točke partnera API upotrijebite ovaj kontrolni popis:

• Krajnja točka ima imenovano pravilo autorizacije u matrici pravila.
• Svako pretraživanje objekta uključuje granične uvjete partnera i stanara.
• Svaka krajnja točka popisa filtrira se prema granici aktera prije označavanja stranica.
• Svaki kursor, ID izvoza, ID web-dojavnika, ID odobrenja i ključ idempotencije imaju opseg.
• PATCH krajnje točke koriste popise dopuštenih svojstava prema ulozi i radnji.
• Radnje prijenosa novca zahtijevaju izričit opseg i stanje odobrenja.
• Hitno zamrzavanje odvojeno je od odmrzavanja i kreditnog ovlaštenja.
• Odbijanja izbjegavaju curenje podataka o postojanju među zakupcima.
• Revizijski zapisnici bilježe odluku o autorizaciji i verziju pravila.
• Isti negativni testovi izvode se protiv API i pozadinskih staza portala.

Kompromisi za eksplicitnu odluku

Sitno zrnati dometi smanjuju radijus eksplozije, ali povećavaju složenost integracije partnera. Zadani predlošci uloga pomažu: vlasniku, financijama, podršci, analitici, automatizaciji pružanja i hitnom odgovoru. Dopustite naprednim partnerima da se prilagode prema tim predlošcima umjesto da počnu od neobrađenih opsega.

Strogi popisi dopuštenih svojstava usporavaju uvođenje značajke jer svako novo polje koje se može uređivati zahtijeva promjenu pravila. To trenje je korisno za naplatu, cijene, mapiranje pružatelja usluga i polja upravljanja ključevima. Za polja profila niskog rizika postupak može biti lakši.

Tokovi odobrenja smanjuju slučajne ili zlonamjerne promjene kredita, ali dodaju kašnjenje legitimnim operacijama podrške. Neka hitno zamrzavanje bude brzo, reverzibilno i odvojeno. Nemojte dopustiti da isti hitni token dodaje kredite, mijenja marže, izvozi upotrebu i odmrzava račune.

Predviđanje: portali preprodavača nastavit će izlagati više administrativnih radnji putem partnerskih API-ja jer korisnici očekuju pružanje samouslužnih usluga, izvješćivanje i automatizaciju. Sustavi koji dobro stare bit će oni s ugovorima o autorizaciji i negativnim testovima, a ne oni koji se oslanjaju samo na imenovanje rute, skrivene kontrole korisničkog sučelja ili neprozirne ID-ove.

Zaključak koji se može poduzeti

Izgradite snop autorizacije prije nego što partner API postane dovoljno velik da svaka krajnja točka ima vlastitu iznimku. Započnite s dva partnera, dva kupca pod jednim partnerom, jednim kupcem pod drugim partnerom i malim skupom tokena. Zatim testirajte radnje koje vam mogu najviše naškoditi: stvaranje ključa, opoziv ključa, dopune kredita, izvozi korištenja, ažuriranja novčanika, ponovno korištenje odobrenja, ponavljanje idempotencije i PATCH polja.

Ugovor je jednostavno navesti: pozivatelj mora imati pravi opseg, pod pravim partnerom, za pravog stanara, objekt, imovinu, radnju, iznos i stanje odobrenja. Rad na implementaciji to čini istinitim na svakoj krajnjoj točki, uključujući one dosadne.

Povezana literatura

• idempotentni partner API automatizacija za dodjelu ključeva i kredita