Claude Code: säkerhetschecklista för snabba kontroller av webbappar

Vad en lättviktig säkerhets-spot-check är

En lättviktig säkerhets-spot-check är en snabb granskning (ofta 30–60 minuter) avsedd att hitta uppenbara, högpåverkande problem innan de släpps. Det är inte en fullständig revision. Tänk på det som en säkerhetsrond: du skannar de vägar som oftast går fel i verkliga appar och letar efter bevis, inte gissningar.

Denna Claude Code-säkerhetschecklista fokuserar på de områden som oftast brister i vardagliga webbappar:

• Autentiseringsantaganden (hur du vet vem användaren är)
• Auktoriseringsluckor (vad de får göra)
• Indatavalidering
• Hantering av hemligheter
• Vanliga injektionsytor (SQL, kommandokörning, templatrendering, omdirigeringar, uppladdningar)

Den försöker inte bevisa att buggar inte finns, modellera komplexa hotaktörer eller ersätta penetrationstester.

"Konkreta fynd" innebär att varje problem du dokumenterar har bevis som en utvecklare kan agera på omedelbart. För varje fynd, få med:

• Exakt fil(er) och funktions-/handler-namn
• Den riskfyllda beteendet i en mening
• Ett minimalt reproduktionssteg (request, payload eller klickväg)
• Varför det är viktigt (påverkan) och vem som kan trigga det
• En säker riktning för fixen (inte en full omskrivning)

AI är en hjälpare, inte en auktoritet. Använd den för att söka, sammanfatta och föreslå tester. Verifiera sedan genom att läsa koden och, när möjligt, reproducera med en riktig förfrågan. Om modellen inte kan peka på specifika platser och steg, behandla påståendet som obekräftat.

Sätt scope på 10 minuter

En snabb granskning fungerar bara om du smalnar av målet. Innan du ber Claude Code titta på något, bestäm vad du försöker bevisa idag och vad du inte kontrollerar.

Börja med 1 till 3 verkliga användarresor där misstag kostar pengar, exponerar data eller ger makt. Bra kandidater är inloggning, lösenordsåterställning, checkout och adminredigeringsskärmar.

Nämn sedan de tillgångar du måste skydda. Var specifik: användarkonton, betalningsåtgärder, personuppgifter, admin-enda operationer.

Skriv sedan ner dina hotantaganden i enkla ord. Försvarar du mot en nyfiken användare som klickar runt, en extern angripare med skript eller en insider med viss åtkomst? Svaret ändrar vad som är "tillräckligt bra".

Slutligen, definiera pass och fail så att din spot-check slutar med fynd, inte magkänsla. Enkla regler fungerar bra:

• Pass: varje känslig åtgärd visar en tydlig authn- och authz-kontroll.
• Fail: någon endpoint litar på klienten för användar-ID eller roll.
• Pass: inputs valideras server-side, inte bara i UI.
• Fail: hemligheter syns i loggar, konfigurationer eller klientkod.

Om du inte kan beskriva hur ett fel ser ut är scopet fortfarande för oklart.

Förbered kontexten du ger Claude Code

En spot-check fungerar bara om modellen tittar på rätt platser. Samla ett litet paket med kod och anteckningar så att granskningen kan ge bevis, inte gissningar.

Börja med att dela den säkerhetskritiska vägen: request-entrépunkter och koden som avgör vem användaren är och vad hen får göra. Inkludera precis tillräckligt med omgivande kod för att visa hur data flödar.

Ett praktiskt paket brukar innehålla:

• Auth-entré: session/JWT-parsing, cookie-inställningar, login-callbacks, auth-middleware
• Routes + handlers: controllers, RPC-metoder, GraphQL-resolvers, bakgrundsjobbs-hanterare
• Datalager: ORM-frågor, råa SQL-hjälpare, query-builders, migrationer för känsliga tabeller
• Policys: rollkontroller, ägarskapskontroller, feature-flaggor, admin-enda endpoints
• Validering: request-schema-validators, filuppladdningshanterare, deserialiseringskod

