Files
recipe-app/filanalys.md
T
Nils-Johan Gynther d645d3ad9d
Test Suite / test (24.15.0) (push) Has been cancelled
Test Suite / flutter-quality (push) Has been cancelled
feat: add Flutter quality checks and tests for category chips in inventory and pantry screens
2026-05-12 16:13:10 +02:00

3.3 KiB

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

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.

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

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.