Claude Code beveiligingschecklist voor snelle controles van webapps

Wat een lichte beveiligings-spotcheck is

Een lichte beveiligings-spotcheck is een snelle review (vaak 30–60 minuten) bedoeld om voor de release zichtbare, hoog-impact problemen te vinden. Het is geen volledige audit. Zie het als een veiligheidsrondgang: je scant de paden die in echte apps het vaakst falen en zoekt naar bewijs, niet naar gissingen.

Deze Claude Code beveiligingschecklist richt zich op de gebieden die in dagelijkse webapps het vaakst misgaan:

• Authenticatieveronderstellingen (hoe je weet wie de gebruiker is)
• Autorisatielekken (wat ze mogen doen)
• Invoervalidatie
• Geheimenbeheer
• Veelvoorkomende injectieoppervlakken (SQL, commando-executie, template-rendering, redirects, uploads)

Hij probeert niet de afwezigheid van bugs te bewijzen, complexe dreigingsactoren te modelleren of penetratietesten te vervangen.

"Concrete bevindingen" betekent dat elk probleem dat je noteert bewijs bevat waar een ontwikkelaar direct mee aan de slag kan. Voor elke bevinding leg je vast:

• De exacte bestands(zen) en functienaam/handler
• Het risicovolle gedrag in één zin
• Een minimale repro-stap (request, payload of klikpad)
• Waarom het belangrijk is (impact) en wie het kan triggeren
• Een veilige oplossingsrichting (geen complete herschrijving)

AI is een helper, geen autoriteit. Gebruik het om te zoeken, samen te vatten en tests voor te stellen. Verifieer daarna door de code te lezen en, waar mogelijk, te reproduceren met een echt request. Als het model geen specifieke locaties en stappen kan aanwijzen, behandel de claim dan als onbewezen.

Scope bepalen in 10 minuten

Een snelle review werkt alleen als je het doel versmalt. Voordat je Claude Code iets laat bekijken, beslis wat je vandaag probeert te bewijzen en wat je niet controleert.

Begin met 1 tot 3 echte gebruikersroutes waarbij fouten geld kosten, gegevens blootstellen of macht geven. Goede kandidaten zijn inloggen, wachtwoordherstel, checkout en admin-bewerkingsschermen.

Benoem vervolgens de assets die je moet beschermen. Wees specifiek: gebruikersaccounts, betaalacties, persoonlijke data, admin-only bewerkingen.

Schrijf daarna je dreigingsaannames in gewone taal op. Verdedig je tegen een nieuwsgierige gebruiker die rondklikt, een externe aanvaller met scripts of een insider met beperkte toegang? Je antwoord verandert wat "goed genoeg" betekent.

Definieer ten slotte pass en fail zodat je spot-check eindigt met bevindingen, niet met een gevoel. Eenvoudige regels werken goed:

• Pass: elke gevoelige actie toont een expliciete authn- en authz-check.
• Fail: een endpoint vertrouwt op de client voor gebruikers-id of rol.
• Pass: invoer wordt server-side gevalideerd, niet alleen in de UI.
• Fail: geheimen verschijnen in logs, configs of clientcode.

Als je niet kunt beschrijven hoe falen eruitziet, is de scope nog te vaag.

Bereid de context voor die je Claude Code geeft

Een spot-check werkt alleen als het model naar de juiste plekken kijkt. Verzamel een klein pakket code en notities zodat de review bewijs kan leveren, geen gissingen.

Begin met het delen van het security-kritieke pad: request-entrypoints en de code die bepaalt wie de gebruiker is en wat ze mogen doen. Voeg net genoeg omliggende code toe om te laten zien hoe data stroomt.

Een praktisch pakket bevat meestal:

• Auth-entry: sessie/JWT-parsing, cookie-instellingen, login-callbacks, auth-middleware
• Routes + handlers: controllers, RPC-methoden, GraphQL-resolvers, achtergrondjob-handlers
• Datalayer: ORM-queries, raw SQL-helpers, query-builders, migraties voor gevoelige tabellen
• Policy-checks: rolchecks, eigendomschecks, featureflags, admin-only endpoints
• Validatie: request-schema-validators, file upload-handlers, deserialisatiecode