Lägg till ett par rader miljöanteckningar så antaganden blir tydliga: session vs JWT, var tokens bor (cookie eller header), reverse proxy eller API-gateway-beteende, köer/cron-workers, och eventuella "endpoints endast för intern användning".

Innan du jagar buggar, be om en inventering: entrépunkter, privilegierade endpoints och datalager som berörs. Det förhindrar missade ytor.

Kom också överens om ett outputformat som tvingar fram konkreta fynd. En enkel tabell fungerar bra: Fynd, Allvarlighetsgrad, Påverkad endpoint/fil, Bevis (exakt utdrag eller linjeintervall), Utnyttjandescenario, Förslag till fix.

Steg-för-steg arbetsflöde för en 30–60 minuters granskning

Tidsboxa det:

• 10 minuter för orientering
• 15–30 minuter för att följa flöden
• 10 minuter för dokumentation

Målet är inte perfekt täckning. Det är en liten uppsättning testbara fynd.

Ha appen öppen medan du läser. Klicka igenom UI:t och se vilka förfrågningar som skickas. Anteckningar bör peka på specifika endpoints, parametrar och datakällor.

Ett arbetsflöde som ryms i en sittning:

1. Skissa entrépunkter och förtroendegränser. Notera publika routes, inloggade routes, admin-routes, webhooks, uppladdningar och callbacks från tredjepart. Markera var data går från användarkontrollerat till server-trust.
2. För varje viktig endpoint, skriv vad som bevisar identitet och var det händer. Om kontrollen är "middleware", bekräfta att varje route faktiskt använder den.
3. Gör samma för auktorisering. Välj en riskfylld åtgärd (visa andras användardata, uppdatera roller, exportera, radera) och följ beslutet hela vägen till databasen.
4. Följ användarindata till "sinks". Följ en parameter från request till SQL/ORM-frågor, template-rendering, kommandokörning, URL-fetches (SSRF), omdirigeringar och filvägar.
5. Skanna hemlighets- och konfigflöden medan du följer dem. Leta efter tokens i loggar, klientkod, felmeddelanden och miljöutskrifter.

En användbar vana: för varje "verkar okej", skriv vad du skulle göra för att bryta det. Om du inte kan beskriva ett sätt att bryta det har du troligen inte verifierat det.

Authn-spot-checks: bevisa vem användaren är

Autentisering är där appen bestämmer: "den här förfrågan tillhör den här personen." En snabb spot-check handlar inte om att läsa varje rad. Det handlar om att hitta platsen där identitet etableras och sedan kontrollera genvägar och felvägar.

Lokalisera förtroendegränsen: var skapas eller accepteras identiteten först? Det kan vara en session-cookie, en JWT-bearer-token, en API-nyckel eller mTLS i kanten. Be Claude Code peka på exakt fil och funktion som förvandlar "anonym" till ett användar-id, och lista varje annan väg som kan göra detsamma.

Authn-kontroller värda att skanna:

• Identifiera alla auth-entréer (weblogin, API-tokens, mobil auth, intern service-auth) och bekräfta att de konvergerar till en konsekvent identitetsmodell.
• Kontrollera login och lösenordsåterställning för rate limits, låsning och user enumeration (olika felmeddelanden eller tidsfördröjningar för befintliga vs icke-befintliga konton).
• Inspektera session och cookies: HttpOnly, Secure, SameSite, utgångstid, rotation vid inloggning och privilegieändring, samt logout-invalidering (server-side, inte bara "ta bort cookie").
• Granska MFA och återställning så att återställningsvägen inte är svagare än MFA (t.ex. e-post-återställning som kringgår MFA).
• Granska auth-fel-logging: användbart för ops, men läck inte detaljer som hjälper angripare (inga "användare finns"-hintar, inga token-dumpar).

