Regel: Följ Diggs API-profil och beakta deras SKA- och BÖR-krav vid utformning av REST-API:er. Använd version 1.1.0 av API-profilen (se nedan) kompletterat med avsteg och tillägg enligt denna anvisning.

Motivering: genom att följa Diggs profil när detta är möjligt uppnås en ökad linjering av API:er inom Svensk offentlig förvaltning över tid. Detta kommer sannolikt att leda till ökad kostnadseffektivitet för etablering av samverkan och även en ökad digitaliseringstakt överlag.

För att Diggs API-regler ska passa kontexten svensk välfärd ges nedan ett antal regler som förtydligar, kompletterar, eller ersätter regler i Diggs API-profil.

Regel: Ett API:s servicenivå SKA finnas tydligt beskrivet i en interoperabilitetsspecifikation.

Motivering: API-specifikationer kan tänkas återanvändas i flera olika tillämpningar och det är respektive tillämpning som kan avgöra vilka servicenivåer som behövs. Det innebär att servicenivån för samma API-specifikation kan skilja sig mellan tillämpningarna.

Regel: En offentlig identifierare för person eller organisation SKA INTE användas som del av URL-path.

Förtydligande: Med offentlig identifierare för person eller organisation avses personnummer, samordningsnummer och organisationsnummer.
URL-path är den del av URL:en som innehåller elementen api, version, resurs och eventuell identifierare. Query-parametrar ingår inte i URL-path.

Se även regel REST.04

Motivering: identifierare i URL-path hamnar med stor sannolikhet i loggfiler, vilket innebär att information som kan identifiera personer riskerar att bli åtkomliga för andra än personer som har rätt att ta del av informationen. Detta regleras även av GDPR som säger att personuppgifter ska skyddas så att inte obehöriga får tillgång till dem.

Regel: Diggs säkerhetsavsnitt SKA följas och BÖR kompletteras med OWASP’s REST Security-regler

Komplettering: Diggs regel SÄK.11 säger att refreshtoken SKALL användas. Detta gäller för mänskliga användare. Beträffande kommunikation maskin-till-maskin så KAN refreshtoken användas. Anledningen till att det inte är ett BÖR- eller SKA-krav är att värdet inte är så stort vid maskin-till-maskin-kommunikation eftersom det inte finns en slutanvändare som störs av en förnyelseprocess.

Motivering: både Digg och OWASP tillhandahåller information som syftar till att öka säkerheten för REST-API:er. OWASP’s information syftar till att vara en hjälp att hantera de risker som beskrivs i OWASP Top 10.

OWASP:s rekommendationer ändras i takt med omvärlden, och för att våra rekommendationer ska hålla över tid bör denna anvisning hänvisa till de aktuella rekommendationerna.

Regel: vid implementation SKA man överväga riskerna som beskrivs i OWASP Top 10. Man BÖR överväga att använda de verktyg som rekommenderas av OWASP för identifiera och åtgärda risker.

Motivering: för att minimera kända risker i implementationen bör OWASP Top 10 beaktas och validering bör göras för att få kunskap om i vilken grad dessa risker är åtgärdade.