Voeg een paar regels omgevingsnotities toe zodat aannames expliciet zijn: sessie versus JWT, waar tokens leven (cookie of header), reverse proxy of API-gateway gedrag, queues/cron workers en eventuele "internal-only" endpoints.

Vraag eerst om een inventaris: entrypoints, geprivilegieerde endpoints en datastores die worden geraakt. Dit voorkomt gemiste oppervlakken.

Kom ook overeen welk outputformaat concrete bevindingen afdwingt. Een simpele tabel werkt goed: Bevinding, Ernst, Getroffen endpoint/bestand, Bewijs (exact fragment of regelbereik), Exploit-scenario, Oplossingssuggestie.

Stapsgewijze workflow voor een 30–60 minuten review

Timebox het:

• 10 minuten om te oriënteren
• 15–30 minuten om flows te volgen
• 10 minuten om te schrijven

Het doel is geen perfecte dekking. Het is een kleine set testbare bevindingen.

Houd de app open terwijl je leest. Klik door de UI en bekijk welke requests worden gestuurd. Notities moeten naar specifieke endpoints, parameters en gegevensbronnen verwijzen.

Een workflow die in één zitting past:

1. Schets entrypoints en trust-boundaries. Noteer publieke routes, ingelogde routes, admin-routes, webhooks, uploads en third-party callbacks. Markeer waar data van gebruiker-gecontroleerd naar server-vertrouwd overgaat.
2. Voor elk belangrijk endpoint, noteer wat identiteit bewijst en waar dat gebeurt. Als de check in "middleware" zit, bevestig dat elke route die middleware ook echt gebruikt.
3. Doe hetzelfde voor autorisatie. Kies één risicovolle actie (andere gebruikersdata bekijken, rollen updaten, exporteren, verwijderen) en traceer de permissiebeslissing helemaal tot aan de databasequery.
4. Volg gebruikersinvoer naar sinks. Volg één parameter van request naar SQL/ORM-queries, template-rendering, command-executie, URL-fetches (SSRF), redirects en bestands-paden.
5. Scan geheimen en configuratiestromen terwijl je traceert. Zoek tokens in logs, client-side code, foutmeldingen en environment dumps.

Een nuttige gewoonte: voor elke "lijkt prima", beschrijf hoe je het zou breken. Als je geen poging kunt beschrijven om te breken, heb je het waarschijnlijk niet echt geverifieerd.

Authn spot-checks: bewijs wie de gebruiker is

Authenticatie is waar de app beslist: "dit request behoort tot deze persoon." Een snelle spot-check gaat niet over elke regel lezen. Het gaat om het vinden van de plek waar identiteit wordt vastgesteld en het controleren van shortcuts en faalwegen.

Lokaliseren van de trust-boundary: waar wordt identiteit eerst gemaakt of geaccepteerd? Het kan een sessiecookie, een JWT-bearer-token, een API-sleutel of mTLS aan de edge zijn. Vraag Claude Code om het exacte bestand en de functie aan te wijzen die "anonymous" in een user-id omzet, en om alle andere paden te noemen die hetzelfde kunnen doen.

Authn-checks die het waard zijn te scannen:

• Identificeer alle auth-entrypoints (weblogin, API-tokens, mobiele auth, interne service-auth) en bevestig dat ze samenkomen in één consistent identiteitsmodel.
• Controleer login en wachtwoordreset op rate limits, lockouts en user-enumeratie (verschillende foutmeldingen of timing voor bestaande vs niet-bestaande accounts).
• Inspecteer sessies en cookies: HttpOnly, Secure, SameSite, vervaltatum, rotatie bij login en privilege-wijziging, en logout-invalidering (server-side, niet alleen "cookie verwijderen").
• Review MFA en recovery zodat het recovery-pad niet zwakker is dan MFA (bijv. e-mail-only reset die MFA omzeilt).
• Review auth-foutlogging: nuttig voor ops, maar lek geen details die aanvallers helpen (geen "user bestaat" hints, geen token-dumps).

Een praktisch voorbeeld: als reset-mails "account niet gevonden" teruggeven, is dat snel een enumeratieprobleem. Zelfs met een generiek bericht kunnen timingverschillen hetzelfde lekken, dus controleer ook responstijden.

