Différences entre versions de « NF16616 — Sécurisation des API ⇒ identification par header pour sécuriser les attaques par CSRF. »
De Documentation Polaris
Ligne 4 : | Ligne 4 : | ||
Les API supportent l'identification par header, ce qui sécurise les attaques par CSRF. | Les API supportent l'identification par header, ce qui sécurise les attaques par CSRF. | ||
{{FinChapeau}} | {{FinChapeau}} | ||
− | Pour rendre les API plus résistantes aux attaques par CRSF, | + | Pour rendre les API plus résistantes aux attaques par CRSF, elles ont été transformées en '''API REST''', i.e. soumis à un verbe HTTP : |
* les lectures sur un GET | * les lectures sur un GET | ||
* les actions, écritures uniquement réservées à un PUT, POST, DELETE | * les actions, écritures uniquement réservées à un PUT, POST, DELETE |
Version du 20 novembre 2019 à 10:50
Voir la carte de la fonctionnalité : A classer
Les API supportent l'identification par header, ce qui sécurise les attaques par CSRF.
Pour rendre les API plus résistantes aux attaques par CRSF, elles ont été transformées en API REST, i.e. soumis à un verbe HTTP :
- les lectures sur un GET
- les actions, écritures uniquement réservées à un PUT, POST, DELETE
Un système a été mis en place permettant de préciser le verbe HTTP attendu :
- ANY (tous, comme actuellement, en obsolète pour assurer la transition)
- GET, POST, PUT, DELETE
A terme, le ANY doit disparaître.