説明
全体のsecurity配列に空の要件オブジェクト{}があると、認証なしのアクセスも選択肢になります。要件は一つを満たせばよいため、ほかの項目で認証を指定しても必須にはなりません。一方、security: {}のように項目自体をオブジェクトにすると、配列を要求するOpenAPIの形式に適合しません。
想定される影響
共通の認証を必須にする意図でも、このポリシーを使う操作は匿名アクセスも許可するものとして記載されます。クライアントとサーバーのアクセス方針が食い違うおそれがあります。
対処方法
認証が必須の場合は配列内の空のオブジェクトを削除し、定義済みの認証方式だけを参照してください。security自体は配列でなければならないため、security: {}は無効な形式です。公開アクセスを許可するかどうかは、実際のサービスのポリシーに基づいて判断してください。
例
次の例では空の要件をexampleSecurityによるAPIキー認証に置き換えます。サーバー側でも同じ認証ポリシーを適用してください。
変更前
json
{
"openapi": "3.0.0",
"paths": {
"/": {
"get": {
"responses": {
"200": {
"description": "ok"
}
}
}
}
},
"security": [
{}
],
"info": {
"title": "Simple API overview",
"version": "1.0.0"
},
"components": {
"securitySchemes": {
"exampleSecurity": {
"type": "apiKey",
"in": "header",
"name": "X-API-Key"
}
}
}
}
変更後
json
{
"openapi": "3.0.0",
"paths": {
"/": {
"get": {
"responses": {
"200": {
"description": "ok"
}
}
}
}
},
"security": [
{
"exampleSecurity": []
}
],
"info": {
"title": "Simple API overview",
"version": "1.0.0"
},
"components": {
"securitySchemes": {
"exampleSecurity": {
"type": "apiKey",
"in": "header",
"name": "X-API-Key"
}
}
}
}