Authz spot-checks: bewijs dat de gebruiker toestemming heeft

Autorisatie is de vraag die de meeste schade veroorzaakt als het fout is: "Mag deze gebruiker deze actie op precies deze resource uitvoeren?" Een snelle spot-check moet proberen die aanname doelbewust te doorbreken.

Schrijf rollen en permissies in gewone taal. Houd het menselijk:

• Eigenaar kan leden uitnodigen
• Lid kan zijn/haar eigen profiel bewerken
• Support kan factureringsgegevens bekijken maar geen plan wijzigen
• Admin kan projecten verwijderen

Verifieer daarna dat elke gevoelige actie authz server-side afdwingt, niet alleen in de UI. Knoppen kunnen verborgen zijn, routes kunnen in de client geblokkeerd zijn, maar een aanvaller kan nog steeds direct de API aanroepen.

Een snelle scan die meestal echte issues vindt:

• Vind endpoints/mutaties die creëren, verwijderen, exporteren, rollen wijzigen of facturering openen
• Voor elk endpoint, lokaliseer de server-side permissiecheck (niet de frontend)
• Zoek naar gebruikers-gestuurde IDs (projectId, userId, orgId) en bevestig eigendomschecks
• Bevestig dat admin-only paden dichtvallen als de rol ontbreekt
• Controleer tenant-grenzen: orgId/accountId moet uit de sessiecontext komen, niet alleen uit request-input

De klassieke IDOR-geur is simpel: een request zoals GET /projects/{id} waarbij {id} door de gebruiker wordt geleverd en de server het laadt zonder te verifiëren dat het bij de huidige gebruiker of tenant hoort.

Een prompt die een echt antwoord afdwingt:

"Voor dit endpoint, laat de exacte code zien die toegang beslist, en noem de specifieke voorwaarden die het mogelijk zouden maken dat een gebruiker van een andere orgId het kan benaderen. Als er geen zijn, leg uit waarom met bestands- en functienamen."

Invoervalidatie: houd slechte data buiten de deur

De meeste snelle webapp-issues beginnen met een kloof: de app accepteert invoer die de ontwikkelaar niet verwacht. Beschouw "invoer" als alles wat een gebruiker of een ander systeem kan beïnvloeden, ook als het onschuldig lijkt.

Begin met het benoemen van de inputs voor het endpoint dat je spot-checkt:

• URL-query- en padwaarden
• Request-bodyvelden (inclusief geneste JSON)
• Headers (auth-headers, content-type, forwarded IP)
• Cookies
• Bestandsuploads (naam, grootte, type, metadata)

Validatie moet gebeuren dicht bij waar data de app binnenkomt, niet diep in de businesslogica. Controleer de basis: type (string vs nummer), maximale lengte, verplicht vs optioneel en formaat (e-mail, UUID, datum).

Voor bekende waarden zoals rollen, statusvelden of sorteer-richtingen heeft een allowlist de voorkeur. Dat is moeilijker te omzeilen dan het blokkeren van een paar slechte waarden.

Controleer ook foutafhandeling. Als de app invoer afwijst, echo niet de ruwe waarde terug in de response, logs of UI. Zo veranderen kleine validatiebugs in datalekken of hulpjes voor injecties.

Een snelle "foute invoer" mini-plan voor risicovolle endpoints (login, search, upload, admin-acties):

• Te lange strings (10.000+ tekens)
• Verkeerde types (array in plaats van string)
• Onverwachte enumwaarden
• Speciale tekens die betekenis kunnen veranderen
• Lege waarden voor verplichte velden

Voorbeeld: een sort-parameter die elke string accepteert kan later een SQL-fragment worden. Een allowlist zoals "date" of "price" voorkomt die foutklasse vroeg.

Veelvoorkomende injectieoppervlakken om snel te scannen

De meeste snelle reviews vinden issues op dezelfde plekken: overal waar gebruikersinvoer wordt geïnterpreteerd als code, query, pad of URL. Dit is het gedeelte waarin je zoekt naar momenten waarop "invoer een trust boundary kruist".

Traceer data van entrypoints (query params, headers, cookies, uploads, admin-formulieren) naar waar het eindigt.

