Herdet applikasjonen med nonce‑basert CSP, HSTS, SameSite‑informasjonskapsler, databaseroller etter prinsippet om minste privilegium og ny kontroll av tilgangsrettigheter på serversiden.

Situasjon. Plattformen inneholder faglige og organisatoriske data, den typen folk forventer blir håndtert ordentlig, så én enkelt forsvarslinje kom aldri til å være nok. Arbeidsantakelsen må være at klienten er fiendtlig — at den som sitter med nettleseren, kan slå av alt nettleseren håndhever — og sikkerheten må holde likevel.

Oppgave. Plattformen måtte herdes i hvert lag — frontend, API, database — slik at sikkerheten ble håndhevet av serveren uavhengig av hva grensesnittet tilfeldigvis tillot.

Handling. I frontenden setter proxy‑mellomvaren i Next.js — proxy.ts — en Content‑Security‑Policy med en nonce per forespørsel og strict‑dynamic, i tillegg til HSTS og SameSite‑cookies, så nettleseren er låst ned med tanke på hva den vil kjøre og sende. I API‑et finnes hastighetsbegrensning, CORS, grenser for forespørselsstørrelse, inndatavalidering før noe rører databasen, og logging av sikkerhetsrelevante hendelser. I databasen logger API‑et inn som en rolle med minst mulig rettigheter, som bare har EXECUTE på appfunksjonene, funksjonene kjører som SECURITY DEFINER, og alt er parameterisert. Og rettighetene — abonnementsnivå, rolle, organisasjon, avgrensning per skip — kontrolleres på nytt på serveren ved hver forespørsel, og sperrene i frontenden behandles bare som UX. Sperrene avgjør hva man ser; serveren avgjør hva man kan gjøre.

Resultat. Sikkerheten er ikke avhengig av at brukergrensesnittet oppfører seg. Beskyttelsene ligger i lag, slik at den som kommer forbi én, ikke dermed kommer forbi resten, og det hele bygger på antakelsen om at klienten ikke kan stoles på — som er den riktige antakelsen for data folk deler i fortrolighet.