En pentestare kommer till en okänd sajt och ser bara fasaden. De verkliga sårbarheterna, SQL injection, XSS, path traversal, gömmer sig i djupet: dolda kataloger, bortglömda endpoints, icke-uppenbara requestparametrar. Manuell genomgång tar timmar. Automatiserad genomgång, utan rätt verktyg, missar antingen kritiska ingångspunkter eller kraschar applikationen med en lavin av förfrågningar.

Burp Suite Professional löser denna uppgift med en kombination av "crawler + scanner". En genomkörning, och du har en applikationskarta där varje sida har kontrollerats för dussintals sårbarhetsklasser. Allt i ett fönster, utan skript eller kommandorad.

Den här guiden är en steg-för-steg-genomgång av Burp Suites crawler och scanner: från grundläggande genomgång till finjustering av granskningen. Skärmbilderna är aktuella för versioner från 2024 och framåt, logiken har inte ändrats sedan Burp 2.0. Vi kommer att täcka Crawl, Audit och det kombinerade läget Crawl and Audit.

💡 Snabb översikt:

• Starta en grundläggande crawl-skanning: Dashboard-fliken, New Scan, Crawl, få en sajtkarta i Target.
• Konfigurera crawlern för din uppgift: exkludera webbadresser utanför scope, lägg till inloggningsuppgifter, justera requestpoolen.
• Gå vidare till granskning: Audit Selected Items på valfri webbadress från kartan, Burp hittar sårbarheter och organiserar dem efter allvarlighetsgrad.
• Kombinera Crawl + Audit för testning från början till slut: crawlern går igenom sajten, scannern kontrollerar omedelbart varje upptäckt sida.
• Slutför analysen genom att studera Advisory: payload, request/response, CVSS och åtgärdssteg.

Vad är en web crawler i Burp Suite

En web crawler (även känd som en spider) är en mekanism som går igenom en webbapplikation: följer länkar, skickar formulär och loggar in i skyddade sektioner. Resultatet är en trädliknande sajtkarta på Target-fliken, där varje webbadress kommer med HTTP-metoder och requestparametrar.

Fram till version 1.7 använde Burp Suite Spider, ett separat verktyg med en egen flik. Från och med Burp 2.0 ersatte PortSwigger det med Crawler, inbyggd direkt i Dashboard. Alla automatiserade åtgärder, genomgång, granskning, loggning, samlas i ett fönster. Hantering: pausa/återuppta för varje uppgift separat.

I grunden gör crawlern samma sak som DirBuster eller Dirb: räknar upp kataloger, registrerar dolda webbadresser. Men till skillnad från dem analyserar Burp Crawler sidinnehåll, kör JavaScript (om analys är aktiverad) och förstår applikationens navigationslogik. DirBuster och Dirb brute-forcar helt enkelt med hjälp av en ordlista. Crawler bygger en applikationsgraf.

Köra crawlern: grundläggande skanning

Öppna Burp Suite och växla till fliken Dashboard. Panelen är uppdelad i fyra zoner:

• Tasks, alla pågående genomgångar och skanningar. Härifrån kan du pausa, återuppta och visa detaljer för varje uppgift.
• Event log, Burp Suite-händelser: proxyuppstart, modulfel, skanningsslutförande.
• Issue activity, upptäckta sårbarheter med filtrering efter allvarlighetsgrad och typ.
• Advisories, detaljerat kort för den valda sårbarheten: payload, request/response och CVSS.

Klicka på knappen New Scan högst upp i Tasks-sektionen.

Ett popup-fönster för New Scan visas med två alternativ:

• Crawl and audit, genomgång + granskning i en körning;
• Crawl, endast genomgång.

För en första introduktion, välj Crawl. Ange en test-URL, till exempel http://testphp.vulnweb.com, och klicka på OK.

Fönstret stängs. På Dashboard under Tasks visas en ny uppgift, "Crawl testphp.vulnweb.com". Event log bekräftar händelsen "Crawl started".

Efter ett par minuter är uppgiften slutförd. Leta efter resultatet på fliken Target, crawlern matar ut sajtkartan där i form av ett URL-träd.

På den högra panelen kommer varje webbadress med HTTP-metoder och en Parameters-kolumn. Parametrar indikerar ingångspunkter, potentiellt sårbara för injektioner. Dubbelklicka på kolumnrubriken Parameters, så stiger webbadresser med parametrar till toppen.

