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

Retningslinjene er inspirert av dokumentet This document contains guidelines that will help you create and consume APIs in a secure way.

The guidelines are inspired by the document "OWASP cheat for REST Security" som finnes her which you can find here: 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.

...

General guidelines for securing REST based APIs

• Secure all endpoint using HTTPS. Among other things, this will protect Access Tokens that are transferred between HelseID and the API-klient, as well as between API-clients and API endpoints.

• Perform access control on every endpoint, event if the API is hidden behind an API Gateway.

• Require JWTs as security tokens.

• Restrict which HTTP methods that are used. Reject every HTTP methods that is not in use by responding with the HTTP status code 405 - "method not allowed"

• Valider alle inputparametre

  Aldri stol på input parametre, se gjerne på OWASP sitt

  Validate every input parameter

  • Never trust input parameters, take a look at the OWASP 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 detailed explanations

  • Validate the lenght of the input-value, valid ranges and values, format and type

  • All input parameters should be strongly typed

  • Do not accept unexpected or unknown content

  • Use libraries or framworks for validating and sanitizing input values

  • Define limits for data size in requests and reject requests that are too big by responding with the HTTP status code 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

  • Log errors that occur during input validation, consider implementing rules that temporarily ban API-clients that often fail.

• Validate "content types". Dersom du ikke validerer If you don’t validate "content type" åpner du for injisering og eksekvering av kodeyou open up for injecting and execution of code

  • 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

• SikkerhetsheadereSecurity headers

  • 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

...