Snel te scannen doelen

Let op deze patronen en eis een concreet callsite en payloadvoorbeeld voor elk:

• SQL-injectie: string-gebouwde queries, dynamische ORDER BY, en IN (...) builders die user-waarden samenvoegen
• XSS: HTML-rendering, templates, markdown-previews, rich text editors waar "later sanitizen" wordt aangenomen
• Command-injectie: shell-calls rond imageprocessing, PDF-tools, backups of "convert"-stappen die user-gecontroleerde flags doorgeven
• SSRF: URL-fetchers voor webhooks, linkpreviews, import-from-URL features en interne checks die een gebruikers-URL accepteren
• Path traversal: bestands-download endpoints, zip-extractie en upload-pijplijnen die later bestanden op naam teruglezen

Let ook op deserialisatie en template-injectie. Alles wat user-provided JSON, YAML of templated strings parset kan risicogedrag verbergen, vooral als het custom types, expressies of server-side rendering ondersteunt.

Als een feature een URL, bestandsnaam of geformatteerde tekst accepteert, ga er vanuit dat het kan worden misbruikt totdat je het met codepaden en tests kunt bewijzen.

Geheimenbeheer: vind lekken en zwakke opslag

Problemen met geheimen zijn vaak luid zodra je weet waar je moet kijken. Richt je op waar geheimen leven en waar ze per ongeluk gekopieerd kunnen worden.

Veelvoorkomende plekken waar geheimen verschijnen:

• Omgevingsvariabelen en app-configbestanden
• CI-output en build-logs (inclusief mislukte deploy-logs)
• Client-bundles en mobile builds (alles wat naar gebruikers wordt gestuurd)
• Debug-endpoints, health-pagina's en admin-tools
• Foutpagina's, stacktraces en analytics-events

Vervolgens dwing je een concreet antwoord af: als een geheim vandaag wordt blootgesteld, wat gebeurt er dan? Een goed systeem heeft een rotatiepad (nieuwe sleutel uitgegeven), intrekking (oude sleutel uitgeschakeld) en een manier om snel opnieuw te deployen. Als het antwoord is "we veranderen het later", behandel dat dan als een bevinding.

Least privilege is een andere snelle winst. Incidenten worden erger omdat sleutels te machtig zijn. Zoek naar databasegebruikers die tabellen kunnen droppen, third-party tokens die accounts kunnen beheren of API-keys die over omgevingen gedeeld zijn. Geef de voorkeur aan één sleutel per service, per omgeving met de kleinste set permissies.

Snelle spot-check prompts die je in Claude Code kunt plakken:

• "Zoek naar hard-coded tokens, wachtwoorden en private keys. Noem exacte bestandslocaties en de stringpatronen die je matchte."
• "Vind code die request-headers, cookies, env vars of volledige foutobjecten logt. Laat de logregels zien en welke gevoelige velden kunnen verschijnen."
• "Controleer of geheimen in snapshots, exports of build-artifacts kunnen terechtkomen. Identificeer wat wordt vastgelegd en waar het wordt opgeslagen."

Bevestig tot slot guardrails: blokkeer geheimen in source control (pre-commit/CI checks) en zorg dat backups of snapshots geen platte-tekst referenties bevatten. Als je platform snapshots en rollback ondersteunt, verifieer dan dat geheimen runtime worden geïnjecteerd en niet in baked images zitten.

Prompts die concrete bevindingen afdwingen (copy-paste patronen)

Vage prompts leveren vage antwoorden. Dwing het model om zich te committeren aan bewijs: exacte locaties, een trace die je kunt volgen, een repro die je kunt draaien en wat de claim fout zou maken.

Gebruik één patroon per keer en vraag het daarna te reviseren nadat je een detail bevestigd of afgewezen hebt.

