Als PO wil ik een strakkere specificatie van de validatieregels voor de response payload (outputvalidatie)

[CathyDingemanse]

...zodat de client de output beter kan valideren (betere outputvalidatie)
EN de kans op het hacken van de client als gevolg van een server hack kleiner wordt.

Threat type:

• Spoofing. Voordoen als iemand anders
• Tampering. Modificeren van data (in transit)
• Repudiation. Verwijderen van audit log
• Information Disclosure. Toegang tot data waarvoor niet is geautoriseerd
• Denial of Service. Beperken toegang tot data
• Elevation of Privilege. Toegang tot data waarvoor niet is geautoriseerd

Threat:
Te ruim gespecificeerde validatieregels voor eigenschappen van personen in de payload
Veel definities zijn niet-alfanummeriek. Nummers zijn soms ook niet-nummerieke karakters. Voorbeelden:

• de naam.geslachtsnaam is gespecificeerd als een string van maximaal 400 karakters
• de verblijfplaats.nummeraanduidingIdentificatie is gespecificeerd als een string van maximaal 16 karakters
  Dit maakt het mogelijk om SQL of scripts te injecteren in de payload van de response. Dit maakt bijvoorbeeld cross site scripting mogelijk, waarbij de client naar een andere site wordt geleid door bijvoorbeeld javascript in strings te accepteren.

Countermeasures
De specificatie moet clients de mogelijkheid bieden om de output zo veel mogelijk te valideren, door de validatieregels voor de response strakker te specificeren. Voorbeeld:

• naam.geslachtsnaam specificeren als een string van minimaal 3 en maximaal 100 van alleen de volgende karakters: a-zA-Z'- en diakrieten
• verblijfplaats.nummeraanduidingIdentificatie parameter specificeren als een string van precies 16 cijfers.