Partner API Authorization Tester för AI API återförsäljarportaler

En partner API för återförsäljarportaler måste anta att varje objekt-ID i en förfrågan kan kopieras, gissas, spelas upp igen, loggas av en annan integration eller skickas genom fel personalverktyg. Kärnproblemet är inte om kund-ID:n är ogenomskinliga. Problemet är om varje åtgärd bevisar att anroparen, partnerkontot, målhyresgästen, objektet, fastigheten och godkännandetillståndet hör ihop.

Detta är viktigast i en AI API-återförsäljarportal eftersom API vanligtvis exponerar kraftfulla kontrollplansobjekt: nedströmskunder, virtuella API-nycklar, plånböcker, kreditjusteringar, användningsexporter, webhook-destinationer, personalanvändare och nödstopp. En enda saknad auktoriseringskontroll kan låta en kund läsa en annan kunds användning, låta en personaltoken flytta krediter mellan hyresgäster eller låta en automatiseringstoken återkalla en nyckel som den aldrig borde se.

Fakta: OWASP API Security 2023 listar Broken Object Level Authorization som API1 och Broken Object Property Level Authorization som API3. Rent praktiskt svarar kontroller på objektnivå "kan den här anroparen agera på det här objektet?" medan kontroller på fastighetsnivå svarar "kan den här uppringaren ställa in eller läsa det här fältet?" Båda är förstklassiga frågor för Partner API design.

Definiera Authorization-kontraktet innan du skriver test

Authorization tester är bara användbara om de testar mot ett explicit policyavtal. Börja med en matris som beskriver vilken aktör som kan göra vilken handling på vilket mål, under vilka förutsättningar. Lita inte på slutpunktsnamn eller UI-roller som policy.

En användbar matris har följande kolumner:

• Aktörstyp: partnerägare, partneradministratör, finansoperatör, supportoperatör, automatiseringstoken, kundadministratör, skrivskyddad kundanvändare.
• Partnerkonto: återförsäljar- eller byråkontot som äger nedströmskundrelationen.
• Målhyresgäst: nedströmskundkontot som skapas, faktureras, inspekteras, stängs av eller tas bort.
• Objekttyp: kund, virtuell nyckel, plånbok, reskontrapost, användningsrapport, webhook-slutpunkt, personalanvändare, prisprofil, leverantörskartläggning.
• Åtgärd: skapa, läs, lista, uppdatera, återkalla, fyll på, återbetala, exportera, frysa, låsa upp.
• Monetär myndighet: om åtgärden ändrar saldo, kreditgräns, marginal, avräkningsstatus, fakturastatus eller utgiftstak.
• Godkännandestatus: om begäran är förgodkänd, väntar på godkännande, dubbelgodkänd, utgången eller endast nödsituation.

Till exempel kan en supportoperatör tillåtas att se en kunds maskerade nyckelmetadata och frysa en nyckel under en incident, men inte skapa krediter, ändra priskatalogen, exportera fullständig användningsdata eller låsa upp nyckeln utan godkännande. En finansoperatör kan skapa en kreditjustering för en kund som ägs av samma partner, men bara inom ett konfigurerat belopp och först efter att det finns en godkännandepost.

Rekommendation: skriv matrisen som en versionerad artefakt och låt sedan varje auktoriseringstestnamn referera till en rad eller regel. När en policy ändras ska skillnaden visa både kontraktsändringen och teständringen.

Use Tenant-Bound Object References

Ogenomskinliga ID:n minskar risken för uppräkning, men de bevisar inte auktorisation. Ett virtuellt nyckel-ID, plånboks-ID, reskontrapost-ID, användningsexport-ID eller markörtoken måste lösas inom den förväntade partner- och hyresgästens gräns.

Ett säkert sökmönster är:

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

Det farliga mönstret är:

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

Den andra versionen tillåter innehav av ett scope, inte auktoritet över målet. Det misslyckas när en giltig token för partner A skickar ett nyckel-ID från partner B, eller när en operatör för kund A skickar ett plånboks-ID från kund B.

Bindning av hyresgästen bör omfatta mer än de uppenbara föremålen. Inkludera markörtokens för användningsrapporter, exportjobb-ID:n, webhook-slutpunkts-ID:n, godkännande-ID:n, idempotensnycklar och reskontrajusterings-ID:n. Dessa föremål känns ofta "inre", vilket är exakt varför de blir svaga punkter.

