You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Bij het CIBG (min. VWS) baseren we onze API's op de Logius standaarden. In dat kader zoeken we naar een standaard uitwerking van de /transport/no-sensitive-uris: No sensitive information in URIs regel, als onderdeel van de Transport Security ADR module.
Zover we hebben kunnen nagaan is er geen informatief stuk opgenomen over hoe een API gevoelige parameters zou kunnen ondersteunen.
Als jullie dit relevant achten voor een vermelding in de API standaarden dan leggen we hierbij graag onze uitwerking neer zodat deze kan worden meegenomen in een aankomend overleg.
Voorstel:
Gebruik een POST body voor gevoelige query en pad parameters
Houd gevoelige parameters uit de URL volgens /transport/no-sensitive-uris. Gebruik hiervoor een HTTP POST met een application/x-www-form-urlencoded body en met /get en /query als pad suffix om het onderscheid met de POST op de collectie te maken.
Voorkom een mix van query en body parameters, met deze opzet moeten alle niet gevoelige parameters ook in de body komen. Een request met query parameters in de URL moet een 400 Bad Request teruggeven.
Get resource by ID
Onveilig: GET /personen/123456782
Veilig: POST /personen/get Content-Type: application/x-www-form-urlencoded id=123456782 (body)
Deze "get by ID" moet een enkel object terug geven. Overige parameters, naast het id, in de body zouden genegeerd moeten worden. Wel kunnen er parameters worden meegegeven om bijvoorbeeld de velden in het response te beperken zoals ook mogelijk had geweest bij een GET op de resource, zoals bijvoorbeeld id=123456782&fields=naam,geboortedatum.
Query on collection
Onveilig: GET /[email protected]
Veilig: POST /personen/query Content-Type: application/x-www-form-urlencoded [email protected] (body)
Deze "query op de collectie" moet een array teruggeven. Voorbeeld van een combinatie van gevoelige en niet gevoelige parameters in de body: [email protected]&status=actief
Bij het CIBG (min. VWS) baseren we onze API's op de Logius standaarden. In dat kader zoeken we naar een standaard uitwerking van de
/transport/no-sensitive-uris: No sensitive information in URIs
regel, als onderdeel van de Transport Security ADR module.Zover we hebben kunnen nagaan is er geen informatief stuk opgenomen over hoe een API gevoelige parameters zou kunnen ondersteunen.
Als jullie dit relevant achten voor een vermelding in de API standaarden dan leggen we hierbij graag onze uitwerking neer zodat deze kan worden meegenomen in een aankomend overleg.
Voorstel:
Gebruik een POST body voor gevoelige query en pad parameters
Houd gevoelige parameters uit de URL volgens /transport/no-sensitive-uris. Gebruik hiervoor een HTTP POST met een
application/x-www-form-urlencoded
body en met/get
en/query
als pad suffix om het onderscheid met de POST op de collectie te maken.Voorkom een mix van query en body parameters, met deze opzet moeten alle niet gevoelige parameters ook in de body komen. Een request met query parameters in de URL moet een 400 Bad Request teruggeven.
Get resource by ID
Onveilig:
GET /personen/123456782
Veilig:
POST /personen/get
Content-Type: application/x-www-form-urlencoded
id=123456782
(body)Deze "get by ID" moet een enkel object terug geven. Overige parameters, naast het
id
, in de body zouden genegeerd moeten worden. Wel kunnen er parameters worden meegegeven om bijvoorbeeld de velden in het response te beperken zoals ook mogelijk had geweest bij een GET op de resource, zoals bijvoorbeeldid=123456782&fields=naam,geboortedatum
.Query on collection
Onveilig:
GET /[email protected]
Veilig:
POST /personen/query
Content-Type: application/x-www-form-urlencoded
[email protected]
(body)Deze "query op de collectie" moet een array teruggeven. Voorbeeld van een combinatie van gevoelige en niet gevoelige parameters in de body:
[email protected]&status=actief
Referenties:
https://cwe.mitre.org/data/definitions/598.html
The text was updated successfully, but these errors were encountered: