Den første gangen jeg virkelig forstod hva sikkerhet betyr i praksis, var ikke da jeg leste om OWASP Top 10. Det var da jeg oppdaget at en API-rute i Nextbook lot hvem som helst hente en annen brukers data ved å endre en ID i URL-en. Teknisk sett fungerte alt perfekt. Funksjonelt var det en katastrofe.
Det øyeblikket endret hvordan jeg tenker om sikkerhet. Det er ikke en feature du legger til — det er en grunnleggende del av hvordan du designer et system.
Sikkerhet som systemtenkning
Mange utviklere, inkludert meg selv i starten, tenker på sikkerhet som en sjekkliste: HTTPS, hashede passord, input-validering. Hak av og gå videre. Men sikkerhet er ikke en sjekkliste — det er en tenkemåte.
Det handler om å stille spørsmålet: hva kan gå galt? Ikke bare i koden din, men i hele kjeden. Fra brukerens nettleser, gjennom API-et, inn i databasen, og tilbake. Hvert ledd er en potensiell svakhet.
Jeg lærte dette gradvis, og mye av det fra folk som hadde mer erfaring med backend-systemer enn meg. En samtale med en data engineer om hvordan RLS fungerer i PostgreSQL endret fundamentalt måten jeg strukturerer tilgangskontroll.
Row Level Security: Forsvar i dybden
RLS i Supabase ble et vendepunkt for meg. Konseptet er enkelt: i stedet for å stole på at applikasjonskoden din alltid sjekker tilganger riktig, definerer du regler direkte i databasen.
CREATE POLICY "Users can only see own data"
ON profiles FOR SELECT
USING (auth.uid() = user_id);Det geniale med dette er at det er et siste forsvarsverk. Selv om frontend-koden har en bug, selv om API-et glemmer å filtrere, returnerer databasen bare data brukeren har lov til å se.
I Nextbook bruker jeg RLS for alt som handler om brukerdata — kurs-påmeldinger, fremgang, leveringer. Applikasjonskoden har sin egen validering, men RLS sørger for at selv om noe glir gjennom, får ingen tilgang til data de ikke eier.
Det tok tid å forstå RLS ordentlig. De første policyene mine var for enkle — de dekket ikke edge cases som hva som skjer når en bruker er både student og kursskaper. Etter hvert lærte jeg å tenke gjennom alle rollene og tilstandene i systemet før jeg skriver en policy.
Audit trails: Tillit gjennom transparens
En annen ting jeg lærte fra mer erfarne utviklere: det er ikke nok å beskytte data. Du må også vite hvem som endret hva og når.
I Nextbook logger jeg alle endringer i data — når et kurs oppdateres, når en bruker registrerer seg, når tilganger endres. Ikke bare for debugging, men fordi brukere fortjener å vite hva som skjer med dataene deres.
Det handler om tillit. Hvis en kursskaper lurer på om noen har endret innholdet deres, kan jeg se det i audit-loggen. Hvis en student rapporterer at fremgangen deres ble nullstilt, kan jeg spore nøyaktig hva som skjedde.
Implementasjonen er en database-trigger som fanger opp alle endringer. Jeg fikk hjelp til å designe den riktig — det er en av de tingene der det lønner seg å spørre noen som har gjort det før, fordi detaljene (som SECURITY DEFINER på triggerfunksjoner) betyr mye for om det faktisk fungerer trygt.
Autentisering: Ikke oppfinn hjulet på nytt
Et av de beste rådene jeg fikk tidlig var: ikke bygg autentisering selv. Det høres kanskje ut som en svakhet å innrømme, men det er det motsatte — det er en sikkerhetsbeslutning.
Autentisering er et av de områdene der feil er dyrest og vanskeligst å oppdage. Feil i passord-hashing, token-håndtering, session-management eller MFA kan gi alvorlige konsekvenser uten at du merker det.
Derfor bruker jeg Supabase Auth for Nextbook. Ikke fordi jeg ikke forstår hvordan autentisering fungerer — men fordi et team som jobber med auth på heltid gjør det bedre enn jeg kan alene. Jeg forstår flyten, jeg kan konfigurere den, og jeg kan vurdere om den dekker behovene mine. Men implementasjonsdetaljene overlater jeg til spesialistene.
Det er en form for systemtenkning i seg selv: å vite hvilke deler av systemet du bør bygge selv, og hvilke du bør stole på andre for.
Hva jeg fortsatt lærer
Sikkerhet er et felt der du aldri er ferdig. Jo mer jeg lærer, jo mer innser jeg hvor mye jeg ikke vet. Og det er greit — poenget er ikke å vite alt, men å ha ydmykheten til å innse hva som krever ekstra oppmerksomhet.
Noen prinsipper jeg har landet på:
- Stol aldri på input. Valider alt som kommer utenfra — fra brukere, fra API-er, fra alt du ikke kontrollerer.
- Forsvar i dybden. Ikke stol på ett enkelt lag. RLS i databasen og validering i API-et og sjekker i frontend.
- Minst mulig tilgang. Gi brukere og tjenester bare tilgangen de trenger. Ikke mer.
- Spor endringer. Audit trails er ikke paranoia — de er profesjonalitet.
- Bruk etablerte løsninger. For kritiske ting som autentisering og kryptering, bruk verktøy bygget av spesialister.
Sikkerhet handler til syvende og sist om respekt for brukerne dine. De stoler på at du tar vare på dataene deres. Det ansvaret tar jeg på alvor — ikke fordi jeg er sikkerhetsekspert, men fordi jeg forstår hva som står på spill.