Ett praktiskt exempel: om återställningsmejl returnerar "konto hittades inte" är det ett snabbt enumeration-problem. Även med ett generiskt meddelande kan tidsdifferenser läcka samma fakta, så kontrollera även svarstider.

Authz-spot-checks: bevisa att användaren har behörighet

Auktorisering är den fråga som orsakar mest skada när den är fel: "Får den här användaren göra denna åtgärd på denna exakta resurs?" En snabb spot-check bör medvetet försöka bryta det antagandet.

Skriv roller och behörigheter i vanligt språk. Håll det mänskligt:

• Ägare kan bjuda in medlemmar
• Medlem kan redigera sin egen profil
• Support kan se fakturauppgifter men inte ändra plan
• Admin kan radera projekt

Verifiera sedan att varje känslig åtgärd upprätthåller authz på serversidan, inte bara i UI. Knappar kan döljas, routes kan blockeras i klienten, men en angripare kan fortfarande anropa API:t direkt.

En snabb genomgång som ofta hittar verkliga problem:

• Hitta endpoints/mutationer som skapar, raderar, exporterar, ändrar roller eller får åtkomst till fakturering
• För varje, lokalisera server-side behörighetskontroll (inte frontend)
• Leta efter användarkontrollerade ID:n (projectId, userId, orgId) och bekräfta ägarskapskontroller
• Bekräfta att admin-enda vägar "fail closed" när roll saknas
• Kontrollera tenant-gränser: orgId/accountId bör komma från sessionkontext, inte bara från request-input

Den klassiska IDOR-doften är enkel: en request som GET /projects/{id} där {id} kontrolleras av användaren och servern laddar den utan att verifiera att den tillhör aktuell användare eller tenant.

En prompt som tvingar fram ett verkligt svar:

"För denna endpoint, visa exakt kod som avgör åtkomst och lista specifika villkor som skulle tillåta en användare från en annan orgId att få åtkomst. Om inga finns, förklara varför med fil- och funktionsnamn."

Indatavalidering: håll dåliga data ute tidigt

De flesta snabba webbapp-problem börjar med en lucka: appen accepterar input utvecklaren inte förväntade. Behandla "input" som allt en användare eller ett annat system kan påverka, även om det känns ofarligt.

Börja med att namnge input för endpointen du granskar:

• URL query och path-värden
• Request body-fält (inklusive nästlad JSON)
• Headers (auth-headers, content-type, forwarded IP)
• Cookies
• Filuppladdningar (namn, storlek, typ, metadata)

Validering bör ske nära där data går in i appen, inte djupt i affärslogiken. Kontrollera grunderna: typ (string vs number), maxlängd, obligatorisk vs valfri och format (email, UUID, datum).

För kända värden som roller, statusfält eller sorteringsriktningar, föredra en allowlist. Det är svårare att kringgå än att "blockera ett par dåliga värden."

Granska också felhantering. Om appen avvisar input, ekar den inte tillbaka det råa värdet i svaret, loggar eller UI. Det är så små valideringsbuggar blir dataläckor eller hjälp för injektion.

En snabb "dålig input"-mini-plan för riskfyllda endpoints (login, sök, uppladdning, admin-åtgärder):

• För långa strängar (10 000+ tecken)
• Fel typ (array istället för string)
• Oväntade enum-värden
• Specialtecken som kan ändra betydelse
• Tomma värden för obligatoriska fält

Exempel: en sort-parameter som accepterar vilken sträng som helst kan bli ett SQL-fragment senare. En allowlist som "date" eller "price" förhindrar den typen av misstag tidigt.

Vanliga injektionsytor att snabbt skanna

De flesta snabba granskningar hittar problem på samma få ställen: där användarinput tolkas som kod, en fråga, en sökväg eller en URL. Här letar du efter ögonblick där input korsar en förtroendegräns.

Följ data från entrépunkter (query params, headers, cookies, uppladdningar, admin-formulär) till där den hamnar.

Snabba skanningsmål

