recipe-app/filanalys.md

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

• 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)?

---

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).

---

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.
• 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
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 + 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".