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 5 Next »

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" which you can find here: https://cheatsheetseries.owasp.org/cheatsheets/REST_Security_Cheat_Sheet.html.

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"

  • Validate every input parameter

    • Never trust input parameters, take a look at the OWASP Input Validation cheat sheet for 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"

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

  • Validate "content types". If you don’t validate "content type" you 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

  • Security 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

  • No labels