Titta efter dessa mönster och kräva ett konkret call site och payload-exempel för varje:

• SQL-injektion: stränguppbyggda queries, dynamisk ORDER BY, och IN (...)-byggare som joinar användarvärden
• XSS: HTML-rendering, templates, markdown-preview, rich text-editors där "sanera senare" antas
• Kommandoinjektion: shell-anrop kring bildbehandling, PDF-verktyg, backup- eller convert-steg som passerar användarkontrollerade flaggor
• SSRF: URL-fetchers för webhooks, länkförhandsvisningar, import-från-URL-funktioner och interna statuskontroller som accepterar en användar-URL
• Path traversal: filnedladdningsendpoints, zip-extraktion, och uppladdningspipelines som senare läser filer tillbaka efter namn

Observera också deserialisering och templatinjektion. Allt som parser användarleverad JSON, YAML eller templated-strängar kan dölja riskfyllt beteende, särskilt om det stödjer custom-typer, uttryck eller server-side rendering.

Om en funktion accepterar en URL, ett filnamn eller formaterad text, anta att den kan missbrukas tills du kan bevisa motsatsen med kodvägar och tester.

Hantering av hemligheter: hitta läckor och svag lagring

Problem med hemligheter är ofta högljudda när du vet var du ska leta. Fokusera på var hemligheter bor och var de av misstag kopieras.

Vanliga ställen hemligheter dyker upp:

• Miljövariabler och appkonfigfiler
• CI-utdata och build-loggar (inklusive misslyckade deploy-loggar)
• Klientpaket och mobilbyggen (allt som skickas till användare)
• Debug-endpoints, health-sidor och admin-verktyg
• Fel-sidor, stacktraces och analytics-händelser

Tvinga sedan fram ett konkret svar: om en hemlighet exponerades idag, vad händer härnäst? Ett bra system har en rotationsväg (ny nyckel utfärdas), återkallning (gammal nyckel inaktiveras) och ett sätt att återplacera snabbt. Om svaret är "vi skulle ändra det senare", behandla det som ett fynd.

Least privilege är en annan snabb vinst. Incidenter blir värre eftersom nycklar är övermäktiga. Leta efter databas-användare som kan droppa tabeller, tredjepartstokens som kan hantera konton eller API-nycklar delade mellan miljöer. Föredra en nyckel per tjänst, per miljö, med minsta möjliga behörighet.

Snabba prompts du kan klistra in i Claude Code:

• "Sök efter hårdkodade tokens, lösenord och privata nycklar. Lista exakta filvägar och vilka strängmönster du matchade."
• "Hitta kod som loggar request-headers, cookies, env-vars eller fulla error-objekt. Visa loggraderna och vilka känsliga fält som kan dyka upp."
• "Kontrollera om hemligheter kan hamna i snapshots, exports eller build-artifakter. Identifiera vad som fångas och var det lagras."

Slutligen, bekräfta guardrails: blockera hemligheter från versionskontroll (pre-commit/CI-checks), och se till att backups eller snapshots inte inkluderar klartextuppgifter. Om plattformen stöder snapshots och rollback, verifiera att hemligheter injiceras i runtime, inte bakas in i sparade images.

Prompter som tvingar fram konkreta fynd (kopiera-klistra-mönster)

Vaga prompts ger vaga svar. Tvinga modellen att binda sig till bevis: exakta platser, ett spår du kan följa, en repro du kan köra och vad som skulle göra påståendet fel.

Använd ett mönster i taget, be den sedan revidera efter att du bekräftat eller avvisat en detalj.