Bygg en minimal testfixtur för flera hyresgäster

Använd en medvetet liten armatur som gör det lätt att uttrycka fel åtkomst. Målet är inte en bred datavolym. Målet är tydlig åtskillnad.

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

Med den här fixturen kan du testa två felklasser. Först, samma-partner cross-customer access, där en uppringare från P1 försöker röra C1B medan han agerar på C1A. För det andra, åtkomst mellan partner, där en P1-token försöker röra P2:s objekt.

Rekommendation: kör samma match mot den offentliga partnern API och återförsäljarportalens backend. Användargränssnittsbegränsningar skyddar inte direkta API klienter, bakgrundsjobb, webbläsarutvecklingsverktyg eller komprometterade integrationstoken.

Testa objektnivå Authorization på varje effektfull slutpunkt

För varje slutpunkt som accepterar ett objekt-ID, skapa minst ett positivt test och flera negativa test. Positiva tester visar att fixturen är giltig. Negativa tester visar att gränsen håller.

Skapa och söka efter kunder

Kundskapandet ser vanligtvis ofarligt ut eftersom målhyresgästen inte finns ännu. Den behöver fortfarande auktorisering eftersom den som ringer kan försöka skapa kunder under en annan partner, tilldela en förbjuden prissättningsprofil eller ange interna metadata.

Testfall:

• En partnerägare kan skapa en kund under samma partner.
• En automatiseringstoken med kundprovisioneringsomfång kan skapa en kund under samma partner.
• En token för endast support kan inte skapa en kund.
• En P1-token kan inte skapa en kund med partner_id=P2.
• En token på kundnivå kan inte lista syskonkunder.

Skapa, återkalla och rotera nycklar

Nyckellivscykelåtgärder har stor inverkan eftersom de ger körtidsåtkomst och kan avbryta produktionsbelastningar. Providers kontrollplan exponerar vanligtvis administrativa objekt som projekt, arbetsytor, tjänstkonton, medlemmar och API-nycklar via API:er. En gateway eller återförsäljarlager bör behandla sina egna virtuella nycklar med samma försiktighet.

Testfall:

• P1-automatisering kan skapa K1A endast för C1A när dess token inkluderar nyckelskrivningsomfång.
• P1-support kan inte skapa K1A om supportrollen är skrivskyddad för nycklar.
• P1-support kan endast frysa K1A om nödfrysning är inom omfattningen.
• P1-stöd kan inte återkalla K1B när förfrågningskontexten säger C1A.
• P1 full token kan inte återkalla K2A.
• En kundadministratör för C1A kan inte rotera, avslöja eller återkalla K1B.

För team som implementerar Partner API automation är det viktiga testet inte bara "har denna token nyckelskrivning?" Det är "har denna token nyckelskrivning för den här partnern, den här kunden, den här nyckeln, det här tillståndet och den här operationen?"

Kreditpåfyllningar och ändringar av plånbok

Pengaflyttande åtgärder kräver strängare tester än vanliga uppdateringar. En kreditpåfyllning kan vara korrekt syntaktisk och fortfarande vara obehörig eftersom plånboken tillhör en annan hyresgäst, beloppet överstiger behörighet, godkännandeposten riktar sig till en annan kund eller att idempotensnyckeln först användes för en annan operation.

Testfall:

• P1 finance kan fylla på W1A inom sin beloppsgräns efter godkännande.
• P1 finance kan inte fylla på W1B med ett godkännande skapat för W1A.
• P1-ekonomi kan inte fylla på W2A.
• P1-stöd kan inte fylla på någon plånbok.
• En automatiseringstoken kan inte ändra kreditgränsen om den inte har en explicit omfattning för att flytta pengar.
• En omspelad idempotensnyckel kan inte omdirigera en tidigare W1A-påfyllning till W1B.

Rekommendation: behandla idempotensnycklar som omfattningen av partner plus drift plus målhyresgäst plus normaliserad begäran. Ett nytt försök bör vara säkert, men det bör inte bli en kollisionskanal för flera hyresgäster.

Användningsrapporter och exportmarkörer

