Var pull request som lägger till eller ändrar en slutpunkt ändrar din API-attackyta. De flesta API-säkerhetsverktyg märker det inte förrän slutpunkten är live och redan tar emot trafik. Vid det laget är åtgärden inte längre en ändring på en rad i en kodgranskning, utan en konversation om incidentrespons.
API-säkerhet är praxisen att hitta och stänga riskerna i hur en applikation exponerar sina slutpunkter: vem som kan anropa dem, vilka data de returnerar och om de gör det som dokumentationen säger att de gör.
De flesta verktyg som byggts för det här problemet testar API:et vid körning, från utsidan, på samma sätt som en angripare skulle göra. Den metoden fungerar, men den fungerar bara efter att API:et har driftsatts. Xygeni tar den tidigare vägen: den läser din källkod och din API-specifikation innan en enda begäran någonsin når slutpunkten.
De fyra sätten att testa ett API, och vad vart och ett svarar på
De flesta mogna program kör mer än ett av dessa:
- Statisk testning analyserar källkod och API-specifikationer före driftsättning. Den svarar på "vad avslöjade vi just?". Det är den här metoden som den här artikeln fokuserar på.
- Dynamisk testning (DAST) skickar verklig trafik till ett aktivt API och observerar hur det svarar. Den svarar på "vad är faktiskt tillgängligt och exploaterbart just nu?"
- Luddrigt kastar felaktiga eller oväntade indata vid slutpunkter till ytkrascher och fel i kantfallet. Den svarar på "vilka fel under indata som vi inte förväntade oss?"
- Manuell penetrationstestning lägger till mänsklig bedömning för att hitta logiska brister som automatiserade verktyg missar. Den svarar på "vad skulle en smart angripare kedja ihop?"
Ingen av dessa ersätter de andra. De besvarar olika frågor vid olika tidpunkter i livscykeln, och det luckor som de flesta program har är den första.
Varför de flesta API-säkerhetsverktyg ser risken för sent
Säkerhetstestning av runtime-API:er skickar trafik till en aktiv applikation och övervakar hur den svarar. Det är ett legitimt och nödvändigt lager. Det är också, till sin konstruktion, en fördröjningsindikator: en slutpunkt måste existera, driftsättas och vara nåbar innan en runtime-skanner kan säga något om den. Vad den än hittar var redan exponerad oavsett hur lång tid det tog för skanningen att köra.
Det finns ett andra gap under det där tidsproblemet. Runtime-verktyg kan bara testa det de vet existerar. Om en slutpunkt aldrig dokumenterades, eller om OpenAPI-specifikationen blev föråldrad i samma ögonblick som någon skickade en ny rutt, har en runtime-skanner inget sätt att veta att den finns där. Den testar kartan, inte territoriet.
Statisk API-säkerhetstestning täcker båda luckorna genom att flytta kontrollen till där slutpunkten är definierad: din kod och din API-specifikation, före driftsättning. pull request som introducerar en slutpunkt är pull request som avslöjar dess risk.
Vad statisk API-säkerhet egentligen betyder
Xygeni bygger ditt API-inventarium från två källor: din applikations källkod och dina API-specifikationer, inklusive OpenAPI och Swagger.
En specifikationsbaserad inventering visar de slutpunkter som någon kom ihåg att dokumentera. En kodbaserad inventering visar vad som finns men inte nödvändigtvis hur det var tänkt att användas. Att läsa båda ger dig en komplett bild: de slutpunkter som dina team dokumenterade och de som ingen gjorde.
Det lagret är grunden som allt annat bygger på:
- Totalt antal upptäckta API:er och tillgångar i riskzonen mätt mot en baslinje
- Slutpunkter uppdelade efter HTTP-metod
- Problem grupperade efter tjänst
- Varje slutpunkt med dess metod, sökväg, tjänst, modul, autentiseringsstatus och riskpoäng
Dina tekniska chefer ser formen på din API-yta utan att öppna ett enda ärende.
Varje slutpunkt som Xygeni hittade, med dess metod, autentiseringstillstånd och riskpoäng, byggd från kod och specifikation tillsammans.
Production note Beskär AI-triagepanelen från valfri API-säkerhetsskärmdump.
Mappad till OWASP API Security Top 10
Resultaten beskriver ramverket som era säkerhetsteam och era granskare redan använder. Xygeni upptäcker risker i OWASP API-säkerhet. Topp 10 (2023):
En kategori saknas avsiktligt. API6, Obegränsad åtkomst till känsliga affärsflöden, kräver förståelse för vad en affärsprocess ska tillåta, och ingen statisk analysator upptäcker det på ett trovärdigt sätt. Alla leverantörer som påstår något annat säljer dig en kryssruta. Den kategorin stannar kvar hos din hotmodellering och dina penetrationstestare.
Inte alla resultat är lika: Datakänslighet och toxiska kombinationer
En platt lista med resultat behandlar en oautentiserad slutpunkt för hälsokontroll på samma sätt som en oautentiserad slutpunkt som returnerar kundposter. Det är inte samma problem, och en prioriteringsmodell som poängsätter dem identiskt tränar dina team att ignorera listan.
Xygeni klassificerar de data som varje slutpunkt hanterar, flaggar PII, PCI och PHI i förfrågningsparametrar och i svar, och parar ihop det med slutpunktens autentiseringsstatus.
Den korrelerar också fynd som landar på samma slutpunkt och ökar allvarlighetsgraden när de sammanfaller. En PII-läcka i ett svar är ett allvarligt fynd i sig. Samma läcka på en slutpunkt som inte kräver någon autentisering är kritisk, och plattformen poängsätter det på det sättet istället för att lämna anslutningen åt någon att upptäcka manuellt.
Zombie- och föräldralösa slutpunkter: Glidningen mellan kod och specifikation
Eftersom Xygeni läser din kod och din API-specifikation sida vid sida, ser den var de skiljer sig åt. Den avvikelsen syns som tre igenkännbara mönster:
- Odokumenterade slutpunkter. De finns i koden och har aldrig lagts till i specifikationen.
- Zombie-slutpunkter. De är markerade som föråldrade eller utdragna, och de är fortfarande tillgängliga.
- Föräldralösa slutpunkter. Ingen i det nuvarande laget äger dem.
Inget av dessa dyker upp i ett inventarium med endast specifikationer, eftersom det är precis specifikationen som saknar dem.
Bevis du kan agera utifrån, inte en biljett att utreda
Varje fynd pekar på exakt den ansvariga hanteraren: filen, klassen, metoden och den specifika raden som introducerade felet, med den felaktiga koden renderad bredvid. Var och en har också sin allvarlighetsgrad, sin OWASP API Security Top 10-kategori, sin CWE, slutpunktens autentiseringsstatus och känslighetsklassificeringen av de involverade uppgifterna.
Ett fynd som bara namnger en slutpunkt skickar en utvecklare genom kodbasen innan de ens kan börja åtgärda något. Ett fynd som namnger raden placerar dem omedelbart på rätt plats.
Resultaten exporteras som JSON, CSV, Markdown och SARIF 2.1.0, så de hamnar i tverktyg som dina team redan arbetar i.
Hanteraren, raden och koden som introducerade exponeringen. Inte en ärende att utreda.
Varför detta finns i en plattform, inte en annan konsol
Xygeni kör API-säkerhet tillsammans med SAST, SCA, Hemligheter Säkerhet, IaC och DAST inom en enda plattform, korrelerad genom ASPM, istället för att skicka det som ett separat verktyg med sin egen login och sin egen eftersläpning.
Det är viktigt eftersom statiska resultat och runtime-resultat besvarar olika frågor om samma slutpunkt, och de är mer användbara tillsammans än var för sig. Statisk kod visar att en slutpunkt är riskabel innan den skickas. DAST bekräftar vad som faktiskt är nåbart och exploaterbart när den väl är igång.
Dela upp det över två konsoler och den korrelerade risken blir två orelaterade eftersläpningar. Ingen stämmer av dem, och den slutpunkt som är både odokumenterad och oautentiserad hamnar inte i någon av köerna.
Se din verkliga API-attackyta. API-säkerhet finns tillgänglig som en Enterprise tillägg till Xygeni-plattformen, och en skanning körs mot dina egna databaser i din egen infrastruktur.
FAQ
Kan den avgöra vilka slutpunkter som hanterar känsliga data?
Ja. Xygeni flaggar PII, PCI och PHI i endpointparametrar och svar, och använder den klassificeringen för att rangordna fynd efter verklig exponering.
Kan den köras på alla pull request?
Ja. Stegvis skanning analyserar endast de slutpunkter som ändrats, och manifestet som produceras kan fokusera en efterföljande DAST-skanning på samma slutpunkter, så statisk och körtidstestning förblir i linje med vad som faktiskt ändrades.
Lämnar min kod min miljö?
Nej. Skanningar körs i din egen infrastruktur. Endast resultat laddas upp, skyddas under överföring och i vila.
Hur får jag API-säkerhet?
API-säkerhet finns tillgänglig som en Enterprise tillägg. Begär en PoC så kommer den att granskas med dig.