Den vänstra panelen i Target upptas av sajtträdet, klickbart och med URL-nestning. Välj valfri katalog, den högra panelen visar omedelbart dess metoder och parametrar.

Finjustera crawlern

Grundläggande genomgång räcker för enkla sajter. Men en verklig applikation är mer komplex: vissa sidor är utanför scope, stängda sektioner kräver auktorisering, och en skör applikation klarar inte dussintals samtidiga förfrågningar.

Vi återvänder till Dashboard, klickar på New Scan igen, men nu skyndar vi inte med OK. Vi konfigurerar.

Exkludera webbadresser utanför scope

I sektionen Scan details, leta upp Detailed scope configuration. Gå till Excluded URL prefixes och lägg till en webbadress som inte ska inkluderas i genomgången, till exempel http://testphp.vulnweb.com/signup.php.

Skapa en anpassad konfiguration

Gå till Scan configuration och klicka på knappen New.

Ett fönster med parametrar öppnas. Konfigurationsnamnet kan lämnas som standard. Den viktigaste parametern är Crawl optimization: ett skjutreglage från "Fastest" till "Deepest" avgör hur djupt crawler:n går in i applikationen. För ett produktionstest, ställ in det närmare Deepest, för snabb rekognoscering, närmare Fastest.

Tids- och sidantalsgränser ställs också in här. Rimliga värden för en medelstor applikation: Maximum crawl time, 50 minuter, Maximum unique locations discovered, 5000.

Inloggningsuppgifter för stängda sektioner

Om applikationen kräver inloggning, kryssa i rutorna Log in to user registration portals och Log in using invalid credentials. Crawler:n kommer att försöka registrera sig med slumpmässiga data eller ange medvetet felaktiga inloggningsuppgifter för att se webbplatsens beteende vid misslyckad autentisering.

Klicka på Save, så visas konfigurationen i rullgardinslistan Scan configuration.

Nu lägger vi till riktiga inloggningsuppgifter, de är användbara om crawler:n stöter på en adminportal eller stängd sektion. Gå till sektionen Application login och klicka på Create.

Ange användarnamn och lösenord, klicka på OK.

Resurspool och samtidiga förfrågningar

Sektionen Resource pool hanterar hur många samtidiga förfrågningar crawler:n skickar till applikationen och med vilken fördröjning. För en känslig applikation, minska antalet trådar och öka fördröjningen. För en demomiljö behåller vi standardvärdena.

Klicka på OK, så startar crawler:n med den angivna konfigurationen. Vi följer förloppet på Dashboard.

Efter slutförandet går vi till fliken Target. Sidan signup.php saknas i webbplatskartan, det exkluderade prefixet fungerade som avsett.

Sårbarhetsskanning: audit-läge

Crawlern ger en applikationskarta. Audit går längre, den kontrollerar upptäckta URL:er för sårbarheter: SQL-injektioner, XSS, kommandoinjektion, path traversal och dussintals andra klasser. I Burp Suites terminologi kallas detta "active scanning".

Till skillnad från passiv skanning (analys av svar utan extra förfrågningar) skickar aktiv audit modifierade förfrågningar med payloads och tolkar applikationens svar.

Audit med standardinställningar

Om applikationen redan har skannats av crawlern kan du audita vilken URL som helst från webbplatskartan. På fliken Target högerklickar du på bas-URL:en och väljer Scan.

Fönstret New Scan öppnas igen, men nu är alternativet Audit selected items aktivt. Alla URL:er från webbplatskartan hämtas automatiskt in i fältet Items to scan. Klicka på OK.

Vi går till Dashboard. Bilden har förändrats: sektionerna Tasks och Event log är aktiva, och viktigast av allt, Issue activity och Advisories har nu data.

Efter några minuter har skannern skickat omkring 17 000 förfrågningar och identifierat sårbarheter grupperade efter allvarlighetsgrad: hög (röd), medium (gul), info (grå).

Ett fönster med en fullständig nedbrytning öppnas. Fliken Audit items visar kontrollerade URL:er och antalet upptäckta sårbarheter.

Fliken Issue activity visar samma information nedbruten efter allvarlighetsgrad. Varje sårbarhet kan expanderas för att visa Advisory.

Fliken Advisories visar hela kortet för den valda sårbarheten. Överst finns URL, allvarlighetsgrad, konfidens, CVSS-poäng. Nedanför finns beskrivning, åtgärdsrekommendationer och länkar till externa resurser om denna sårbarhetsklass.

