Toutes les propriĂ©tĂ©s Ă©changĂ©es avec lâAPI ReST doivent ĂȘtre validĂ©es par lâAPI.
La validation doit Ă©galement ĂȘtre implĂ©mentĂ©e cĂŽtĂ© client pour Ă©viter les aller-retours inutiles.
LâAPI ReST doit convertir les donnĂ©es reçues vers leur forme canonique ou les rejeter.
Par exemple, les données suivantes :
{"firstName": "joHn","lastName": " DoE","url": "myWebsite.com"}
... peuvent ĂȘtre converties en :
{"firstName": "john","lastName": "doe","url": "https://mywebsite.com"}
Ce nâest pas Ă lâAPI ReST de gĂ©rer lâescaping du contenu.
Par exemple, sur un blog, le commentaire suivant est cohérent :
<img src="not-found" onerror=alert(1)>
Câest au client de gĂ©rer lâescaping est dâĂ©viter les attaques de type XSS.
La sanitization est un jeu dangereux qui consiste Ă retirer le contenu potentiellement malicieux.
Pour lâexemple prĂ©cĂ©dent, cela consisterait Ă retirer la partie onerror
:
<img src="not-found">
Mais encore une fois, il sâagit dâune problĂ©matique client.
La difficultĂ© est quâil est toujours possible de trouver des techniques pour bypass la sanitization. Certains en ont fait leur mĂ©tier đ http://n0p.net/penguicon/php_app_sec/mirror/xss.htmlâ