Vad koden faktiskt gör

Kontrollerat mot koden 2026-09-16

1. Varje databasfråga passerar genom ett Prisma-tillägg som kopplar den till förfrågans organisation, och en fråga utan organisationskontext misslyckas i stället för att returnera rader.

2. TOTP-seeds och tokens från tredjepartsleverantörer lagras krypterade med AES-256-GCM, med en nyckelring som tillåter nyckelrotation utan att förlora åtkomst till befintliga data.

3. Varje HTML-svar får en Content-Security-Policy med en slumpmässig nonce per förfrågan, och ett inline-skript utan denna nonce körs inte.

4. Varje tillståndsändrande anrop med en personalsession måste skicka en CSRF-token som matchar cookien, och denna kontroll kan inte stängas av i produktion.

5. En länk till ett godkännandekvitto signeras med HMAC-SHA256, signaturen verifieras före varje databasläsning och alla fel returnerar samma 404-fel.

   En delningslänk är en slumpmässig token på 32 byte av vilken endast SHA-256-värdet lagras, med utgångstid, valfritt lösenord och omedelbar återkallelse; en återkallad, utgången eller okänd länk svarar med samma 404-fel.

6. Varje uppladdad fil skannas med ClamAV på en privat VM inom VPC innan någon visningskopia skapas av den, och en fil utan ett rent resultat hålls kvar och levereras inte.

   Filer över 2 GiB hålls kvar och skannas inte. En kvarhållen fil levereras inte.

7. En kund går in i kundportalen utan konto, med kod, länk, telefon eller e-post; endast en HMAC av koden eller token sparas, en ingång löper ut (30 dagar som standard), och en återkallelse kopplar bort varje enhet inom två minuter.

8. Aktivitetsloggen tillåter endast tillägg i applikationen: ingen kodväg uppdaterar eller raderar en granskningsrad, och en CI-grind misslyckas vid varje försök att lägga till en sådan kodväg.

9. Varje API-rutt är hastighetsbegränsad per användare eller klient-IP via en delad Redis-räknare över instanser; när Redis inte är tillgängligt sjunker gränsen till en tredjedel per instans i stället för att öppnas helt.

10. Sessionen är en signerad JWT-cookie (HS256) med HttpOnly, Secure och SameSite=Lax, löper ut efter två inaktiva timmar och kan återkallas på alla enheter samtidigt; lösenord lagras som scrypt-hashar och återställningskoder för MFA lagras endast som HMAC:er.

11. Kundportalen, delningslänkar, kvitton, sidan för att acceptera inbjudningar samt sidorna för slutförd registrering och återställning av lösenord har noindex, och robots.txt blockerar /api/, /admin, /app och /coupons.

12. En ägare av en arbetsyta kan exportera data och radera arbetsytan eller sitt eget konto utan att fråga oss; raderingen låser ute användaren omedelbart, och permanent radering sker automatiskt efter 30 dagar, vilket är det antal som anges i villkoren, integritetspolicyn och DPA.

13. Hemligheter monteras från Secret Manager vid driftsättning, valideras vid uppstart (minsta längd, platshållarvärden nekas, krypteringsnyckeln måste vara 32 slumpmässiga byte) och maskeras i loggar och felrapporter.

14. Schemalagda anrop autentiseras med en HMAC-SHA256-signatur inom ett tidsfönster på fem minuter eller en Google OIDC-token, och en statisk bearer-hemlighet nekas i produktion.

15. Varje utgående anrop till en användarangiven adress (Drive-importer, webhooks) kontrolleras mot privata adressintervall, inklusive efter omdirigeringar och vid anslutningstillfället.

16. En API-request-body är begränsad till 1 MiB och kontrolleras mot ett strikt schema som avvisar okända fält innan koden rör den.

17. Filtypen bestäms utifrån själva filinnehållet snarare än webbläsarens deklaration, och en fil som överskrider planens kvot eller gränsen per fil avvisas före uppladdning.

18. Varje objektsökväg kontrolleras mot organisationens prefix före signering, läsning eller radering, och filer levereras via tidsbegränsade signerade URL:er (6 timmar för visning, 5 minuter för nedladdning).

19. AI-förslag sparas som förslag och tillämpas först efter att en person godkänner dem, och AI-kod får inte öppna ett systemomfång över kunddata; en CI-grind tvingar fram detta.

20. Varje driftsättning passerar först hela testsviten med täckning, kodgrindarna och npm audit på nivån high; en produktionsdriftsättning går också igenom en canary med readiness-kontroller.