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 endpoints 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
Even 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
Validate "content types" for incoming requests to your API
Reject requests that lack "content type", or contain unexpected "content type" values.
Respond to such requests with HTTP status codes:406 - "Unacceptable"
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
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
Make sure your APIs always sends correct HTTP response codes
Avoid the exposure of enpoints for administration on the internet
Be careful when handling errors
Reply with generic error messages - avoid exposing details about the error if its not neccessary
Do not give away technical details such as "call stacks" or internal information to the API-client