Antalet dagliga API-attacker mot organisationer ökade 113 procent under 2025 jämfört med året innan, från i snitt 121 till 258 attacker per dag, enligt Akamais researchteam. Samtidigt rapporterade 87 procent av tillfrågade organisationer minst en API-relaterad säkerhetsincident under samma period. I Sverige har flera stora läckor under 2025 och 2026, bland annat attacken mot HR-plattformen Miljödata och läckan hos CGI Sverige, visat att API:er ofta är den svagaste länken när ett angrepp väl lyckas. Den här guiden går igenom hur du testar dina egna API:er med Burp Suite, verktyget som de flesta professionella penetrationstestare använder som standard för webb- och API-säkerhet.
Du får en praktisk genomgång i 13 steg: från installation och proxykonfiguration till att jaga BOLA-brister, testa JWT-tokens och automatisera attacker med Intruder. Guiden bygger på OWASP API Security Top 10 (utgåva 2023, fortfarande den gällande listan under 2026) och innehåller färdiga kodexempel, en checklista du kan återanvända i varje testomgång och ett litet skript som binder ihop hela arbetsflödet. Målgruppen är utvecklare, testledare och säkerhetsansvariga i svenska och nordiska team som vill komma igång med praktisk API-säkerhetstestning utan att behöva läsa tusen sidor dokumentation först.
Vad är Burp Suite och varför använder pentestare det
Burp Suite är en avlyssnande webbproxy från brittiska PortSwigger som lägger sig mellan din webbläsare (eller ditt API-testverktyg) och målapplikationen. Varje förfrågan och svar passerar genom Burp, vilket gör att du kan läsa, ändra och skicka om trafik innan den når servern. Det låter enkelt, men just den möjligheten, att manipulera exakt det en applikation faktiskt tar emot, är kärnan i nästan all manuell säkerhetstestning av API:er.
Verktyget är uppbyggt kring ett antal moduler som samverkar: Proxy fångar trafiken, Target kartlägger applikationens struktur, Repeater låter dig skicka om och justera enskilda förfrågningar för hand, Intruder automatiserar attacker mot många parametrar samtidigt, och Scanner (endast i betalversionen) letar automatiskt efter kända sårbarhetsmönster. Till detta kommer BApp Store, en inbyggd katalog med tillägg som lägger till specialiserade kontroller, bland annat flera byggda specifikt för att hitta brister i REST- och GraphQL-API:er.
Fördelen med ett proxybaserat verktyg jämfört med att bara skriva testskript i Python eller läsa igenom en OpenAPI-specifikation är att du testar exakt det som faktiskt går över nätverket, inte det ni tror att applikationen gör. Skillnaden spelar roll: dokumentationen säger sällan vad som händer när ett fält saknas, när ett värde är negativt, eller när en header manipuleras för hand. Genom att avlyssna riktig trafik och sedan manipulera den ser du hur API:et faktiskt beter sig i gränsfallen, inte hur det borde bete sig enligt specifikationen. Den skillnaden är precis där de flesta allvarliga API-brister gömmer sig.
Den senaste stora versionsserien är 2026.x, och PortSwigger släppte version 2026.8 den 24 augusti 2026 med en uppdaterad Java-runtime (OpenJDK 26.0.2) inbyggd i installationen. Sedan version 2026.4 använder både Community- och Professional-utgåvan samma installationsprogram, vilket förenklar utrullning för team som kör flera maskiner. Om du redan har en äldre 2026.2- eller 2026.3-version installerad fungerar den här guiden fortfarande, men uppdatera gärna innan du börjar för att slippa skillnader i gränssnittet.
Förkunskaper och installation
Du behöver inte vara certifierad penetrationstestare för att följa den här guiden, men grundläggande förståelse för HTTP, REST-API:er och hur autentiseringstokens fungerar gör allt lättare. Så här ser en rimlig startpunkt ut innan du börjar:
- Burp Suite Community Edition (gratis) eller Professional (från 499 dollar per användare och år sedan prishöjningen 6 januari 2026), version 2026.x
- En modern webbläsare med möjlighet att sätta en manuell proxy, till exempel Firefox eller Chrome
- Java 17 eller senare om du kör en fristående installation utan den bundlade runtimen
- Ett API att testa mot: ditt eget test- eller stagingsystem, aldrig en produktionsmiljö du inte äger eller har skriftligt tillstånd att testa
- Grundläggande kunskap i curl eller Postman för att jämföra resultat
- Python 3.10+ eller bash om du vill köra exempelskriptet i slutet av guiden
Ett viktigt förbehåll redan här: testa aldrig ett API du inte äger eller har fått uttryckligt tillstånd att testa. Oauktoriserad testning mot tredje parts system kan vara brottsligt även om avsikten är god. Bygg istället en egen labbmiljö, använd ett medvetet sårbart testprojekt som OWASP:s crAPI, eller få ett skriftligt godkännande innan du pekar Burp mot något annat.
Vem som äger den här typen av testning skiljer sig mellan organisationer. I mindre svenska team är det ofta backend-utvecklarna själva som kör Burp mot sina egna endpoints inför en release, medan större bolag har en dedikerad säkerhetsfunktion eller köper in externa penetrationstester en eller två gånger om året. Ingen av modellerna utesluter den andra: de guider och checklistor du bygger med hjälp av den här artikeln fungerar lika bra som ett internt stöd för utvecklare som som underlag inför en extern granskning, eftersom samma fynd annars ofta upptäcks två gånger, en gång internt och en gång av den externa testaren, till onödig kostnad.
OWASP API Security Top 10 i korthet
Innan du öppnar Burp är det värt att känna till kartan du navigerar efter. OWASP API Security Top 10, utgåva 2023, är fortfarande den gällande referenslistan under 2025 och 2026 enligt OWASP:s egen projektsida, och listan skiljer sig på flera punkter från det klassiska webb-Top 10. Flera branschguider från 2025 och 2026 pekar särskilt ut trasig objektnivåbehörighet (BOLA) som den enskilt vanligaste allvarliga bristen i både läckedata och pentestresultat, vilket gör den till en naturlig utgångspunkt för dina första tester.
Så skiljer sig 2023 års lista från tidigare utgåvor
Den förra utgåvan av OWASP:s API-lista publicerades 2019, och skillnaden mot 2023 års version är inte bara kosmetisk. Excessive Data Exposure och Mass Assignment, som tidigare var två separata kategorier, slogs ihop till API3, trasig egenskapsnivåbehörighet, eftersom de i praktiken beskriver samma underliggande problem: API:et litar för mycket på klienten när det gäller vilka fält som ska visas eller tas emot. Samtidigt tillkom tre helt nya kategorier: API6 (oskyddade känsliga affärsflöden), API7 (SSRF, som tidigare bara nämndes i förbigående) och API10 (osäker konsumtion av tredjeparts-API:er). Tillsammans speglar de en förskjutning i hur moderna API:er faktiskt attackeras, från enkla injektionsbrister till mer sofistikerad missbruk av legitima affärslogik och beroenden till externa tjänster.
| Risk | Namn | Vad den innebär i praktiken |
|---|---|---|
| API1:2023 | Trasig objektnivåbehörighet (BOLA) | API:et kontrollerar inte att den inloggade användaren faktiskt äger objektet som efterfrågas via ID |
| API2:2023 | Trasig autentisering | Svaga eller felkonfigurerade inloggnings- och tokenmekanismer gör det möjligt att kapa andras identitet |
| API3:2023 | Trasig egenskapsnivåbehörighet | API:et exponerar eller tar emot fler fält än nödvändigt, till exempel att en användare kan sätta sin egen roll till admin |
| API4:2023 | Obegränsad resursförbrukning | Saknad gränssättning på anrop, filstorlekar eller batchstorlekar öppnar för överbelastning och kostnadsattacker |
| API5:2023 | Trasig funktionsnivåbehörighet (BFLA) | Administrativa funktioner går att nå även för vanliga användare eftersom kontrollen bara sker i gränssnittet |
| API6:2023 | Oskyddade känsliga affärsflöden | Automatiserad missbruk av legitima flöden, till exempel massköp eller kontoöversvämning, som ser normala ut anrop för anrop |
| API7:2023 | Server-side request forgery (SSRF) | API:et går att lura till att göra anrop mot interna system eller molnets metadatatjänster |
| API8:2023 | Säkerhetsfelkonfiguration | Osäkra standardinställningar, saknad härdning eller felkonfigurerade proxyer och API-gateway |
| API9:2023 | Bristande inventering | Glömda eller odokumenterade versioner och skugg-API:er som ingen längre bevakar |
| API10:2023 | Osäker konsumtion av tredjeparts-API:er | För stort förtroende för data och svar från externa API:er utan egen validering |
Varför BOLA fortsätter dominera
Håll tabellen ovan öppen medan du testar. Varje steg i resten av guiden pekar tillbaka på en eller flera av dessa tio kategorier, så att du vet exakt vad du faktiskt letar efter i varje modul. BOLA hamnar överst av en enkel anledning: bristen kräver varken avancerad teknik eller specialverktyg, bara ett numeriskt eller gissningsbart ID och ett konto som testaren själv äger. Det gör den till lågt hängande frukt för både forskare som letar bug bounty-belöningar och angripare som letar snabba vägar in. Samma enkelhet gör den paradoxalt nog lätt att missa i vanlig kodgranskning, eftersom koden på ytan ofta ser ut att ha en behörighetskontroll, den kontrollerar bara fel sak (att användaren är inloggad, inte att användaren äger objektet den frågar efter).
Steg 1-3: Sätt upp testmiljön
Steg 1: Installera Burp Suite. Ladda ner Community eller Professional från PortSwiggers nedladdningssida och kör installationsprogrammet. Från och med version 2026.4 är installationsfilen densamma oavsett utgåva, du väljer edition först när du startar programmet och loggar in med ditt PortSwigger-konto (endast Professional kräver licens).
Steg 2: Konfigurera proxyn i webbläsaren. Burp lyssnar som standard på 127.0.0.1:8080. Sätt din webbläsares manuella proxy till den adressen, eller använd ett tillägg som FoxyProxy för att snabbt växla mellan vanlig trafik och Burp-trafik. Testa genom att surfa till valfri sida och kontrollera att förfrågan dyker upp under fliken Proxy > HTTP history i Burp.
Steg 3: Installera Burps CA-certifikat. För att kunna läsa krypterad HTTPS-trafik behöver din webbläsare lita på Burps eget certifikat. Gå till http://burp inne i webbläsaren medan proxyn är aktiv, ladda ner CA-certifikatet och importera det i webbläsarens certifikatarkiv (eller i operativsystemets, om du testar en mobilapp eller ett fristående API-klientverktyg). Utan det här steget kommer varenda HTTPS-förfrågan att blockeras av certifikatvarningar, vilket är den absolut vanligaste nybörjarfällan.
Steg 4-5: Kartlägg API:t med Proxy och Target
Steg 4: Bygg ett scope. Öppna fliken Target, högerklicka på API:ets domän i sajtträdet och välj “Add to scope”. Gå därefter till Proxy-inställningarna och slå på “Show only in-scope items” så att du slipper drunkna i trafik från annonsnätverk, analystjänster och andra webbplatser som råkar öppnas samtidigt. För ett API utan traditionellt användargränssnitt kan du med fördel köra din befintliga Postman-samling eller ett testskript genom Burps proxy för att snabbt fylla sajtträdet med alla kända endpoints.
Steg 5: Läs igenom trafiken manuellt. Klicka dig igenom varje endpoint under Proxy > HTTP history och notera vilka som tar emot ID:n i URL:en (till exempel /api/v1/users/1234), vilka headers som skickar autentisering, och vilka svar som innehåller mer data än vad gränssnittet faktiskt visar. Ett typiskt fångst i historiken kan se ut så här:
GET /api/v1/users/1234/profile HTTP/1.1
Host: api.exempel.se
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...
Accept: application/json
User-Agent: Mozilla/5.0
HTTP/1.1 200 OK
Content-Type: application/json
{"id":1234,"email":"[email protected]","role":"user","ssn":"19850101-XXXX"}Redan här ser du två varningsflaggor: ett numeriskt, gissningsbart ID i URL:en, och ett svar som innehåller personnummer trots att det troligen inte behövs i den vyn. Det är exakt den typen av observationer som leder in i nästa steg.
Steg 6-7: Hitta BOLA och BFLA med Repeater
Steg 6: Skicka en förfrågan till Repeater. Högerklicka på förfrågan i Proxy-historiken och välj “Send to Repeater” (kortkommando Ctrl+R). Repeater är, enligt PortSwiggers egen dokumentation, byggt för att manuellt manipulera och skicka om enskilda meddelanden och analysera applikationens svar, vilket gör det till standardverktyget för riktade BOLA- och BFLA-tester.
Steg 7: Byt ID och observera skillnaden. Ändra användar-ID:t i förfrågan från ditt eget (1234) till någon annans (till exempel 1235) och skicka om. Om servern fortfarande svarar 200 OK med en annan användares data har du hittat en BOLA-brist, API1 på OWASP-listan. Testa sedan samma princip mot administrativa endpoints med ett vanligt användarkonto, till exempel /api/v1/admin/users, för att leta efter BFLA (API5).
GET /api/v1/users/1235/profile HTTP/1.1
Host: api.exempel.se
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...
Accept: application/json
HTTP/1.1 200 OK
Content-Type: application/json
{"id":1235,"email":"[email protected]","role":"user","ssn":"19900615-XXXX"}Fick du data tillbaka för en användare som inte är du, utan att servern nekade eller loggade ut dig? Då har applikationen en objektnivåbehörighetsbrist som bör rapporteras och åtgärdas omgående, oavsett hur “liten” den känns. BOLA-brister av precis den här typen ligger bakom en stor andel av de faktiska dataläckor som har drabbat svenska och nordiska bolag de senaste åren.
Steg 8-9: Automatisera attacker med Intruder
Steg 8: Skicka förfrågan till Intruder. När du manuellt bekräftat att ett ID-fält går att manipulera är nästa naturliga steg att testa det i större skala. Markera förfrågan i Repeater, högerklicka och välj “Send to Intruder”. Intruder beskrivs av PortSwigger som ett kraftfullt verktyg för att köra automatiserade, skräddarsydda attacker mot webbapplikationer, och det är precis vad du behöver för att systematiskt gå igenom tusentals ID:n eller parametervärden.
Steg 9: Markera position och ladda payload-lista. Markera ID-värdet i förfrågan med “Add §” (eller den automatiska markören) och välj attacktyp “Sniper” för att testa ett numeriskt intervall. Under fliken Payloads väljer du typ “Numbers” och anger start- och slutvärde, eller laddar en egen lista:
# Exempel på payload-lista för Intruder (Payload type: Simple list)
1230
1231
1232
1233
1236
1240
9999
0
-1Starta attacken och sortera resultatlistan på svarskod och svarslängd. Ett mönster där de flesta ID:n ger 403 Forbidden men ett fåtal ger 200 OK med varierande svarslängd är en stark indikation på inkonsekvent behörighetskontroll, något som ofta uppstår när ett API har byggts ut av flera team över tid utan en gemensam auktoriseringsmodell.
Intruder erbjuder fyra attacklägen och det är lätt att välja fel. Sniper testar en position i taget med hela payload-listan, vilket passar bäst för just ID-svepning. Battering ram sätter samma värde i flera positioner samtidigt, användbart när ett token upprepas på flera ställen i förfrågan. Pitchfork kör flera payload-listor parallellt, position för position, praktiskt när du till exempel vill para ihop ett användarnamn med rätt lösenord ur två separata listor. Cluster bomb testar alla kombinationer av flera listor mot varandra, kraftfullt men också det läge som lättast överbelastar en oskyddad testmiljö om listorna är stora, så håll koll på antalet trådar under Resource Pool innan du startar.
Steg 10: Skanna automatiskt med Burp Scanner
Community Edition ger dig bara de manuella verktygen (Proxy, Repeater, Decoder, Comparer), medan Scanner-funktionen är reserverad för Professional och DAST-utgåvan. Har du tillgång till Scanner, högerklicka på API:ets rot i Target-trädet och välj “Scan”. Burp Scanner kartlägger då automatiskt attackytan och granskar den mot ett stort antal kända sårbarhetsmönster i både webbapplikationer och API:er, inklusive flera av OWASP:s API-kategorier som SSRF (API7) och säkerhetsfelkonfiguration (API8).
Kom ihåg att en automatisk skanning aldrig ersätter det manuella arbetet i steg 6 till 9. Scanner är bra på att hitta injektionsbrister, felkonfigurationer och kända mönster, men den förstår sällan affärslogiken bakom ett API tillräckligt väl för att självständigt upptäcka en BOLA-brist som kräver att du jämför två olika användarkonton. Se skanningen som ett komplement, inte en ersättning för de manuella stegen.
Skanningen sker i två faser som du kan styra separat under “Scan configuration”. Crawl-fasen bygger sajtkartan genom att följa länkar och skicka in formulär, medan audit-fasen faktiskt skickar attackpayloads mot varje identifierad punkt. För ett API utan renderat gränssnitt är crawl-fasen ofta meningslös eftersom det inte finns några länkar att följa, så mata istället in en färdig lista av endpoints (till exempel exporterad från din Postman-samling eller Proxy-historiken) och kör bara audit-fasen mot dem. Det sparar tid och ger ett renare resultat än en generisk crawl som ändå inte hittar något nytt.
Steg 11: Testa JWT-autentisering och tokens
De flesta moderna API:er använder JSON Web Tokens (JWT) för autentisering, och trasig autentisering (API2) är fortfarande en av de vanligaste bristerna enligt Akamais data för 2025, där ungefär 19 procent av observerade API-attacker involverade just brutna autentiseringsmekanismer. Kopiera din Bearer-token från valfri förfrågan i Proxy-historiken och klistra in den i Decoder-fliken för att bryta ner den i header, payload och signatur:
// Header (Base64-avkodad)
{"alg":"HS256","typ":"JWT"}
// Payload (Base64-avkodad)
{"sub":"1234","role":"user","exp":1798761600}
// Testa i Repeater: byt "alg" till "none" och ta bort signaturdelen,
// samt "role":"user" till "role":"admin". Skicka och se om servern
// fortfarande accepterar token utan giltig signatur.Om API:et accepterar en token där algoritmen satts till “none”, eller om det inte verifierar signaturen alls, kan en angripare fritt ändra sin roll till administratör utan att någonsin behöva knäcka en hemlig nyckel. Testa också vad som händer med en utgången token (justera exp-värdet bakåt i tiden) och en token signerad med fel nyckel, för att säkerställa att servern verkligen validerar allt den ska.
Ett besläktat problem är algoritmförvirring, där servern accepterar både HS256 och RS256 utan att pinna vilken algoritm den förväntar sig. Om API:et publicerar en offentlig RSA-nyckel (till exempel via en JWKS-endpoint) kan den nyckeln under vissa felkonfigurationer återanvändas som en HMAC-hemlighet för att signera en förfalskad token, ett klassiskt trick som fortfarande dyker upp i skarpa API:er. Skickas HS256-signerade tokens med en svag eller förutsägbar hemlig nyckel går det dessutom att köra en offlineattack med ett verktyg som hashcat mot en avlyssnad token, helt utanför Burp, för att kontrollera om nyckeln går att knäcka inom rimlig tid.
Steg 12: Testa rate limiting och resursförbrukning
API4, obegränsad resursförbrukning, handlar om vad som händer när ett API saknar gränser för hur många eller hur stora anrop en klient får skicka. Använd Intruder med attacktyp “Null payloads” för att snabbt skicka samma förfrågan hundratals gånger, eller kör ett enkelt curl-skript utanför Burp för att mäta hur systemet beter sig under belastning:
#!/bin/bash
# Enkel rate-limit-koll: skickar 200 anrop och räknar svarskoder
for i in $(seq 1 200); do
curl -s -o /dev/null -w "%{http_code}\n" \
-H "Authorization: Bearer $TOKEN" \
"https://api.exempel.se/v1/search?q=test"
done | sort | uniq -cEtt förväntat, sunt resultat visar en blandning av 200- och 429-koder (Too Many Requests) efter ett visst antal anrop. Får du 200 OK på samtliga 200 anrop utan avbrott har API:et sannolikt ingen fungerande gräns, vilket öppnar för allt från överbelastningsattacker till kostsam missbruk av betaltjänster kopplade till API:et, till exempel SMS-utskick eller tredjeparts-API-anrop som faktureras per gång.
Steg 13: Bygg ett komplett testprojekt
De föregående stegen fungerar bra som engångstester, men ett API förändras ständigt. Bygg därför in testerna i ett återanvändbart skript som du kan köra manuellt eller lägga in i CI-pipelinen som en snabb säkerhetskontroll innan varje release. Nedan är ett litet men komplett Python-skript som automatiserar de vanligaste kontrollerna: BOLA över ett ID-intervall, saknad rate limiting och ett grundläggande JWT-manipulationstest. Kör det som en snabb “smoke test” innan du går vidare med djupare manuell testning i Burp.
#!/usr/bin/env python3
"""api_smoke_test.py - snabb säkerhetskoll innan manuell Burp-testning"""
import requests, time
BASE = "https://api.exempel.se/v1"
TOKEN = "din-testtoken-har"
HEADERS = {"Authorization": f"Bearer {TOKEN}"}
def test_bola(own_id, other_ids):
for oid in other_ids:
r = requests.get(f"{BASE}/users/{oid}/profile", headers=HEADERS)
if r.status_code == 200 and str(oid) != str(own_id):
print(f"[BOLA-VARNING] ID {oid} gav 200 OK: {r.text[:80]}")
def test_rate_limit(endpoint, n=100):
codes = {}
for _ in range(n):
r = requests.get(f"{BASE}{endpoint}", headers=HEADERS)
codes[r.status_code] = codes.get(r.status_code, 0) + 1
if 429 not in codes:
print(f"[RATE-LIMIT-VARNING] Inga 429-svar efter {n} anrop: {codes}")
else:
print(f"[OK] Rate limiting triggades: {codes}")
if __name__ == "__main__":
test_bola(1234, [1230, 1231, 1235, 1236, 9999])
test_rate_limit("/search?q=test", n=100)Spara resultatet från varje körning tillsammans med datum och API-version, så bygger du snabbt upp en historik som visar om nya brister smyger sig in när koden ändras. Ett riktigt testprojekt kompletterar det här skriptet med en checklista i din ärendehanterare, en fast Burp-projektfil per API, och en rutin för att verifiera att tidigare rapporterade brister faktiskt är åtgärdade innan de stängs.
Vill du gå ett steg längre går det att köra skriptet som ett jobb i GitHub Actions eller motsvarande CI-plattform, till exempel schemalagt varje natt mot en stagingmiljö eller som ett obligatoriskt steg innan en pull request får mergas till huvudgrenen. Låt jobbet returnera en felkod om skriptet hittar en BOLA-varning eller saknad rate limiting, så stoppas releasen automatiskt tills någon i teamet har tittat på fyndet. Kombinerat med en schemalagd, djupare Scanner-körning i Burp Suite DAST eller OWASP ZAP får du på så vis både snabb, kontinuerlig kontroll och regelbunden manuell granskning utan att någon behöver komma ihåg att trycka på en knapp.
Vanliga fallgropar vid API-säkerhetstestning
Även erfarna testare fastnar i samma fällor om och om igen. Här är de vanligaste, och hur du undviker dem.
- Glömt CA-certifikat. Utan Burps CA-certifikat installerat blockeras all HTTPS-trafik av certifikatfel, vilket ofta misstolkas som att API:et självt kräver klientcertifikat.
- Testar bara ett konto. BOLA och BFLA går nästan aldrig att hitta med ett enda testkonto. Skapa alltid minst två konton med olika roller innan du börjar.
- Skanning utan scope. Att köra Scanner eller Intruder mot hela domänen istället för avgränsade endpoints riskerar att träffa produktionssystem, tredjepartstjänster eller betalflöden av misstag.
- Ignorerar GraphQL och WebSocket. Många team testar bara REST-endpoints och missar att samma API exponerar en GraphQL-endpoint eller en WebSocket-kanal med helt andra behörighetskontroller.
- Litar blint på Scanner. Automatisk skanning missar nästan alltid affärslogiska brister som BOLA och oskyddade affärsflöden (API6), eftersom de kräver förståelse för vad en “korrekt” respons faktiskt är.
- Testar i produktion utan tillstånd. Det låter uppenbart, men stressade releaser leder ofta till att någon “bara kollar snabbt” mot skarp miljö utan godkännande.
- Sparar aldrig testresultat strukturerat. Utan historik är det omöjligt att avgöra om en brist är ny, återkommande eller redan rapporterad tidigare.
- Testar bara lyckade flöden. Många team kör igenom API:et som en vanlig användare skulle göra, men glömmer att skicka tomma fält, negativa tal, orimligt långa strängar och fel datatyper, exakt de indata en verklig angripare provar först.
Felsökning: vanliga problem och lösningar
Stöter du på problem under installationen eller testningen är det oftast något av följande som ligger bakom.
| Problem | Trolig orsak | Lösning |
|---|---|---|
| Ingen trafik syns i Proxy-historiken | Webbläsarens proxy pekar inte mot Burp, eller trafiken går via en app som inte respekterar systemproxyn | Kontrollera proxyinställningen igen och testa med curl –proxy 127.0.0.1:8080 |
| Certifikatvarning i webbläsaren | Burps CA-certifikat är inte importerat eller har hamnat i fel certifikatarkiv | Ladda ner certifikatet från http://burp igen och importera det som betrodd rotutfärdare |
| Intruder är gråmarkerad | Du kör Community Edition, där Intruder är hastighetsbegränsad och saknar vissa attacktyper | Uppgradera till Professional, eller begränsa antalet payloads i Community-läget |
| Scanner-fliken saknas helt | Community Edition har ingen Scanner-modul alls | Kör manuell testning med Repeater och Intruder istället, eller uppgradera |
| API:et svarar 401 på allt i Repeater | Token har hunnit gå ut, eller sessionen är bunden till andra headers som saknas | Hämta en färsk token via inloggningsflödet och kontrollera om API:et kräver ytterligare headers som User-Agent eller X-Client-Id |
| Mobilappens trafik dyker inte upp | Appen använder certificate pinning som blockerar Burps mellanhandscertifikat | Använd ett verktyg som Frida eller objection för att kringgå pinning i en testmiljö, aldrig i produktion |
| Intruder-attacken tar orimligt lång tid | Målservern har egen rate limiting som bromsar varje anrop | Sänk antalet trådar under Resource Pool-inställningarna eller lägg in fördröjning mellan anrop |
| Burp kraschar eller hänger sig vid stora svar | Java-processen har fått för lite tilldelat minne för ett stort API-svar eller en lång skanning | Höj minnesgränsen i Burps startinställningar (Java -Xmx-flaggan) eller filtrera bort stora binärsvar från scope |
| Falska positiva i Scanner-rapporten | Automatisk skanning känner inte till applikationens specifika felmeddelanden och tolkar dem fel | Verifiera varje fynd manuellt i Repeater innan det rapporteras vidare |
| WebSocket-trafik syns inte i Proxy | Burp fångar WebSocket-handskakningen men visar meddelanden i en separat vy som lätt missas | Öppna fliken Proxy > WebSockets history istället för HTTP history för att se den löpande meddelandetrafiken |
Burp Suite jämfört med alternativen
Burp Suite är inte ensamt på marknaden. OWASP ZAP är det mest kända alternativet, helt gratis och öppen källkod, vilket gör det populärt bland studenter och team med begränsad budget. Ett nyare alternativ är Caido, ett lättviktigt verktyg för webbsäkerhetsgranskning som fångar och manipulerar HTTP-trafik på ett sätt som liknar Burp men med ett snabbare, mer modernt gränssnitt. Postman räknas sällan som ett rent säkerhetsverktyg, men fungerar väl som API-klient för funktionstestning och kan kombineras med Burp genom att dirigera Postmans trafik via Burps proxy.
| Verktyg | Kostnad | Styrka |
|---|---|---|
| Burp Suite Professional | 499 dollar per användare och år (2026) | Bäst i klassen för manuell testning: Repeater, Intruder med flera attacklägen, Comparer och Sequencer |
| Burp Suite Community | Gratis | Fullt fungerande Proxy, Repeater och Decoder, men utan Scanner och med begränsad Intruder |
| OWASP ZAP | Gratis, öppen källkod | Starkast för automatiserad skanning i CI/CD-pipelines via Docker och GitHub Actions |
| Caido | Gratis- och betalnivå | Modernt, lättviktigt gränssnitt med snabbare arbetsflöde för dagliga tester |
| Postman | Gratis- och betalnivå | Bäst för API-design, dokumentation och funktionstestning, inte en dedikerad säkerhetsskanner |
Många säkerhetsteam kör faktiskt flera av verktygen parallellt: ZAP i pipelinen för kontinuerlig, automatisk kontroll, och Burp Suite Professional för djupare manuell granskning inför större releaser eller när ett fynd behöver verifieras och dokumenteras i detalj.
Prissättning för Burp Suite 2026
Community Edition är fortsatt helt gratis och räcker gott för att lära sig grunderna och köra de flesta stegen i den här guiden. Professional höjdes från 449 till 499 dollar per användare och år den 6 januari 2026, med möjlighet att teckna ett-, tre- eller tioåriga licenser för att sänka snittkostnaden. För organisationer som vill köra kontinuerlig, automatiserad skanning över hela API-flottan finns Burp Suite DAST (tidigare kallat Enterprise Edition), där priset offereras individuellt men där jämförelsesajter för säkerhetsinköp har noterat en typisk startnivå kring 19 000 dollar per år för obegränsat antal användare plus skannerkapacitet.
För ett litet till medelstort svenskt utvecklingsteam är en enskild Professional-licens ofta det mest kostnadseffektiva valet: den täcker allt som beskrivs i den här guiden, och den fria Community-utgåvan fungerar utmärkt som komplement för utvecklare som bara behöver Proxy och Repeater i sitt dagliga arbete.
Läget i Sverige och Norden
API-säkerhet är inte längre ett abstrakt hot i den nordiska kontexten. Flera av de senaste årens största svenska dataläckor har haft ett bristfälligt eller överexponerat API som en central del av angreppskedjan, vilket gör praktisk testning till mer än en teoretisk övning för lokala utvecklingsteam.
Miljödata och CGI-läckan
I augusti 2025 drabbades HR-plattformen Miljödata av en ransomware-attack som enligt tidigare rapportering påverkade uppemot 870 000 personer kopplade till svenska kommuner, en incident som visade hur en enda sårbar leverantör kan slå igenom hela den offentliga sektorn. I mars 2026 publicerade aktören ByteToBreach källkod från ett svenskt e-tjänstsystem efter ett intrång hos CGI Sverige AB. De läckta materialen innehöll bland annat API-dokumentation, signeringsnycklar för API-anrop och testendpoints som tillät fjärrkörning av kod, en påminnelse om att API-hemligheter i källkod är minst lika känsliga som produktionsdata. Båda incidenterna delar ett mönster: skadan spred sig inte genom en enda spektakulär exploit, utan genom vardagliga API-brister av precis den typ som Repeater och Intruder är byggda för att hitta innan de hamnar i produktion.
Vad IMY:s och Wallarms siffror visar
Integritetsskyddsmyndigheten (IMY) tog emot 12 276 anmälningar om personuppgiftsincidenter under 2025, den högsta siffran sedan GDPR trädde i kraft, vilket ger en fingervisning om hur många svenska system som brister i grundläggande dataskydd, ofta med ett API som ingångspunkt. Wallarms API ThreatStats-rapport för 2026 pekar på samma mönster globalt: av 67 058 analyserade publicerade sårbarheter under 2025 var 11 053, ungefär 17 procent, API-relaterade, och 43 procent av de nya sårbarheter som CISA lade till i sin KEV-katalog under 2025 rörde just API:er. Att lära sig testa API:er praktiskt, med ett verktyg som Burp Suite, är därför inte längre en nischkompetens utan en grundfärdighet för alla team som bygger eller driftar API:er i Sverige och Norden.
Avancerade tips för erfarna testare
När grunderna sitter finns det flera sätt att fördjupa testningen ytterligare. Installera tillägg från BApp Store som är byggda specifikt för API-testning, till exempel verktyg som analyserar OpenAPI-specifikationer och automatiskt genererar testfall för varje dokumenterad endpoint, inklusive de som saknar exempel i dokumentationen. Använd Burp Collaborator för att upptäcka blinda SSRF-brister (API7), där API:et gör ett internt anrop som aldrig syns i det direkta svaret men som går att bevisa genom att servern kontaktar en extern testdomän du kontrollerar.
Bygg egna Repeater-grupper per OWASP-kategori så att du snabbt kan gå igenom samma kontroller nästa gång API:et ändras. Kombinera Burp med ett schemautvalideringsverktyg som jämför faktiska svar mot API:ets OpenAPI-schema, eftersom avvikelser ofta avslöjar fält som läcker mer data än specifikationen tillåter, ett tydligt tecken på API3. Slutligen: dokumentera varje fynd med fullständig förfrågan, svar och en kort beskrivning av affärsrisken, inte bara den tekniska detaljen, så att utvecklingsteamet förstår varför bristen behöver prioriteras.
För team som testar samma API regelbundet lönar det sig att spara Burp-projektfilen mellan körningar istället för att starta om från noll varje gång. Projektfilen behåller sajtträdet, dina sparade Repeater-flikar och tidigare Intruder-resultat, vilket gör det enkelt att jämföra en ny körning mot föregående månads fynd och snabbt se om ett tidigare rapporterat problem har återkommit efter en refaktorering. Sätt även upp en enkel namnkonvention för projektfilerna, till exempel api-namn_yyyymmdd.burp, så slipper teamet leta efter rätt fil när en incident kräver att ni snabbt slår upp exakt vad som testades och när.
Vanliga frågor
Är Burp Suite Community Edition tillräckligt för att testa API:er?
Ja, för manuell testning av BOLA, BFLA och grundläggande autentiseringsbrister räcker Community gott. Du saknar bara den automatiska Scanner-funktionen och får en hastighetsbegränsad Intruder, vilket gör större skanningar långsammare men inte omöjliga.
Är det lagligt att testa ett API med Burp Suite?
Bara om du äger systemet eller har fått skriftligt tillstånd från ägaren. Att köra Burp mot ett API du inte har rätt att testa kan strida mot dataintrångslagstiftning oavsett hur god avsikten är.
Hur skiljer sig API-testning från vanlig webbapplikationstestning i Burp?
Verktygen är desamma, men fokus flyttas från formulär och sidladdningar till att jämföra svar mellan olika användarkonton, verifiera behörighetskontroller på objekt- och funktionsnivå, och granska tokens och headers snarare än synligt gränssnittsinnehåll.
Vad är skillnaden mellan BOLA och BFLA?
BOLA (API1) handlar om att komma åt ett specifikt objekt som tillhör någon annan, till exempel en annan användares profil. BFLA (API5) handlar om att komma åt en hel funktion, till exempel en administrativ åtgärd, som du inte borde ha behörighet till.
Kan Burp Suite testa GraphQL-API:er?
Ja. Proxy och Repeater fungerar likadant oavsett om API:et är REST eller GraphQL, och flera tillägg i BApp Store är byggda specifikt för att analysera GraphQL-scheman och bygga introspektionsbaserade attacker.
Hur ofta bör vi köra API-säkerhetstester?
Bäst resultat får team som kombinerar kontinuerlig, automatiserad skanning (till exempel med ZAP eller Burp DAST i CI/CD) med djupare manuell testning i Burp Suite Professional inför varje större release eller när nya endpoints läggs till.
Behöver vi en dedikerad säkerhetstestare, eller kan utvecklare göra det här själva?
Grunderna i den här guiden, särskilt BOLA-, BFLA- och rate limiting-testerna, kan de flesta utvecklare lära sig och köra själva. Djupare tester av affärslogik och SSRF-kedjor gynnas dock av en person med specifik säkerhetsbakgrund.
Vad kostar det att komma igång?
Ingenting, om du börjar med Community Edition och ett eget testlabb. Vill teamet ha automatisk skanning och snabbare Intruder-attacker kostar Professional 499 dollar per användare och år från och med 2026.
Vilket labb kan vi öva på innan vi testar ett riktigt API?
OWASP:s eget crAPI-projekt (Completely Ridiculous API) är byggt specifikt för att öva på OWASP API Security Top 10 i en säker, medvetet sårbar miljö. Det går att köra lokalt med Docker på några minuter och täcker de flesta bristtyper som beskrivs i den här guiden, inklusive BOLA, trasig autentisering och obegränsad resursförbrukning.