• Fil-nivåbevis: "Sök i repot efter auth, sessions, tokens och middleware. Namnge exakta filer, funktioner och linjeintervall. Citera relevanta utdrag. Om du inte kan peka på kod, säg 'no evidence found'."
• Spåra från input till sink: "Välj en användarkontrollerad input (header, query, body, cookie). Visa dataflödet steg-för-steg från entrépunkt till där det används (SQL, HTML, shell, template, redirect, filväg). Lista varje funktion i kedjan."
• Repro-steg: "Ge en minimal repro med curl (metod, URL-form, headers, body). Inkludera förväntad statuskod och ett succé/fel-exempel i svaret. Ange antaganden (roller, auth-state)."
• Kontroll för falska positiva: "Vad skulle motbevisa detta fynd? Lista 2–3 kontroller: config-flaggor, middleware-ordning, allowlist-validering, parametriserade queries, ramverkets escaping. Om någon finns, förklara varför risken förändras."
• Minsta säkra fix + test: "Föreslå den minsta förändringen som blockerar problemet utan att bryta giltiga fall. Skriv sedan ett test att lägga till (namn, avsikt, inputs, förväntat resultat). Om det finns kompromisser, redogör för dem."

Om output fortfarande känns fuzzy, spika det:

"Svara endast med: filväg, funktionsnamn, riskfylld rad och enmenings påverkan."

Ett realistiskt exempel: förvandla en aning till ett verifierat problem

Profiluppdaterings-endpoints döljer ofta åtkomstkontrollbuggar. Här är ett litet fall du kan gå igenom checklistan med.

Scenario: en API-endpoint uppdaterar en användarprofil:

PATCH /api/profile?accountId=123 med JSON som { "displayName": "Sam" }.

Du ber Claude Code hitta handlern, spåra hur accountId används och bevisa om servern upprätthåller ägarskap.

Vad som ofta dyker upp:

• Authn: förfrågan kräver session eller token, så den verkar skyddad.
• Authz: handlern litar på accountId från query-string och uppdaterar det kontot utan att kontrollera att det matchar inloggad användare.
• Indatavalidering: displayName trunkeras, men accountId valideras inte som ett heltal.
• Injektionsyta: SQL byggs med strängkonkatenering som "... WHERE account_id=" + accountId.

En bra rapport är konkret:

• Allvarlighetsgrad: Hög (IDOR + möjlig SQL-injektion)
• Bevis: en request med giltig inloggning ändrar en annan användare när accountId modifieras; SQL byggs från otillförlitlig input
• Fix: ignorera accountId från klienten, använd den autentiserade användarens account id på servern; parameterisera frågan
• Test: försök uppdatera ett annat konto och förvänta 403; avvisa icke-numeriskt accountId

Efter patch, kör snabben igen:

• Testa samma request med ett annat accountId och bekräfta att det misslyckas.
• Bekräfta att loggar visar att servern använder autentiserat id, inte query-param.
• Bekräfta att queryn använder placeholders/params, inte strängbyggnad.
• Kör ett negativtest för malformerad input (bokstäver, mycket stort nummer).

Vanliga fallgropar som gör att spot-checks missar riktiga problem

Det snabbaste sättet att missa en sårbarhet är att lita på vad UI:t verkar upprätthålla. En knapp som är dold eller inaktiverad är inte en behörighetskontroll. Om servern accepterar förfrågan ändå kan vem som helst spela upp den med ett annat användar-id, en annan roll eller en direkt API-anrop.

En annan vanlig miss är en vag förfrågan. "Gör en säkerhetsgranskning" ger oftast en generisk rapport. En spot-check behöver ett snävt scope (vilka endpoints, vilka roller, vilka data) och ett strängt outputformat (filnamn, funktion, riskfylld rad, minimalt repro).

Samma regel gäller för AI-output: acceptera inte påståenden utan pekare. Om ett fynd inte inkluderar en konkret kodplats och ett steg-för-steg-sätt att trigga det, behandla det som obekräftat.

Snabba sätt spot-checks spårar ur

Dessa fallgropar återkommer:

• Antar "endast admin" för att det är en admin-sida, inte för att servern upprätthåller det
• Begär breda granskningsresultat istället för "visa exakt request som kringgår X"
• Accepterar "möjlig SQL-injektion" utan query-konstruktionspunkt och input-path
• Hoppar över mindre uppenbara entrépunkter som webhooks, schemalagda jobb, importverktyg och interna admin-åtgärder
• Patchar symptom (lägger till filter eller regex) medan rotorsaken är saknad validering eller saknad auktorisation

Om du märker att du lägger till fler filter efter varje nytt edge case, pausa. Fixen är ofta tidigare och enklare: validera input vid gränsen och gör auktorisationskontroller explicita och centraliserade så att varje kodväg använder dem.

Snabba kontroller du kan köra innan du levererar

Dessa ersätter inte en fullständig granskning, men fångar misstag som smyger in när alla är trötta. Håll dem fokuserade på vad du kan bevisa snabbt: en request du kan skicka, en sida du kan ladda, en loggrad du kan hitta.

Fem snabba spot-checks som ofta lönar sig:

• Authn-friktion: Testa 10 misslyckade inloggningar i följd. Ser du rate limits, låsningar eller åtminstone en fördröjning? Kan du avgöra om en e-post finns från felmeddelanden eller tid?
• Authz genom ID-swap: Välj en verklig resurs (order, faktura, profil). Byt ID i URL:en, JSON-body eller GraphQL-variabler. Får du data som inte är din, även "bara metadata"?
• Indataguider: För nyckelfält (email, namn, sökning, filuppladdning) pröva mycket långa strängar, konstigt Unicode och oväntade typer (nummer istället för sträng). Tillämpas längdbegränsningar och allowlists där det spelar roll?
• Exponering av hemligheter: Sök i nyare loggar och klientpaket efter tokens, API-nycklar, JWTs eller "Authorization: Bearer". Kontrollera även fel-sidor. "Det var bara i staging" blir ofta "det levererades".
• Injektionsytor: Leta efter strängkonkatenering in i SQL, filter, template-rendering, shell-kommando eller redirect-URLs. Om input når någon av dessa utan stark validering, anta risk tills bevis visar motsatsen.

Skriv ner de tre främsta fixarna du kan leverera denna vecka, inte en önskelista. Exempel: (1) lägg till rate limiting för inloggning och lösenordsåterställning, (2) upprätthåll server-side ägarskapskontroller på "get by id"-endpointen, (3) begränsa inputlängd och avvisa oväntade tecken för sökfältet.

Nästa steg: gör denna checklista till en del av din byggprocess

En spot-check ger bara värde om resultaten förändrar vad ni levererar. Behandla denna checklista som ett litet, upprepningsbart byggsteg, inte en engångsinsats.

Gör varje fynd till en backlog-post som är svår att missförstå:

• Fix: vad som kommer ändras i kod eller konfig
• Test: hur du bevisar att det är fixat (en request, ett unit test, ett QA-steg)
• Ägare: en person ansvarig
• Mål datum: nästa release eller ett specifikt datum
• Bevis: fil/endpoint och exakt request eller payload som visade problemet

Välj en takt som matchar er risk och teamstorlek. För många team är varje release bäst. Om releaser är frekventa, gör en 30–60 minuters granskning månadsvis och en kortare kontroll innan leverans.

Gör det enklare att upprepa genom att skapa ett återanvändbart promptpaket och en checklistemall. Håll promptarna fokuserade på konkreta outputs: visa route, kontrollen, fallande request och förväntat beteende. Lagra paketet där teamet redan arbetar så det inte hoppas över.

Om du bygger appar via chat, baka in checklistan i planeringen. Lägg till en kort "säkerhetsantaganden"-not för authn/authz, input och hemligheter, och kör spot-checken direkt efter första fungerande version.

Plattformar som Koder.ai (koder.ai) kan passa bra med denna vana eftersom de låter dig iterera snabbt samtidigt som granskningens checkpoints bevaras. Att använda snapshots och rollback kring riskfyllda förändringar gör det enklare att leverera säkerhetsfixar utan att fastna när något går sönder.