För att se den specifika HTTP-förfrågan och det svar som utlöste fyndet, gå till fliken HTTP request/response. Här ser du den payload Burp skickade till applikationen och serversvaret som bekräftar sårbarheten.

Finjustering av audit

Standard-auditen täcker alla sårbarhetsklasser. Men ibland behöver du snäva in fokus: kontrollera endast SQL-injektioner eller endast XSS. Eller omvänt, lägga till anpassade kontroller för ett specifikt API.

Skapa en audit-profil

Vi öppnar fönstret New Scan igen. I sektionen Scan configuration klickar du på New, skapa en audit-konfiguration.

I fönstret som öppnas, gå till fliken Audit optimization. Här finns tre nivåer:

• Default, standardtäckning, balans mellan hastighet och djup;
• Thorough, utökat set av payloads och djupare kontroll av varje parameter;
• Fast, lättviktsläge, färre förfrågningar och kontroller.

Sektionen Issues reported låter dig välja specifika sårbarhetsklasser. Lämna till exempel bara SQL injection och Cross-site scripting, så slösar inte skannern tid på att kontrollera path traversal eller kommandoinjektion.

På fliken Audit optimization > Custom kan du mer exakt konfigurera vilka klasser som ska ingå och hur intensiva kontrollerna ska vara.

Skanningstyper

På fliken Audit optimization finns en sektion som heter Scan type med fyra aggressivitetsnivåer:

• Passive, enbart trafikanalys, inga extra förfrågningar. Säkert för produktion, men hittar bara headers och konfigurationsproblem.
• Light active, minimal uppsättning aktiva kontroller. Kompromiss mellan täckning och risk.
• Medium active, fler kontroller, medelhög belastning. För staging-miljöer.
• Intrusive, full uppsättning, inklusive destruktiva kontroller. Endast på isolerade testmiljöer.

På samma ställe kan JavaScript-analys aktiveras som tillval, då kör crawlen JS för att upptäcka dynamiskt innehåll och dolda endpoints i SPA-applikationer.

Det slutliga valet av skanningstyp visas högst upp i konfigurationsfönstret.

Infogningspunkter

Infogningspunkter är positioner i förfrågningar där Burp placerar in payloads. Som standard avgör skannern dessa automatiskt: URL-parametrar, POST-body, headers, cookies. I avancerat läge kan du begränsa eller utöka uppsättningen positioner.

Vi sparar konfigurationen, den dyker upp i dropdown-listan.

Klicka på OK. Skannern skickar cirka 2 700 förfrågningar (jämfört med 17 000 vid en fullständig granskning) och hittar en sårbarhet med hög allvarlighetsgrad.

När du nu högerklickar på en URL i Target visas inte bara ett utan två skanningsalternativ: standard och vår anpassade.

Inbyggda kontroller från biblioteket

Manuell granskningskonfiguration krävs inte. Burp Suite levereras med ett bibliotek med färdiga profiler. När du skapar en ny konfiguration klickar du på Select from library längst ner i fönstret.

Välj en inbyggd profil, till exempel en som är anpassad för en specifik sårbarhetsklass eller applikationstyp.

Den valda profilen hämtas tillbaka till fönstret New Scan.

Klicka på OK. När granskningen är klar visar URL:ens snabbmeny i Target tre skanningsalternativ: default, custom och library.

Skanning och granskning i en körning

Hittills har vi kört crawler och granskning separat. Men Burp Suite har stöd för ett heltäckande Crawl and Audit-läge: först traverserar det applikationen, sedan kontrollerar det omedelbart allt som hittats efter sårbarheter.

Klicka på New Scan igen på Dashboard, välj Crawl and audit, ange URL:en.

I konfigurationsavsnittet, när du klickar på Create, frågar Burp vilken del som ska konfigureras: crawleroptimering eller granskningsparametrar. De interna parametrarna är desamma som vi såg separat.

Detta är huvudläget för produktionspentestning: en körning täcker både rekognosering och sårbarhetsupptäckt. För stora applikationer med tiotusentals sidor är det snabbare att dela upp i två steg, först crawlern, sedan granskningen. Men för de flesta webbplatser levererar Crawl and Audit resultat i en enda körning.

Uppgiftshantering: borttagning och rensning

Slutförda och inaktuella uppgifter bör tas bort för att undvika att Dashboard blir rörigt. Klicka på papperskorgsikonen bredvid uppgiften.