Användningsrapporter är lätta att underskydda eftersom de är skrivskyddade. I återförsäljarsystem kan användningsdata avslöja kundnamn, arbetsbelastningar, modellval, kostnader, slutanvändaridentifierare och kommersiella marginaler. Cursor tokens och export-ID:n måste också vara hyresgästbundna.

Testfall:

• C1A-administratören kan läsa C1A-användningssegment.
• C1A-administratören kan inte läsa C1B-användning genom att ändra customer_id.
• P1 skrivskyddad analystoken kan endast exportera användning för P1-kunder om exportomfattning finns.
• P1-token kan inte återuppta en P2-användningsexport med en kopierad markör.
• En markör som skapats för en rapport på nyckelnivå kan inte återanvändas för att hämta hyresgästomfattande användning om det inte uttryckligen tillåts.

Om portalen visar AI API kundanvändningsmätning, testa både sammanfattningsvyerna och de nedladdningsbara exporterna. Exportsökvägar kringgår ofta samma kontroller eller policykod som används av interaktiva sidor.

Testa egenskapsnivå Authorization på PATCH och uppdatera slutpunkter

Broken Object Property Level Authorization visas när en anropare tillåts uppdatera ett objekt men kan också ställa in fält som ska vara interna, privilegierade eller ägda av ett annat arbetsflöde.

För Partner API:er inkluderar känsliga fält ofta:

• partner_id, customer_id och förälders ägarskapsfält.
• provider_project_id, provider_workspace_id och uppströms nyckelreferenser.
• pricing_catalog_version, margin_tier och åsidosätter rabatter.
• wallet_balance, credit_limit, settlement_status och fakturastatus.
• fraud_status, risk_score och efterlevnadsflaggor.
• role, scopes och förbikopplingsflaggor för godkännande.

Använd godkännandelistor, inte nekningslistor. Till exempel kan en slutpunkt för uppdatering av kundprofil tillåta display_name, billing_email och metadata.external_reference. Den ska avvisa eller ignorera margin_tier, credit_limit och provider_project_id, även om den som ringer kan uppdatera kundobjektet.

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

Det förväntade resultatet bör vara deterministiskt. Föredrar ett valideringsfel som identifierar otillåtna fält utan att avslöja känsliga interna värden. Acceptera inte privilegierade fält tyst och ignorera dem om inte ditt API-kontrakt redan använder det mönstret konsekvent.

Make Denials Non-numerating

Negativa tester bör kontrollera både statuskoder och svarsform. Om en P1-token begär K2A, bör svaret inte avslöja om K2A finns under en annan partner.

En vanlig regel är:

• Använd 401 när den som ringer inte är autentiserad.
• Använd 403 när den som ringer är autentiserad men saknar ett åtgärdsområde i sin egen gräns.
• Använd 404 eller ett generiskt svar som inte hittades när objektet är utanför anroparens gräns och existensen inte ska avslöjas.

Den exakta konventionen kan variera, men beteendet måste vara konsekvent. Avslagsorganet bör undvika meddelanden som "nyckeln tillhör en annan kund" eller "plånboken finns under partner P2." Den informationen är användbar för angripare och sällan användbar för legitima kunder.

Trade-off: generiska avslag gör felsökning svårare för partnerutvecklare. Lös det med begärande-ID:n, strukturerade granskningsloggar och supportverktyg, inte genom att läcka förekomst av flera hyresgäster i offentliga API-fel.

Logga Authorization-beslutet, inte känsliga nyttolaster

Authorization tester bör också hävda att avslag ger användbara interna bevis. Du behöver tillräckligt med detaljer för att rekonstruera vad som hände under en incident utan att lagra råa uppmaningar, hemligheter eller onödig kunddata.

Loggfält bör innehålla:

• request_id och spåra korrelations-ID.
• actor_id, skådespelaretyp, token-ID och rollmall.
• partner_id från den autentiserade skådespelaren.
• Begärd målhyresgäst och löst målhyresgäst, när upplösning tillåts.
• Objekttyp och åtgärd.
• Policyversion och beslutsresultat.
• Orsakskod för avslag, som missing_scope, tenant_mismatch, approval_required eller field_not_allowed.

