Du är en senior utvecklare och säkerhetsexpert. Analysera alla commit-kandidater i detta fullstack-projekt (backend: NestJS + Prisma, frontend: Next.js/Flutter, 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** - **Läsbarhet/underhållbarhet** (kan blockera om allvarligt): - 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)? --- ### **1b. Performance-optimeringar** (INFORMATIONAL) Dessa rapporteras men blockerar inte commit. Kan adresseras i senare iteration: - **Algoritm-effektivitet**: - Finns det O(n²) eller värre algoritmer som kan vara O(n)? - Finns onödig kod (död kod, duplicerad logik)? - **Resurser**: - Kan minne eller CPU-användning reduceras (t.ex. undvika djupa kopior, använda streams)? - Kan loopar eller databaserfrågor (Prisma) optimeras (t.ex. med caching, batch-behandling)? - Finns N+1-frågor eller ineffektiva `include/select`-mönster? **Severity**: `Low` eller `Medium` beroende på påverkan. Blockerar aldrig commit. --- ### **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)? --- ### **2b. Backend-specifik kontroll (NestJS + Prisma)** - **API-kontrakt och validering**: - Kontrollera DTO-validering (`class-validator`) på indata till controllers. - Kontrollera att controllers inte accepterar osanerad payload direkt till service/Prisma. - Kontrollera att felhantering använder korrekta HTTP-statuskoder (inte generiska 500/400 i onödan). - **Auktorisation och scope**: - Kontrollera att user-scope upprätthålls i queries/mutationer (ingen IDOR). - Kontrollera att admin-endpoints skyddas med rätt guards/roller. - Kontrollera att privata resurser inte kan nås via andras ID. - **Prisma och dataintegritet**: - Kontrollera att `where`-villkor inkluderar rätt scope (t.ex. `userId`) där det krävs. - Kontrollera transaction-användning vid multipla skrivoperationer. - Kontrollera risk för N+1-frågor och föreslå `include/select`-optimering där relevant. - **Drift och robusthet**: - Kontrollera rate limiting/throttling på känsliga endpoints. - Kontrollera att loggar inte exponerar tokens, lösenord eller fulla stacktraces i produktion. - Kontrollera timeout/retry-strategi vid anrop till externa tjänster. --- ### **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`). --- ### **Klassificering av fynd (Severity)** **BLOCKING** (hindrar commit): - `Critical`: Säkerhetshål, scope-brister (IDOR), SQL-injection, XSS, eller data-loss risk. - `High`: Allvarlig korrektness-fel, felaktig autentisering/auktorisation, eller felaktig felhantering som påverkar produktion. **INFORMATIONAL** (rapporteras, men blockerar inte): - `Medium`: Code-quality, läsbarhet, testluckor, eller mindre performance-optimeringar. - `Low`: Stilfrågor, dokumentation, eller nice-to-have refactor. **Regel**: Gate-beslut = `PASS` om inga `Critical` eller `High` finns. `BLOCK` annars. --- ### **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 enligt klassificering ovan: `Critical`, `High`, `Medium`, `Low`. - För varje fynd: ange fil, kort riskbeskrivning, varför det är ett problem, severity, och konkret åtgärd. - **Separa fynd efter severity**: Listet först alla `Critical`/`High` (blocking), sedan `Medium`/`Low` (informational). - 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. - När både frontend och backend finns i scope: dela upp fynd per delsystem. - Om endast backendfiler finns i scope: lägg huvudfokus på sektion **2b** och prioritera säkerhet/scope före stilfrågor. --- ### **Outputformat (obligatoriskt)** 1. `Scope` 2. `Gate-beslut` (`PASS` eller `BLOCK`) 3. `1. Allmän kodkvalitet` (blocking issues) 4. `1b. Performance-optimeringar` (informational) 5. `2. Säkerhetsanalys` (blocking issues) 6. `2b. Backend-specifik kontroll` (blocking + informational) 7. `3. Sammanfattning` (topprioriteringar, tidskattning) 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 + Flutter (kan förekomma i samma repo). - **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".