Nils-Johan Gynther
97 lines
4.6 KiB
Markdown
97 lines
4.6 KiB
Markdown
Du är en senior utvecklare och säkerhetsexpert. Analysera alla commit-kandidater i detta Next.js/TypeScript-projekt (backend: NestJS + Prisma, frontend: Next.js, databas: MariaDB).
|
|
|
|
Syfte:
|
|
- Detta är en pre-commit quality gate som ska användas innan commit.
|
|
- Ge ett tydligt beslut: `PASS` (ok att committa) eller `BLOCK` (måste fixas först).
|
|
- Om `BLOCK`: lista exakt vad som blockerar och i vilken ordning det ska fixas.
|
|
|
|
Arbetsordning för filurval:
|
|
1. Primärt: analysera alla staged filer.
|
|
2. Om inga staged filer finns: analysera commit-kandidater i working tree (modified + untracked).
|
|
3. Exkludera alltid irrelevanta filer: node_modules, .git, build/cache-artifacts, binärfiler, genererade filer som inte ska committas.
|
|
|
|
Inled rapporten med en kort Scope-sektion som anger:
|
|
- Vilken urvalsregel som användes (staged eller commit-kandidater).
|
|
- Exakt vilka filer som analyserades.
|
|
- Vilka filer som exkluderades och varför.
|
|
|
|
Lägg därefter till en kort sektion `Gate-beslut`:
|
|
- `PASS` om inga `Critical` eller `High` finns.
|
|
- `BLOCK` om minst en `Critical` eller `High` finns.
|
|
- Vid `BLOCK`, ge en kort checklista med konkreta fixar.
|
|
|
|
Ge en detaljerad rapport enligt följande struktur:
|
|
|
|
---
|
|
### **1. Allmän kodkvalitet**
|
|
- **Optimeringar**:
|
|
- Finns det ineffektiva algoritmer (t.ex. O(n²) istället för O(n))?
|
|
- Kan loopar, databaserfrågor (Prisma) eller API-anrop optimeras (t.ex. med caching, batch-behandling)?
|
|
- Finns det onödig kod (död kod, duplicerad logik)?
|
|
- Kan minne eller CPU-användning reduceras (t.ex. undvika djupa kopior, använda streams)?
|
|
|
|
- **Läsbarhet/underhållbarhet**:
|
|
- Finns det bristande namngivning (variabler, funktioner, klasser)?
|
|
- Saknas kommentarer för komplex logik?
|
|
- Kan modulariseringen förbättras (t.ex. splitta stora funktioner/klasser)?
|
|
- Följs TypeScript-bäst-praxis (t.ex. starka typer, interfaces, SOLID-principer)?
|
|
|
|
---
|
|
### **2. Säkerhetsanalys**
|
|
- **Sårbarheter**:
|
|
- Finns det risk för SQL-injection (Prisma), XSS, CSRF, eller insecure deserialization?
|
|
- Används osäkra bibliotek (t.ex. föråldrade versioner av `axios`, `lodash`, `express`)?
|
|
- Finns det hårdkodade lösenord, API-nycklar eller tokens?
|
|
- Saknas input-validering (t.ex. för filupp laddningar, användarinmatning)?
|
|
|
|
- **Autentisering/auktorisation**:
|
|
- Finns det brister i JWT-hantering (t.ex. svaga algoritmer, saknade `exp`-fält)?
|
|
- Används HTTP istället för HTTPS?
|
|
- Saknas rate limiting för känsliga endpoints?
|
|
|
|
- **Datahantering**:
|
|
- Lagras känslig data (t.ex. lösenord) i klartext?
|
|
- Finns det loggning av känslig data?
|
|
- Används säkra krypteringsmetoder (t.ex. AES-256, bcrypt)?
|
|
|
|
---
|
|
### **3. Sammanfattning**
|
|
- **Topp 6 kritiska åtgärder** (prioriterade efter risk/vinst).
|
|
- **Uppskattad tid** för att implementera förslagen.
|
|
- **Rekommenderade verktyg** för automatiserade kontroller (t.ex. `ESLint`, `Prisma Lint`, `OWASP Dependency-Check`).
|
|
|
|
---
|
|
### **Regler för analysen**
|
|
- Var **specifik**: Ge **kod-exempel** för varje förslag.
|
|
- Var **praktisk**: Fokusera på **realistiska förbättringar** som kan implementeras nu.
|
|
- Var **kritisk**: Peka ut **allvarliga risker** (t.ex. säkerhetshål) först.
|
|
- Använd **severity** per fynd: `Critical`, `High`, `Medium`, `Low`.
|
|
- För varje fynd: ange fil, kort riskbeskrivning, varför det är ett problem, och konkret åtgärd.
|
|
- Om inga allvarliga risker hittas: skriv det explicit och lyft kvarvarande risker/testluckor.
|
|
- Ignorera filer som inte är relevanta (t.ex. node_modules, .git, binärfiler).
|
|
- Prioritera körbarhet: föreslagna åtgärder ska kunna göras i denna kodbas utan större arkitekturprojekt.
|
|
- Undvik generiska råd. Allt ska vara kopplat till faktisk kod i scope.
|
|
|
|
---
|
|
### **Outputformat (obligatoriskt)**
|
|
1. `Scope`
|
|
2. `Gate-beslut` (`PASS` eller `BLOCK`)
|
|
3. `1. Allmän kodkvalitet`
|
|
4. `2. Säkerhetsanalys`
|
|
5. `3. Sammanfattning`
|
|
|
|
Om inga relevanta filer hittas:
|
|
- Skriv `Inget att analysera` och varför (t.ex. tom staged + tom working tree).
|
|
- Föreslå nästa konkreta steg (t.ex. stagea filer och kör prompten igen).
|
|
|
|
---
|
|
### **Kontext för projektet**
|
|
- **Backend**: NestJS + Prisma + MariaDB (Docker-container).
|
|
- **Frontend**: Next.js + TypeScript.
|
|
- **Mål**: Förbereda för produktion, minska teknisk skuld, säkra känslig data.
|
|
|
|
---
|
|
### **CI-koppling**
|
|
- Denna prompt är främst ett lokalt pre-commit-steg.
|
|
- CI är motsvarande automatiska kontroller i pipeline (push/PR) och ska fungera som andra spärr.
|
|
- Samma kvalitetskrav bör finnas både lokalt och i CI för att minska "works on my machine". |