Logga inte fullständiga API-nycklar, uppströmsleverantörshemligheter, uppmaningar, råanvändningsnyttolaster eller fullständigt exportinnehåll. Var försiktig så att interna loggar är åtkomstkontrollerade för nekade förfrågningar om flera hyresgäster. det offentliga svaret kan vara generiskt medan säkerhetsteamet fortfarande har tillräckligt med bevis.

Automatisera selen i CI och Staging

Teststammen bör köras på tre ställen: enhetstester för policyfunktioner, integrationstester för API-slutpunkter och iscensättningssonder mot den distribuerade återförsäljarportalens backend. Varje lager fångar olika fel.

En praktisk CI-struktur:

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

Varje matrisrad ska definiera aktör, begäran, förväntat beslut och förväntat icke-uppräknande beteende.

- 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

Lägg till varianter av mutationsstil som byter en identifierare åt gången: kund-ID, nyckel-ID, plånboks-ID, godkännande-ID, markör, idempotensnyckel och webhook-slutpunkts-ID. Dessa tester är repetitiva av design. Upprepning är acceptabelt när det bevisar att varje identifierare är oberoende av varandra.

Driftschecklista

Innan du skickar en Partner API-slutpunkt använder du denna checklista:

• Slutpunkten har en namngiven auktoriseringsregel i policymatrisen.
• Varje objektsökning inkluderar gränsvillkor för partner och hyresgäster.
• Varje lista slutpunkt filtrerar efter aktörsgräns före paginering.
• Varje markör, export-ID, webhook-ID, godkännande-ID och idempotensnyckel omfattas.
• PATCH-slutpunkter använder egendomstillståndslistor efter roll och åtgärd.
• Åtgärder för att flytta pengar kräver explicit omfattning och godkännandestatus.
• Nödfrysning är skild från unfreeze och kreditmyndighet.
• Nekningar undviker existensläckor mellan hyresgäster.
• Revisionsloggar registrerar auktoriseringsbeslutet och policyversionen.
• Samma negativa test körs mot API och portalens backend-sökvägar.

Avvägningar att bestämma uttryckligen

Finkorniga omfattningar minskar sprängradien, men de ökar komplexiteten för partnerintroduktion. Standardrollmallar hjälper: ägare, ekonomi, support, analys, provisioneringsautomatisering och nödsituationer. Låt avancerade partners skräddarsy från dessa mallar istället för att börja från råa omfattningar.

Strikta godkännandelistor för egendom saktar ner funktionsutbyggnaden eftersom varje nytt redigerbart fält behöver ändras. Den friktionen är användbar för fakturering, prissättning, leverantörskartläggning och nyckelhanteringsfält. För fält med lågriskprofiler kan processen vara lättare.

Godkännandeflöden minskar oavsiktliga eller skadliga kreditändringar, men de lägger till fördröjning till legitima supportåtgärder. Håll nödfrysning snabb, reversibel och separat avgränsad. Låt inte samma nödtoken lägga till krediter, ändra marginaler, exportera användning och låsa upp konton.

Prognos: återförsäljarportaler kommer att fortsätta att exponera fler administrativa åtgärder via Partner API:er eftersom kunderna förväntar sig självbetjäning, rapportering och automatisering. Systemen som åldras väl kommer att vara de med auktoriseringskontrakt och negativa tester, inte de som enbart förlitar sig på ruttnamn, dolda gränssnittskontroller eller ogenomskinliga ID:n.

Aktiveringsbar slutsats

Bygg auktoriseringsstammen innan partnern API blir tillräckligt stor för att varje slutpunkt har sitt eget undantag. Börja med två partners, två kunder under en partner, en kund under en annan partner och en liten uppsättning tokens. Testa sedan de åtgärder som kan skada dig mest: skapande av nycklar, återkallande av nycklar, påfyllning av krediter, användningsexporter, plånboksuppdateringar, återanvändning av godkännande, återuppspelning av idempotens och PATCH-fält.

Avtalet är enkelt att ange: en uppringare måste ha rätt omfattning, under rätt partner, för rätt hyresgäst, objekt, egendom, åtgärd, belopp och godkännandestatus. Implementeringsarbetet gör att det blir sant på alla slutpunkter, inklusive de tråkiga.

Relaterad läsning

• idempotent Partner API automation for provisioning keys and credits