Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 4 Next »

Dette dokumentet inneholder retningslinjer som vil hjelpe utviklere med å lage og konsumere API på en sikker måte.

Retningslinjene er inspirert av dokumentet "OWASP cheat for REST Security" som finnes her : https://cheatsheetseries.owasp.org/cheatsheets/REST_Security_Cheat_Sheet.html.

Generelle retningslinjer for sikring av REST baserte API

  • Sikre alle endepunkt med HTTPS. Dette vil blant annet beskytte Access Tokens som overføres mellom HelseID og API-klient, og API-klient og API endepunkter.

  • Utfør tilgangskontroll på hvert endepunkt, selv om APIet skjuler seg bak en API Gateway.

  • Krev bruk av JWTs som sikkerhetsbillett.

  • Begrens hvilke HTTP metoder som er i bruk. Avslå alle HTTP metoder som ikke er i bruk ved å svare med HTTP statuskode 405 - "method not allowed"

  • Valider alle inputparametre

    • Aldri stol på input parametre, se gjerne på OWASP sitt Input Validation cheat sheet for mer detaljerte forklaringer

    • Valider input-verdiens lengde, gyldige verdier, format og type

    • Alle inputparametre skal ha sterk typing

    • Ikke godta uventet eller ulovlig innhold

    • Bruk bibliotek eller rammeverk for vasking av inputverdier

    • Definer grenser for aksepterte datamengder i forespørsler og avslå forespørsler som er for store ved å svare med HTTP statuskode 413 - "Request Entity Too Large"

    • Loggfør feil som oppstår i forbindelse med inputvalidering, vurder om regler som låser ute klientapplikasjoner som feiler for ofte implementeres bør implementeres

  • Valider "content types". Dersom du ikke validerer "content type" åpner du for injisering og eksekvering av kode

    • Valider "content types" for innkommende kall til ditt API

      • Avslå innkommende kall som enten mangler "content type", eller som inneholder "content type" verdier som ikke er forventet. Svar på slike forespørsler med HTTP statuskode 406 - "Unacceptable" eller 415 - "Unsupported Media Type".

      • Unngå uforvarende eksponering av content types som ikke er bruk ved å definere eksplisitte content types. Ved å  gjøre dette unngås angrep ved XXE.

    • Svar med trygge content types

      • IKKE kopier "Accept" header til "Content-type" headeren til responsen

      • Ikke godta forespørselen dersom "Accept" headeren ikke inneholder en av de tillatte typene. Svar med HTTP statuskode 406 - "Not Acceptable" dersom typen angitt i "Accept" headeren ikke er tillatt.

      • Sørg for at "content type" headere i din response stemmer overens  med innholdet i body.- F.eks application/json og ikke application/javascript

  • Unngå eksponering av endepunkt for administrasjon via internett

  • Vær varsom med feilhåndtering

    • Svar med generiske feilmeldinger - unngå å avsløre detaljer om feilsituasjonen dersom det ikke er nødvendig

    • Ikke vis tekniske detaljer som "call stacks" eller intern informasjon  til klientapplikasjonen

  • Sikkerhetsheadere

    • Send "Content-Type" headeren med riktig content type og charset.

    • Send sikkerhetsheaderen "X-Content-Type-Options: nosniff" for å sikre at nettleseren ikke forsøker å sette en annen Content-Type enn det som faktisk ble sendt (dette kan føre til XSS).

    • Send sikkerhetsheaderen "X-Frame-Options: deny" for å beskytte mot "drag'n drop clickjacking" angrep i eldre nettlesere

  • Riktig bruk av CORS. Ved å levere passende CORS headere signaliserer REST APIet ditt hvilke domener (origins) som har lov til å gjøre JavaScript kall til REST-tjenesten

    • Deaktiver CORS headere hvis kall på tvers av domener ikke støttes eller forventes

    • Vær så spesifikk som mulig, og så generell som nødvendig når du definerer hvilke origins som er gyldige for kall på tvers av domener

  • Sørg for at dine API alltid sender riktige HTTP response koder

  • No labels