Tous les produits
Search
Centre de documentation

Edge Security Acceleration:Validation de la conformité des schémas d'API

Dernière mise à jour :Aug 12, 2026

Importez un schéma d'API, tel qu'une spécification OpenAPI. ESA l'associe automatiquement à vos API gérées, valide les requêtes entrantes par rapport à ce schéma et applique l'action configurée aux requêtes non conformes.

Fonctionnement

La validation de schéma s'applique à toute API gérée via la gestion des API ESA.

image
  1. Lorsqu'une requête atteint un nœud ESA, ESA vérifie si elle concerne une API gérée :

    • Dans le cas contraire, ESA transmet la requête aux autres fonctionnalités de sécurité.

    • Si c'est le cas, ESA associe la requête au schéma d'API correspondant.

  2. ESA valide ensuite la requête par rapport au schéma :

    • Si la requête est non conforme, ESA applique l'action configurée et journalise l'événement.

    • Si la requête est conforme, ESA autorise son passage.

Configurer la validation de schéma

Pour utiliser la validation de schéma, importez un schéma et activez la fonctionnalité.

  1. Dans la console ESA, choisissez Websites, puis cliquez sur le site web cible dans la colonne Website.

  2. Dans le volet de navigation de gauche, choisissez Security > API Security.

  3. Sur la page API Security, sélectionnez l'onglet Schema Validation, puis cliquez sur Schema Validation Settings.image

  4. Sur la page des paramètres, cliquez sur Upload Schema pour importer votre fichier de schéma personnalisé.image

  5. ESA associe automatiquement vos API gérées aux définitions du schéma importé. Après avoir vérifié les correspondances, cliquez sur OK.image

  6. Une fois le schéma importé, configurez une action par défaut pour les requêtes non conformes. Nous vous recommandons de commencer par l'action Monitor. Activez ensuite le commutateur Status.image

  7. Retournez à l'onglet Schema Validation pour consulter les résultats de la validation de schéma.image

Analyser les requêtes non conformes

Une fois la validation de schéma configurée, ESA surveille en continu les requêtes API. Dans l'onglet Schema Validation, cliquez sur l'icône de filtre image dans la barre d'outils de la liste des API et sélectionnez un schéma pour filtrer la liste. La colonne Non-compliant requests affiche le nombre de requêtes non conformes sur les dernières 24 heures.image

Les requêtes non conformes peuvent résulter des problèmes suivants :

  • Erreurs côté client : Des clients légitimes peuvent envoyer des requêtes mal formées, par exemple avec un format de paramètre incorrect (données de formulaire au lieu de JSON), des paramètres obligatoires manquants ou des incompatibilités de type (une chaîne de caractères pour un champ booléen). Vérifiez la conception de votre interface frontale et ajoutez une validation des entrées ainsi que des messages d'erreur pour prévenir ces problèmes.

  • Attaques malveillantes : Les attaquants envoient souvent des requêtes mal formées pour tester des vulnérabilités d'injection ou forcer le système. Une augmentation soudaine des requêtes non conformes peut indiquer une attaque en cours. Si vous soupçonnez une attaque, modifiez l'action pour la définir sur Block et configurez des règles WAF plus strictes.

Analyser les détails des requêtes

Pour identifier la cause racine des requêtes non conformes, examinez les journaux échantillonnés dans Events ou Security Analytics.

  1. Identifiez d'abord une API présentant un nombre anormal de requêtes non conformes.image

  2. Choisissez la fonctionnalité de journalisation appropriée selon l'action configurée :

    • Action définie sur None : Ces requêtes ne déclenchant aucune action de sécurité, analysez-les dans Security Analytics.

    • Action définie sur Monitor ou Block : Ces requêtes déclenchant une action de sécurité, vous trouverez plus facilement les journaux associés dans Events.

  3. Cette section prend Events comme exemple. Dans le volet de navigation de gauche, choisissez Security > Events.

    Pour utiliser Security Analytics, choisissez Security > Security Analytics dans le volet de navigation de gauche.
  4. Sur la page Events, faites défiler jusqu'à la section Sampling Logs. Filtrez les journaux correspondant aux règles API Security. Cliquez sur l'icône de développement image en regard d'une entrée de journal pour afficher ses détails et analyser la requête. Vous pouvez également utiliser Real-time Log pour une analyse plus détaillée des journaux d'accès.

Modifier l'action

Configurez une action par défaut pour toutes les API ou définissez une action spécifique pour des API individuelles.

  • Modifier l'action par défaut globale : Dans l'onglet Schema Validation, cliquez sur Change dans la colonne Default Action et sélectionnez une action :

    • Block : Bloque la requête non conforme et enregistre l'événement.

    • Monitor : Autorise le passage de la requête non conforme et enregistre l'événement.

    • None : Aucune action n'est effectuée.

    image

  • Configurer une action pour une API spécifique : Dans la liste des API de l'onglet Schema Validation, cliquez sur Change Action pour l'API souhaitée et sélectionnez une action :

    • Default : Utilise l'action par défaut globale.

    • Block : Bloque la requête non conforme et enregistre l'événement.

    • Monitor : Autorise le passage de la requête non conforme et enregistre l'événement.

    • None : Aucune action n'est effectuée.

      image