• Bestandsniveau-bewijs: "Doorzoek de repo naar auth, sessions, tokens en middleware. Noem de exacte bestanden, functies en regelbereiken die betrokken zijn. Quote de relevante snippets. Als je geen code kunt aanwijzen, zeg dan 'no evidence found'."
• Trace van input naar sink: "Kies één user-controlled input (header, query, body, cookie). Laat de dataflow stap-voor-stap zien van entrypoint tot waar het wordt gebruikt (SQL, HTML, shell, template, redirect, bestandsnaam). Noem elke functie in de keten."
• Repro-stappen: "Geef een minimale repro met curl (methode, URL-vorm, headers, body). Inclusief verwacht statuscode en een voorbeeld van succes/falen response. Noem aannames (rollen, auth-state)."
• False-positive controle: "Wat zou deze bevinding weerleggen? Noem 2–3 checks: configflags, middleware-order, allowlist-validatie, geparametriseerde queries, framework-escaping. Als een van deze aanwezig is, leg uit waarom het risico wijzigt."
• Kleinste veilige fix + test: "Stel de kleinste wijziging voor die het probleem blokkeert zonder geldige gevallen te breken. Schrijf vervolgens één test om toe te voegen (naam, intentie, inputs, verwacht resultaat). Als er trade-offs zijn, licht ze toe."

Als de output nog steeds vaag voelt, maak het concreet:

"Antwoord alleen met: bestandslocatie, functienaam, risicovolle regel en een één-zin impact."

Een realistisch voorbeeld: van vermoeden naar geverifieerd probleem

Profile-update endpoints verbergen vaak toegangscslechtere controleproblemen. Hier is een klein geval om door deze checklist te lopen.

Scenario: een API-endpoint werkt een gebruikersprofiel bij:

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

Je vraagt Claude Code de handler te vinden, te traceren hoe accountId wordt gebruikt en te bewijzen of de server eigendom afdwingt.

Wat er vaak naar boven komt:

• Authn: het request vereist een sessie of token, dus het lijkt beschermd.
• Authz: de handler vertrouwt accountId uit de querystring en werkt dat account bij zonder te controleren of het overeenkomt met de ingelogde gebruiker.
• Invoervalidatie: displayName wordt getrimd, maar accountId wordt niet gevalideerd als integer.
• Injectie-oppervlak: SQL wordt opgebouwd met stringconcatenatie zoals "... WHERE account_id=" + accountId.

Een goede write-up is concreet:

• Ernst: Hoog (IDOR + mogelijke SQL-injectie)
• Bewijs: een request met een geldige login verandert een andere gebruiker wanneer accountId wordt aangepast; SQL wordt gebouwd uit onbeheerde input
• Oplossing: negeer accountId van de client; gebruik op de server de geauthenticeerde gebruikers-id; parameteriseer de query
• Test: probeer een ander account bij te werken en verwacht 403; verworpen niet-numerieke accountId

Na patchen, controleer snel opnieuw:

• Probeer hetzelfde request met een ander accountId en bevestig dat het faalt.
• Bevestig dat logs laten zien dat de server de geauthenticeerde id gebruikt, niet de queryparam.
• Bevestig dat de query placeholders/params gebruikt in plaats van string-building.
• Voer een negatieve test uit voor malafide invoer (letters, zeer groot nummer).

Veelvoorkomende valkuilen waardoor spot-checks echte issues missen

De snelste manier om een kwetsbaarheid te missen is te vertrouwen op wat de UI afdwingt. Een knop die verborgen of uitgeschakeld is, is geen permissiecheck. Als de server het request toch accepteert, kan iedereen het replayen met een andere gebruikers-id, rol of direct API-call.

Een andere veelvoorkomende miss is een vage opdracht. "Doe een security review" levert meestal een generiek rapport. Een spot-check heeft een strakke scope nodig (welke endpoints, welke rollen, welke data) en een strikt outputformaat (bestandsnaam, functie, risicovolle regel, minimale repro).

Dezelfde regel geldt voor AI-output: accepteer geen claims zonder aanwijzingen. Als een bevinding geen concrete codelocatie en een stapsgewijze trigger bevat, behandel het als onbewezen.

Snelle manieren waarop spot-checks fout gaan

Deze valkuilen komen steeds terug:

• Ervan uitgaan dat iets "admin-only" is omdat het een adminpagina is, en niet omdat de server het afdwingt
• Vragen om brede reviewresultaten in plaats van "laat het exacte request zien dat X omzeilt"
• "Mogelijke SQL-injectie" accepteren zonder waar de query wordt opgebouwd en welke input het pad volgt
• Minder voor de hand liggende entrypoints overslaan zoals webhooks, geplande jobs, importtools en interne admin-acties
• Symptomen patchen (een filter of regex toevoegen) terwijl de oorzaak ontbrekende validatie of ontbrekende autorisatie is

