Security Academy→Course→Security mindset
Modul 1 / 12

Security mindset

Kartlegg appen som en reviewer: komponenter, data, tillitsgrenser og angrepsflate.

Tenk i tillitsgrenser, ikke i skjermbilder

En generert app ser ferdig ut i preview, men sikkerheten avgjøres av hvor data krysser en grense: browser → API, API → database, server → ekstern tjeneste.

Alt på klientsiden av en grense er kontrollert av brukeren. Alt som kommer derfra er input, også headere, cookies, skjulte felt og JSON.

diagram
  [ Browser ]  <- brukeren kontrollerer alt her
       |  HTTPS  (trust boundary #1)
  [ API / server functions ]  <- må autentisere + autorisere
       |  (trust boundary #2)
  [ Database + RLS ]   [ Storage ]   [ Eksterne API-er ]
       ^ service-role nøkler skal ALDRI over grense #1

Kartlegg disse delene

For hver del: hvem kan nå den, hva stoler den på, og hva skjer hvis den lyver?

  • ›Frontend: ruter, skjulte UI-elementer, klientlogikk som tar sikkerhetsbeslutninger
  • ›Backend / API: alle endpoints og server functions, også de UI-et ikke bruker
  • ›Database: tabeller, RLS-policies, views, funksjoner (SECURITY DEFINER)
  • ›Authentication: hvordan identitet etableres og hvor lenge den varer
  • ›Authorisation: hvor sjekkes eierskap og rolle — på server eller bare i UI?
  • ›Storage: buckets, offentlige URL-er, hvem kan liste/skrive
  • ›Secrets: hvilke nøkler finnes, hvor lever de, når roteres de
  • ›External services: webhooks, betaling, e-post, AI-API-er
  • ›Deployment: miljøvariabler, preview vs prod, headers, domener

Mini threat model (15 minutter)

Fyll ut én linje per asset. Det er nok til å prioritere testingen.

ASSET          | HVEM SKAL HA TILGANG    | TRUSSEL                    | KONTROLL
---------------|-------------------------|----------------------------|-------------------------
projects       | eier + inviterte        | IDOR: les andres prosjekt  | RLS: owner_id = auth.uid()
user_roles     | kun admin skriver       | bruker gjør seg til admin  | ingen INSERT/UPDATE policy
uploads bucket | eier                    | gjette URL / liste filer   | privat bucket + signed URLs
STRIPE_SECRET  | kun server              | lekker i JS-bundle         | process.env i server fn
/api/webhook   | kun Stripe              | forfalsket event           | signaturverifisering
Kontroller i din egen app

Quiz

Scenario 1

Appen har en server function getInvoice(id) som bare kalles fra fakturasiden (som krever login). Funksjonen sjekker ikke session. Er det et problem?

Scenario 2

Hva er den viktigste trust boundary i en typisk Lovable-app?