Analyser les API sans schéma

Après l'importation d'un fichier de schéma, les API conformes y sont automatiquement associées. Dans l'onglet Schema Validation, sous la colonne APIs without Schema, cliquez sur le bouton Filter pour afficher la liste des API sans schéma.image

En l'absence de schéma, ESA ne peut pas comptabiliser les requêtes non conformes, ce qui crée une faille de sécurité potentielle. Une API peut manquer de schéma pour les raisons suivantes :

  • Omission dans le schéma : L'API n'a pas été incluse dans le fichier de schéma importé. Vérifiez le chemin de l'API, l'hôte et la méthode HTTP, puis mettez à jour et réimportez le fichier de schéma.

  • Conception d'API non standard : L'API ne suit pas les pratiques de conception standard, ce qui empêche sa correspondance avec le schéma. Un refactoring de l'API peut être nécessaire. Les problèmes courants incluent :

    • Chemin non standard : Le chemin de l'API est incorrect. Par exemple, l'entrée paths correcte est /users, mais elle est définie comme /user.

    • Méthode HTTP mal utilisée : La méthode ne respecte pas les conventions sémantiques. Par exemple, l'utilisation de la méthode GET pour une action destructive comme /users/delete/123 au lieu de DELETE.

    • Abus de codes d'état : Le code d'état de réponse de l'API est incorrect. Par exemple, toutes les réponses retournent 200 OK, et l'état réel est renvoyé dans le corps de la réponse, tel que { "responses": "500" }.

    • Structure d'E/S confuse : Les données d'entrée ou de sortie sont incorrectes. Par exemple, un champ email qui devrait se trouver en entrée est placé par erreur en sortie.

Spécifications du fichier de schéma

Type et taille

Les fichiers de validation de schéma doivent être au format .yml, .yaml ou .json. La taille maximale du fichier est de 58 Ko. Si votre fichier de schéma dépasse cette limite, utilisez le format .json et compressez le fichier localement avant de l'importer.

Contenu du schéma

Version

La validation de schéma ESA prend uniquement en charge la spécification OpenAPI (OAS) v3.0.x.

Champs

Champs obligatoires

  • openapi : La version de l'API, par exemple 3.0.0.

  • info : Métadonnées concernant l'API, telles que "version": "1.0.0".

  • paths : Doit contenir au moins un chemin d'API, par exemple /api.

  • servers : Informations sur l'hôte. Les sous-champs suivants sont pris en charge :

    • url : Seules les URL absolues sont prises en charge, par exemple https://api.example.com.

    • variables : ESA ne prend pas en charge les variables de serveur. Les espaces réservés aux variables sont ignorés lors de l'analyse.

Champs facultatifs

  • schema : Définition de la structure des données. Les types suivants sont pris en charge :

    • int32

    • uint32

    • int64

    • uint64

    • float

    • double

    • boolean

    • email

  • reference : Utilise $ref pour référencer un objet prédéfini. Les références externes ou relatives ne sont pas prises en charge.

  • requestBody : Définit le corps de la requête. Seules les données avec un content-type de application/json sont prises en charge.

Exemple

Voici un exemple de fichier de schéma .json.
{
    "openapi": "3.0.0",
    "info": {
        "title": "example",
        "description": "example",
        "version": "1.0"
    },
    "servers": [
    {
      "url": "https://example1.aliyun.com",
      "description": "example1 url"
    },
    {
      "url": "https://example2.aliyun.com",
      "description": "example2 url"
    }
    ],
    "components": {
        "schemas": {
            "ParamsObject": {
                "type": "object",
                "properties": {
                    "id": {
                        "type": "integer"
                    },
                    "value": {
                        "type": "string"
                    }
                },
                "required": [
                    "id",
                    "value"
                ]
            }
        }
    },
    "paths": {
        "/example/{param1}": {
            "get": {
                "operationId": "getexampleById",
                "parameters": [
                    {
                        "name": "param1",
                        "in": "path",
                        "required": true,
                        "description": "id",
                        "schema": {
                            "type": "integer",
                            "format": "int32"
                        }
                    }
                ]
            }
        },
        "/api1": {
            "post": {
                "operationId": "post_api1",
                "summary": "post api1 request",
                "parameters": [],
                "requestBody": {
                    "required": true,
                    "content": {
                        "application/json": {
                            "schema": {
                                "$ref": "#/components/schemas/ParamsObject"
                            }
                        }
                    }
                }
            },
            "get" :{
                "operationId": "get_api1",
                "summary": "get api1 request",
                "parameters": [
                    {
                        "name": "id",
                        "in": "query",
                        "required": true,
                        "schema": {
                            "type": "integer",
                            "format": "int32"
                        }
                    },
                    {
                        "name": "name",
                        "in": "query",
                        "required": false,
                        "schema": {
                            "type": "string"
                        }
                    }
                ]
            }
        }
    }
}