Als je jezelf betrapt op het steeds toevoegen van filters voor elke nieuwe edge-case, pauzeer. De fix zit meestal eerder en eenvoudiger: valideer invoer aan de grens en maak autorisatiechecks expliciet en gecentraliseerd zodat elk codepad ze gebruikt.

Snelle checks die je kunt doen voordat je uitbrengt

Deze vervangen geen volledige review, maar vangen fouten die insluipen als iedereen moe is. Houd ze gericht op wat je snel kunt bewijzen: een request dat je kunt sturen, een pagina die je kunt laden, een logregel die je kunt vinden.

Vijf snelle spot-checks die meestal lonen:

• Authn-frictie: Probeer 10 foutieve logins achter elkaar. Zie je rate limits, lockouts of op zijn minst vertraging? Kun je aan foutmeldingen of timing zien of een e-mail bestaat?
• Authz door ID-wissel: Pak een echte resource (bestelling, factuur, profiel). Verander het ID in de URL, JSON-body of GraphQL-variabelen. Krijg je data die niet van jou is, ook al is het alleen metadata?
• Input guardrails: Voor sleutelvelden (e-mail, naam, zoekveld, file upload) probeer zeer lange strings, vreemde Unicode en onverwachte types (nummer in plaats van string). Handhaaf je lengtebeperkingen en allowlists waar nodig?
• Geheimenblootstelling: Doorzoek recente logs en client-bundles naar tokens, API-keys, JWTs of "Authorization: Bearer". Controleer ook foutpagina's. "Het stond alleen in staging" wordt vaak "het werd meegeleverd".
• Injectieoppervlakken: Zoek naar stringconcatenatie in SQL, filters, template-rendering, shell-commando's of redirect-URL's. Als invoer ongebonden een van deze bereikt zonder stevige validatie, ga ervan uit dat er risico is totdat het tegendeel bewezen is.

Schrijf de top 3 fixes op die je deze week kunt uitrollen, geen wenslijst. Voorbeeld: (1) voeg rate limiting toe aan login en wachtwoordreset, (2) dwing server-side eigendomschecks af op het "get by id" endpoint, (3) zet inputlengtegrenzen en weiger onverwachte karakters voor het zoekveld.

Volgende stappen: maak deze checklist onderdeel van je buildproces

Een spot-check betaalt zich alleen uit als de resultaten veranderen wat je uitbrengt. Zie deze checklist als een kleine, herhaalbare buildstap, niet als een eenmalige reddingsactie.

Zet elke bevinding om in een backlog-item dat moeilijk verkeerd te interpreteren is:

• Fix: wat er in code of config verandert
• Test: hoe je aantoont dat het gefixt is (één request, één unittest, één QA-stap)
• Eigenaar: één verantwoordelijke
• Doeldatum: volgende release of een concrete dag
• Bewijs: bestand/endpoint en het exacte request of payload die het probleem toonde

Kies een cadans die past bij je risico en teamgrootte. Voor veel teams is elke release ideaal. Als releases frequent zijn, doe dan maandelijks een 30–60 minuten review en een kortere check vóór het uitbrengen.

Maak het herhalen makkelijker door een herbruikbare prompt-pack en een checklist-template te maken. Houd prompts gefocust op concrete outputs: laat de route zien, de guard, het falende request en het verwachte gedrag. Sla de pack op waar je team al werkt zodat hij niet wordt overgeslagen.

Als je apps bouwt via chat, veranker de checklist in de planning. Voeg een korte "security assumptions" notitie toe voor authn/authz, inputs en geheimen, en voer de spot-check uit direct na de eerste werkende versie.

Platforms zoals Koder.ai (koder.ai) passen goed bij deze gewoonte omdat ze snelle iteratie mogelijk maken terwijl review-checkpoints behouden blijven. Gebruik van snapshots en rollback rond risicovolle wijzigingen maakt het eenvoudiger om beveiligingsfixes uit te rollen zonder vast te lopen wanneer iets anders breekt.