Bekräfta borttagningen i popup-fönstret.

Uppgifter tas bort omedelbart, tillsammans med all insamlad data. Innan du tar bort, se till att granskningsresultaten är sparade eller exporterade.

Video: komplett genomgång av Burp Suite Scanner

Crawlern och skannern är bara en del av Burp Suite. Den här videon täcker hela pentestcykeln: från proxykonfiguration till aktiv granskning och exploatering av upptäckta sårbarheter.

⁉️🤔 Vanliga frågor

Hur skiljer sig Burp Suite Crawler från DirBuster och Dirb?

DirBuster och Dirb arbetar från en ordlista och räknar upp katalognamn från en färdig lista. Burp Suite Crawler bygger en applikationsgraf: analyserar sidinnehåll, extraherar länkar, skickar formulär och kan logga in. Resultatet är en applikationskarta med navigationsrelationer, metoder och parametrar. Den hittar det som ordlistor inte har: dynamiska URL:er, ingångspunkter via JavaScript-omdirigeringar och dolda endpoints bakom inloggningsformulär.

Vilken version av Burp Suite behövs för crawler och audit?

Crawler och aktiv audit finns endast i Burp Suite Professional ($499 per användare och år för 2026, Burp Suite Professional prissättning). Community Edition inkluderar proxy, Repeater, Intruder med hastighetsbegränsning och Decoder, men inte Crawler och inte Scanner. Professional ger båda verktygen plus obegränsad Intruder, Collaborator och BCheck-skript för anpassade kontroller. Från och med version 2025 innehåller Professional även Burp AI, en AI-assistent för att tolka skanningsresultat. Enterprise Edition lägger till CI/CD-integration, schemaläggare och teamsamarbete.

Kan man skanna en webbplats som inte är synlig från internet?

Crawler och audit fungerar genom Burp Suites uppströmsproxy. Allt som är tillgängligt för webbläsaren via Burp Proxy är tillgängligt för crawlern: localhost, staging-servrar bakom VPN, företagsportaler. Ingen ytterligare nätverkskonfiguration krävs, scope sätts via Target scope.

Hur undviker man att krascha produktion med aktiv audit?

Välj Light active istället för Intrusive. Inaktivera kontroller med risk för datakorruption: SQL-injektion med INSERT/UPDATE/DELETE, destruktiv kommandoinjektion, filuppladdning. Tre regler: (1) Endast passiv för första genomgången, (2) Light active utan intrusiva kontroller för den andra, (3) Intrusive endast på staging. Resurspool: 1 tråd, 500 ms fördröjning.

Vad är skillnaden mellan passiv audit och aktiv audit?

Passiv granskning (Passive scanning) skickar inga nya förfrågningar, den analyserar trafik som redan passerat genom proxyn: headers, cookies, svarskroppar. Aktiv granskning (Active scanning) genererar nya förfrågningar med modifierade payloads. Passiv hittar inte SQL-injektion, men identifierar saknade säkerhetsheaders och cookies utan HttpOnly/Secure. I praktiken används båda sekventiellt: passivt medan man surfar, aktivt mot intressanta endpoints.

Hur relevant är Burp Suite 2026?

Burp Suite är fortfarande de facto-standarden för webbpenetrationstestning. Under 2025 lade PortSwigger till en AI-assistent för sårbarhetsanalys, under 2026 en kombinerad Professional/Community-installerare, Markdown-anteckningar och utökad HTTP-trafikkontroll. Konkurrenter (OWASP ZAP, Caido) går framåt, men när det gäller djup i aktiv audit och ekosystemet av tillägg är Burp fortfarande ouppnåeligt.

Vilket Burp Suite-läge du ska välja för din uppgift

Crawler, audit eller båda samtidigt, valet beror på pentest-fasen och målet.

Om du behöver bygga en applikationskarta före manuell analys, kör Crawl med optimeringen Deepest. Lägg till inloggningsuppgifter för stängda sektioner och exkludera URL:er utanför scope (utloggningssidor, lösenordsåterställning).

Om kartan redan finns och målet är att hitta sårbarheter, använd Audit på en specifik uppsättning URL:er. För första genomgången, Passive + Light active. Spara Intrusive till staging.

För omfattande testning "från grunden", Crawl and Audit. En körning, minimalt med manuella moment.

Och huvudregeln: kör aldrig Intrusive på någon annans produktion utan skriftligt medgivande. Även Light active lämnar spår i serverloggar.