Le Guide API ReST | Marmicode
  • Le Guide API ReST par Marmicode
  • API ReST
    • L'Ecosystème Moderne
    • Le Besoin
    • Re.S.T. : REpresentational State Transfer
    • Les 5 règles et ½ de l’API ReST
    • Le Modèle de Maturité de Richardson
    • H.A.T.E.O.A.S. & Resource Linking
    • Avis Subjectif sur H.A.T.E.O.A.S. et le Semantic Web
    • ReST over HTTP
    • HTTP & CRUD
    • ReSTful donc Stateless
    • Pragmatisme, Idéologie et ReSTafarians
  • Conventions & Bonnes Pratiques
    • Nommage
    • Base URL
    • Media Type
    • Versioning
    • Propriété “id”
    • Polymorphisme
    • Datetime
    • Ressource d'Association
    • Pourquoi Appliquer ces Bonnes Pratiques
    • Zalando ReSTful API Guidelines
  • Les Outils
    • Swagger
    • OpenAPI Visual Editors
    • IDE Plugins
    • Postman
    • Insomnia
    • Fake & Sandbox
    • JSON Generator
    • Pact
  • Sécurité des APIs ReST
    • OWASP Top 10
    • Authentification et Session Management
    • Autorisation et Gestion des Permissions
    • Validation, Canonicalization, Escaping & Sanitization
    • Cookies are EVIL
    • C.O.R.S.
    • C.S.R.F.
    • C.S.R.F. & Media Type
    • C.S.R.F. Mitigation
    • C.S.R.F. & "Resource Linking"
    • J.O.S.E.
      • J.W.K.
      • J.W.S.
      • J.W.E.
    • J.W.T.
      • Description et Fonctionnement de JWT
      • Usages et Avantages
      • Utilisation de JWT pour l’Authentification
      • JWT, Authentification, Sessions et Risques Sécurité
      • Recommandations JWT
    • OAuth 2
      • OAuth 2 Roles
      • OAuth 2 Abstract Flow
      • OAuth 2 Authorization Code Flow
      • OAuth 2 Implicit Flow
      • OAuth 2 Resource Owner Password Credentials Flow
      • OAuth 2 Client Credentials
      • OAuth 2 Registration
      • OAuth 2 Risques & Recommandations
      • OAuth 2 Substitution Attack
    • OpenID Connect
      • Terminologie
      • Quoi de Neuf ?
      • OpenID Connect Flows
      • Que Faire ?
  • Autres Spécifications
    • JSON API
    • H.A.L.
    • JSON LD
    • Les Autres Initiatives
    • So What?
  • Quelques Liens & Ressources
  • Stay Tuned
    • 📝Blog
    • 🐦Twitter
    • 📬Newsletter
Propulsé par GitBook
Sur cette page
  1. Sécurité des APIs ReST

Autorisation et Gestion des Permissions

En fonction des credentials du client, les autorisations et permissions d’accès sur une ressource peuvent varier.

Une même ressource peut donc retourner des informations différentes en fonction du client. Cela ne transgresse pas les principes ReST.

Par exemple, pour la même ressource user, un rôle owner et un rôle friend n’auront pas accès aux mêmes opérations et propriétés :

Avec le rôle owner : GET /users/123

{
    "id": "123",
    "firstName": "John",
    "lastName": "DOE",
    "address": {
        "street": "...",
        ...
    }
}

Avec le rôle friend : GET /users/123

{
    "id": "123",
    "firstName": "John",
    "lastName": "DOE"
}

Les Trois Niveaux d'Autorisation

  1. Niveau ressource : autorisation d’accès à la ressource.

  2. Niveau verbe : méthodes autorisées sur la ressource (create / read / update / delete).

  3. Niveau propriété : gestion de l’autorisation par propriété (read / write / mask / restricted values per role). Ce dernier niveau est malheureusement souvent omis par la plupart des implémentations et frameworks d’API ReST.

Par exemple, la ressource post d’un blog peut avoir une propriété state pouvant prendre les valeurs suivantes : draft, private ou published.

Les utilisateurs avec le rôle administrator peuvent modifier cette propriété.

En revanche, les utilisateurs avec le rôle editor peuvent modifier toutes les autres propriétés sauf celle-ci.

Peu importe l’implémentation, les permissions doivent être faites à base de whitelist.

Séparez l'implémentation fonctionnelle et la gestion des permissions.

Pour respecter la separation of concerns, améliorer la scalability et faciliter l’implémentation et la compréhension de l’API ReST, il est recommandé d'implémenter la gestion des permissions sur un connecteur dédié.

Pour commencer, cette implémentation peut se faire dans un middleware du framework qui plus tard pourra être migré vers un service dédié ou une solution d'API management.

  • Ce connecteur est similaire aux A.C.L. (Access Control List) que l’on retrouve dans les filesystems ou sur les firewalls.

PrécédentAuthentification et Session ManagementSuivantValidation, Canonicalization, Escaping & Sanitization

Dernière mise à jour il y a 6 ans