Sjekkliste for sikring av API-er

Dette dokumentet inneholder retningslinjer som kan hjelpe deg med å opprette og bruke APIer på en sikker måte. Dette dokumentet er et generelt dokument, og du bør alltid vurdere eventuelle andre sikkerhetsspørsmål relatert til ditt spesifikke domene og teknologi. Dette dokumentet er et supplement til sikkerhetsprofilen, som du alltid skal følge.

Retningslinjene nedenfor er inspirert av dokumentet "OWASP cheat for REST Security" som du kan finne på dette nettstedet.

Generelle retningslinjer for sikring av REST-baserte APIer

ℹ️  Sikre alle endepunkter med HTTPS

Dette vil blant annet beskytte Access-token som overføres mellom HelseID og API-klienten, samt mellom API-klienter og API-endepunkter.

ℹ️  Utfør tilgangskontroll på hvert endepunkt

Selv om APIet er skjult bak en API Gateway.

ℹ️  Krev JWT-er som Security-token

ℹ️  Begrens hvilke HTTP-metoder som brukes

Avvis alle HTTP-metoder som ikke er i bruk ved å respondere med HTTP-statuskode 405 - "Method Not Allowed".

ℹ️  Valider alle input-parametere

  • Stol aldri blindt på input-parametere, se 'OWASP Input Validation cheat sheet' for detaljerte forklaringer.
  • Valider lengden på input-verdien, gyldige områder og verdier, format og type.
  • Alle input-parametere bør være strengt typede.
  • Ikke aksepter uventet eller ukjent innhold.
  • Bruk biblioteker eller rammeverk for å validere og sanere input-verdier.
  • Definer grenser for datamengde i forespørsler og avvis forespørsler som er for store ved å respondere med HTTP-statuskoden 413 - "Request Entity Too Large".
  • Logg feil som oppstår under validering av inndata, vurder å implementere regler som midlertidig bannlyser API-klienter som ofte feiler.

ℹ️  Valider "content types"

Hvis du ikke validerer "content type", åpner du opp for injeksjon og utførelse av kode.

  • Valider "content types" for innkommende forespørsler til APIet ditt.

    • Avvis forespørsler som mangler "content type", eller inneholder uventede "content type"-verdier.
    • Svar på slike forespørsler med HTTP-statuskoder:
      • 406 - "Unacceptable"
      • 415 - "Unsupported Media Type"
    • Unngå å eksponere "content types" som ikke er i bruk ved å definere eksplisitte typer; med dette kan du unngå XXE-angrep (XML External Entity Attacks).

  • Bruk sikre "content types" i svar.

    • Ikke kopier "Accept"-headeren til "Content-type"-headeren i svaret.
    • Ikke aksepter forespørselen hvis "Accept"-headeren inneholder en type som ikke er tillatt.
    • Svar med HTTP-statuskode 406 - "Not Acceptable" hvis typen oppgitt i "Accept"-headeren ikke er tillatt.
    • Sørg for at "content type"-headerne i svarene dine samsvarer med innholdet i kroppen. Eksempel: application/json og ikke application/javascript.

ℹ️  Sikkerhetsheadere

  • Send "Content-Type"-headeren med korrekt type og tegnsett.
  • Send sikkerhetsheader "X-Content-Type-Options: nosniff" for å sikre at nettleseren ikke prøver å endre "Content-Type" til noe annet enn det som ble sendt (kan føre til XSS).
  • Send sikkerhetsheader "X-Frame-Options: deny" for å beskytte deg mot dra-og-slipp clickjacking i eldre nettlesere.

ℹ️  Korrekt bruk av CORS

Ved å levere passende CORS-headere, signaliserer REST APIet hvilke domener (opprinnelser) som har tillatelse 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 opprinnelser som er gyldige for kall på tvers av domener.

ℹ️  Sørg for at APIene dine alltid sender korrekte HTTP-responskoder

⚠️  Unngå eksponering av endepunkter for administrasjon på internett

⚠️  Vær forsiktig når du håndterer feil

  • Svar med generelle feilmeldinger - unngå å avsløre detaljer om feilen hvis det ikke er nødvendig
  • Ikke gi bort tekniske detaljer som "call stacks" eller intern informasjon til API-klienten