You can use Postman to identify any potential security and formatting issues when defining your API.
For all APIs defined in OpenAPI 3.0 and 3.1, the following list describes possible warning messages and potential ways to resolve them.
Issue description | Possible fix |
---|---|
The OAuth2 scopes used in the global security field need to be defined in the security schemes field. Otherwise, an attacker can introduce their scopes to fill the gap and exploit the system. | Make sure that all the OAuth2 scopes used are defined in the OAuth2 security scheme. |
security:
- OAuth2:
- read
- write
components:
securitySchemes:
OAuth2:
type: oauth2
flows:
authorizationCode:
scopes:
read: read objects in your account
write: write objects to your account
Issue description | Possible fix |
---|---|
The OAuth2 scopes used in the security field of the operation need to be defined in the security schemes field. Otherwise, an attacker can introduce their scopes to fill the gap and exploit the system. | Make sure that all the OAuth2 scopes used are defined in the OAuth2 security scheme. |
paths:
/user:
get:
summary: 'Sample endpoint: Returns details about a particular user'
operationId: listUser
security:
- OAuth2:
- read
- write
components:
securitySchemes:
OAuth2:
type: oauth2
flows:
authorizationCode:
scopes:
read: read objects in your account
write: write objects to your account
Issue description | Possible fix |
---|---|
If the global security field isn't defined, the API doesn't require any authentication by default. Anyone can access the API operations that don't have a security field defined. | The security field needs to be defined in the schema. |
openapi: 3.0.0
info:
paths:
security:
- testAuth : []
Issue description | Possible fix |
---|---|
If the security field has an empty array, no security scheme is applied to the operations by default. | The security field needs to have at least one item in the array. |
openapi: 3.0.0
info:
paths:
security:
- testAuth : []
Issue description | Possible fix |
---|---|
An empty object in the security field deactivates the authentication. Without security fields defined for each operation, anyone can access the API operations without any authentication. | Security field array items can't have an empty object. |
openapi: 3.0.0
info:
paths:
security:
- testAuth : []
Issue description | Possible fix |
---|---|
The components object of the API doesn't declare any security schemes which can be used in the security field of the API or individual operations. | Security schemes need to be defined in the schema of the component. |
components:
securitySchemes:
testAuth:
type: http
scheme: basic
Issue description | Possible fix |
---|---|
An empty object in the reusable security schemes means that no authentication scheme is defined for each operation, anyone can access the API operations without any authentication. | Security schemes need to have at least one item in the object. |
components:
securitySchemes:
BasicAuth:
type: http
scheme: basic
Issue description | Possible fix |
---|---|
The authentication scheme used in global or operation security field isn't defined in the security scheme object. | The scheme used in the security field needs to be defined in the security scheme object. |
components:
securitySchemes:
BasicAuth:
type: http
scheme: basic
#...
security:
- BasicAuth: []
Issue description | Possible fix |
---|---|
The name of the HTTP authentication scheme must be registered in the IANA Authentication Scheme registry. | Make sure that the HTTP authentication scheme registered in the IANA Authentication Scheme registry is used. |
servers:
- url: https://my.server.example.com/
description: API server
#...
components:
securitySchemes:
myAuth:
type: http
scheme: basic
#...
security:
- myAuth: []
Issue description | Possible fix |
---|---|
No security scheme is applied to the API operation by default. | The security field in any operation needs to have at least one item in the array. |
openapi: 3.0.0
info:
title: Example API
version: '1.0'
paths:
/user:
get:
security:
- BasicAuth : []
responses:
default:
description: Example
components:
securitySchemes:
BasicAuth:
type: http
scheme: basic
Issue description | Possible fix |
---|---|
An empty object in the security field deactivates the authentication for the operation. Anyone can access the API operation without any authentication. | Specify at least one security requirement in the operation. |
openapi: 3.0.0
info:
title: Example API
version: '1.0'
paths:
/user:
get:
security:
- BasicAuth : []
responses:
default:
description: Example
components:
securitySchemes:
BasicAuth:
type: http
scheme: basic
Issue description | Possible fix |
---|---|
If both the global security field and operation's security field aren't defined, anyone can access the API without any authentication. | Define a security field in the operation. |
openapi: 3.0.0
info:
title: Example API
version: '1.0'
paths:
/user:
get:
security:
- BasicAuth : []
responses:
default:
description: Example
components:
securitySchemes:
BasicAuth:
type: http
scheme: basic
Issue description | Possible fix |
---|---|
The access tokens are sent as plain text over an unencrypted network. Attackers can intercept the access tokens by listening to the network traffic in a public Wi-Fi network. | Make sure that the server URL is a valid URL and uses HTTPS protocol. |
servers:
- url: https://my.api.example.com/
description: API server
# ...
components:
securitySchemes:
OAuth2:
type: oauth2
# ...
security:
- OAuth2:
- write
- read
Issue description | Possible fix |
---|---|
The credentials are sent as plain text over an unencrypted network. Attackers can intercept the access tokens by listening to the network traffic in a public Wi-Fi network. | Make sure that the server URL is a valid URL and uses HTTPS protocol. |
components:
securitySchemes:
OpenIdScheme:
type: openIdConnect
openIdConnectUrl: https://example.com/connect
paths:
'/pets':
post:
operationId: addPet
servers:
- url: https://example.com/
description: API server
security:
- OpenIdScheme: []
Issue description | Possible fix |
---|---|
The authentication tokens are sent as plain text over an unencrypted channel. Attackers can intercept the token by listening to the network traffic in a public Wi-Fi network. | Make sure that the server URL is a valid URL and uses HTTPS protocol. |
servers:
- url: https://my.api.example.com/
description: API server
#...
components:
securitySchemes:
OAuth1:
type: http
scheme: oauth
#...
security:
- OAuth1: []
Issue description | Possible fix |
---|---|
API keys are sent as plain text over an unencrypted channel. Attackers can intercept API key by listening to the network traffic in a public Wi-Fi network. | Make sure that the server URL is a valid URL and uses HTTPS protocol. |
servers:
- url: https://my.api.example.com/
description: API server
#...
components:
securitySchemes:
AuthKeyAuth:
type: apiKey
name: api-key
in: header
#...
security:
- AuthKeyAuth: []
Issue description | Possible fix |
---|---|
The credentials are sent as plain text over an unencrypted network. Attackers can intercept the credentials by listening to the network traffic in a public Wi-Fi network. | Make sure that the server URL is a valid URL and uses HTTPS protocol. |
servers:
- url: https://example.com/
description: Example server
components:
securitySchemes:
BasicAuth:
type: http
scheme: basic
security:
- BasicAuth: []
Issue description | Possible fix |
---|---|
The server supports unencrypted HTTP connections, all requests and responses will be transmitted in the open. Anyone listening to the network traffic while the calls are being made can intercept them. | Make sure that the server URL is a valid URL and uses HTTPS protocol. |
servers:
- url: https://my.api.example.com/
description: API server
# ...
components:
securitySchemes:
OAuth2:
type: oauth2
# ...
security:
- OAuth2:
- write
- read
Issue description | Possible fix |
---|---|
The API operation accepts the access tokens from a flow that are transported in plain text over an unencrypted channel. Attackers can intercept API calls and retrieve the unencrypted tokens. They can then use the tokens to make other API calls. | Make sure that the server URL of the operation is a valid URL and uses HTTPS protocol. |
components:
securitySchemes:
OAuth2:
type: oauth2
paths:
'/pets':
post:
operationId: addPet
servers:
- url: https://my.api.example.com/
description: API server
Issue description | Possible fix |
---|---|
The credentials for an operation are sent as plain text over an unencrypted network. Attackers can intercept the access tokens by listening to the network traffic in a public Wi-Fi network. | Make sure that the server URL of the operation is a valid URL and uses HTTPS protocol. |
components:
securitySchemes:
OpenIdScheme:
type: openIdConnect
openIdConnectUrl: https://my.api.openidconnect.example.com/
paths:
'/pets':
post:
operationId: addPet
servers:
- url: https://my.api.example.com/
description: API server
Issue description | Possible fix |
---|---|
The API operation accepts the authorization tokens that are transported as plain text over an unencrypted channel. Attackers can intercept API calls and retrieve the unencrypted tokens to make other API calls. | Make sure that the server URL of the operation is a valid URL and uses HTTPS protocol. |
paths:
'/pets':
post:
servers:
- url: https://example.com/
description: Example server
#...
components:
securitySchemes:
OAuth1:
type: http
scheme: oauth
#...
security:
- OAuth1: []
Issue description | Possible fix |
---|---|
The API operation accepts API keys that are transported in plain text over an unencrypted channel. Attackers can intercept API calls and retrieve the API key to make other API calls. | Make sure that the server URL of the operation is a valid URL and uses HTTPS protocol. |
paths:
'/pets':
post:
servers:
- url: https://example.com/
description: Example server
# ...
components:
securitySchemes:
AuthKeyAuth:
type: apiKey
name: api-key
in: header
# ...
security:
- AuthKeyAuth: []
Issue description | Possible fix |
---|---|
The API operation accepts the credentials that are transported in plain text over an unencrypted channel. Attackers can intercept API calls and retrieve the unencrypted tokens. They can then use the tokens to make other API calls. | Make sure that the server URL of the operation is a valid URL and uses HTTPS protocol. |
components:
securitySchemes:
BasicAuth:
type: http
scheme: basic
paths:
'/pets':
post:
operationId: addPet
servers:
- url: https://example.com/
description: Example server
security:
- BasicAuth: []
Issue description | Possible fix |
---|---|
The API operation supports unencrypted HTTP connections, all requests and responses will be transmitted in the open. Anyone listening to the network traffic while the calls are being made can intercept them. | Make sure that the server URL of the operation is a valid URL and uses HTTPS protocol. |
get:
operationId: getPetsById
servers:
- url: https://my.api.example.com/
Issue description | Possible fix |
---|---|
OAuth authorization credentials are transported over an unencrypted channel. Anyone listening to the network traffic while the calls are being made can intercept them. | Make sure that the authorization URL is a valid URL and follows HTTPS protocol. |
components:
securitySchemes:
OauthScheme:
type: oauth2
flows:
authorizationCode:
authorizationUrl: https://my.auth.example.com/
Issue description | Possible fix |
---|---|
OAuth authentication tokens are transported over an unencrypted channel. Anyone listening to the network traffic while the token is being sent can intercept it. | Make sure that the token URL is a valid URL and follows HTTPS protocol. |
components:
securitySchemes:
OauthScheme:
type: oauth2
flows:
authorizationCode:
tokenUrl: https://my.token.example.com/
Issue description | Possible fix |
---|---|
OAuth authentication refresh tokens are transported over an unencrypted channel. Anyone listening to the network traffic while the token is being sent can intercept it. | Make sure that the refresh URL is a valid URL and follows HTTPS protocol. |
components:
securitySchemes:
OauthFlow:
type: oauth2
flows:
authorizationCode
authorizationUrl: https://my.auth.example.com/
tokenUrl: https://my.token.example.com/
refreshUrl: https://my.refresh.example.com/
scopes:
write: modify data
read: read data
Issue description | Possible fix |
---|---|
OpenID Connect access tokens & open Ids are transported over an unencrypted channel. Anyone listening to the network traffic while the calls are being made can intercept them. | Make sure that the openID connect URL is a valid URL and follows HTTPS protocol. |
components:
securitySchemes:
OpenIdScheme:
type: openIdConnect
openIdConnectUrl: https://example.com/connect
#...
security:
- OpenIdScheme: []
Issue description | Possible fix |
---|---|
Security scheme uses OAuth 1.0 authentication which has been deprecated and replaced by OAuth 2.0. | Make sure that the security scheme isn't using the deprecated OAuth 1.0 authentication. |
components:
securitySchemes:
OauthFlow:
type: oauth2
flows:
authorizationCode:
authorizationUrl: https://my.auth.example.com/
tokenUrl: https://my.token.example.com/
scopes:
write: modify data
read: read data
Issue description | Possible fix |
---|---|
In OAuth implicit flow, authorization server issues access tokens in the authorization request's response. Attackers can intercept API calls and retrieve the access tokens to make other API calls. | It's recommended to use authorizationCode flow. Make sure that the OAuth authentication scheme isn't using the implicit flow. |
components:
securitySchemes:
OauthFlow:
type: oauth2
flows:
authorizationCode:
authorizationUrl: https://my.auth.example.com/
tokenUrl: https://my.token.example.com/
scopes:
write: modify data
read: read data
Issue description | Possible fix |
---|---|
OAuth password grant flow uses the user's credentials to retrieve the access token. Attackers can intercept API calls and retrieve the access tokens to make other API calls. | It's recommended to use authorizationCode flow. Make sure that the OAuth authentication scheme isn't using the password grant flow. |
components:
securitySchemes:
OauthFlow:
type: oauth2
flows:
authorizationCode:
authorizationUrl: https://my.auth.example.com/
tokenUrl: https://my.token.example.com/
scopes:
write: modify data
read: read data
This rule category deals with the OpenAPI info object, which has metadata about the API.
Issue description | Possible fix |
---|---|
Your API definition's info object doesn't have a description. Although a description isn't required, including one enables you to provide your API's consumers with information about what the API does and how to use it. This can be anything from a short description to a long explanation of possible uses cases. For your organization, defining the API's description during the design phase can help set the boundaries of the API. | Add a description to your API definition's info object. |
openapi: '3.0.3'
info:
title: An API name
version: '1.0'
description: An API description
Issue description | Possible fix |
---|---|
Your API definition's info object doesn't have a license object, which helps your API's consumers know how the API can be copied and used. | Add a license object to your API definition's info object. |
openapi: '3.0.3'
info:
title: An API name
version: '1.0'
license:
name: Apache 2.0
url: https://opensource.org/licenses/Apache-2.0
Issue description | Possible fix |
---|---|
Your API definition's license object doesn't have a license URL, which provides a link to a web page that describes the license. Although a license URL isn't required, a license name alone may not be not enough information for your API's consumers, especially when you use a custom license. | Add a URL to your API definition's license object. |
openapi: '3.0.3'
info:
title: An API name
version: '1.0'
license:
name: Apache 2.0
url: https://opensource.org/licenses/Apache-2.0
Issue description | Possible fix |
---|---|
Your API definition's info object doesn't have the URL of the API's Terms of Service. A terms of service is often mandatory for public APIs. It's also recommended that private APIs provide a link to a Terms and Conditions web page. | Add the URL of the API's Terms of Service to your API definition's info object. |
openapi: '3.0.3'
info:
title: An API name
version: '1.0'
termsOfService: https://example.com/tos
Issue description | Possible fix |
---|---|
Your API definition's info object doesn't have a contact object, which has contact information like a name, email address, or URL. Contact information defines a designated owner for each of your organization's APIs. The contact data may be used directly by your API's consumers, or through an API portal or catalog. | Add a contact object to your API definition's info object. |
openapi: '3.0.3'
info:
title: An API name
version: '1.0'
contact:
email: support@example.com
url: https://example.com/support
Issue description | Possible fix |
---|---|
Your API definition's contact object doesn't have a contact name. Although a contact name isn't required, it helps your API's consumers understand who owns the API. It also makes your organization consider the API's ownership. | Add a name to your API definition's contact object. |
openapi: '3.0.3'
info:
title: An API name
version: '1.0'
contact:
name: A contact name
Issue description | Possible fix |
---|---|
Your API definition's contact object doesn't have a contact URL or email address. Although a contact URL or email aren't required, including one or both gives your API's consumers a way to contact your organization or the API owner. | Add a contact URL, an email address, or both to your API definition's contact object. |
openapi: '3.0.3'
info:
title: An API name
version: '1.0'
contact:
email: contact@example.com
openapi: '3.0.3'
info:
title: An API name
version: '1.0'
contact:
url: https://example.com/support
Issue description | Possible fix |
---|---|
Your API definition's contact object doesn't have an email address. Although a contact email isn't required, including one gives your API's consumers a way to contact your organization or the API owner. | Add an email address to your API definition's contact object. |
openapi: '3.0.3'
info:
title: An API name
version: '1.0'
contact:
email: support@example.com
Issue description | Possible fix |
---|---|
Your API definition's contact object doesn't have a contact URL. Although a contact URL isn't required, including one gives your API's consumers a way to contact your organization or the API owner. | Add a URL to your API definition's contact object. |
openapi: '3.0.3'
info:
title: An API name
version: '1.0'
contact:
url: https://example.com/support
This rule category deals with operations on an API path.
Issue description | Possible fix |
---|---|
One or more path item objects in your API definition's paths object have a trailing slash at the end of the path. Some tools treat a path that ends with a trailing slash (/path/ ) differently from the way that they treat paths without a trailing slash (/path ), which can lead to problems that require long hours of debugging. | Remove any trailing slashes from paths in your API definition's paths object. |
openapi: '3.0.3'
# ...
paths:
'/resources':
Issue description | Possible fix |
---|---|
One or more operation objects in your API definition don't have a summary. A summary of what the operation does provides your API's consumers with important context that the HTTP method and path don't provide on their own. Many organizations use the API operation description that they create during the define phase of the API development process as the summary. | Add a summary for each operation object. |
openapi: '3.0.3'
# ...
paths:
/resources:
get:
summary: A GET operation summary
Issue description | Possible fix |
---|---|
One or more operation objects in your API definition have a summary that ends with a period (. ). API documentation tools use the summary as a title, so it shouldn't end with a period. | Remove the final period from all summaries at the operations object level in your API definition. |
openapi: '3.0.3'
# ...
paths:
/resources:
get:
summary: A GET operation summary
Issue description | Possible fix |
---|---|
One or more operation objects in your API definition don't have a description. When the resource path, HTTP method, and summary don't provide enough context for your API's consumers, a description can provide them with useful information about the API operation and its behavior. | Add a description for each operation object. |
openapi: '3.0.3'
# ...
paths:
/resources:
get:
description: A GET operation description
Issue description | Possible fix |
---|---|
One or more parameter objects in an operations object in your API definition don't have a description field. When the API name and context don't provide enough information for your API's consumers, a description can provide them with useful information about the parameter. | Add a description field for each parameter object. |
openapi: '3.0.3'
# ...
paths:
/resources:
get:
parameters:
- name: status
description: Filters resources on their status
in: query
schema:
type: string
Issue description | Possible fix |
---|---|
One or more parameter objects in an operations object in your API definition don't have an example or examples field. It's important to provide undocumented examples (using the example property) or documented examples (using the examples property) to help your API's consumers understand what data to provide. It may also help them to generate mock servers or a collection. | Add an example or examples field to provide your API's consumers with an example of the parameter's potential value. |
openapi: '3.0.3'
# ...
paths:
/resources:
get:
parameters:
- name: status
description: Filters resources on their status
in: query
example: done
schema:
type: string
openapi: '3.0.3'
# ...
paths:
/resources:
get:
parameters:
- name: status
description: Filters resources on their status
in: query
examples:
anExample:
summary: An example
description: A description of an example
value: done
schema:
type: string
Issue description | Possible fix |
---|---|
One or more POST operation objects in your API definition don't have a request body object. Even though the HTTP protocol permits POST requests without a body, this often hides a design problem. | Add a request body object to any POST operation objects. |
openapi: '3.0.3'
# ...
paths:
/resources:
post:
requestBody:
content:
'application/json':
schema:
type: object
Issue description | Possible fix |
---|---|
One or more PUT operation objects in your API definition don't have a request body object. Since a PUT operation is often used to replace or create something, not having a request body might be an error. However, this use might make sense in some cases (for example, to link two resources with a PUT, like /resource-ones/id1/other-resources/id2 ). | Add a request body object to any POST operation objects. |
openapi: '3.0.3'
# ...
paths:
/resources:
put:
requestBody:
content:
'application/json':
schema:
type: object
Issue description | Possible fix |
---|---|
One or more PATCH operation objects in your API definition don't have a request body object. Since PATCH operations are used to make partial updates, a PATCH method needs to include a request body. | Add a request body object to any PATCH operation objects. |
openapi: '3.0.3'
# ...
paths:
/resources:
patch:
requestBody:
content:
'application/json':
schema:
type: object
Issue description | Possible fix |
---|---|
One or more request body objects in your API definition don't have an example. It's important to provide undocumented examples (using the example property) or documented examples (using the examples property) to help your API's consumers understand what data they'll receive. It may also help them to generate mock servers or a collection. | Add an example or examples field to all request body objects. |
openapi: '3.0.3'
# ...
paths:
/resources:
post:
requestBody:
content:
'application/json':
schema:
# ...
example:
aProperty: example value
openapi: '3.0.3'
# ...
paths:
/resources:
post:
requestBody:
content:
'application/json':
schema:
# ...
examples:
anExample:
summary: An example
description: This is an example description
value:
aProperty: example value
Issue description | Possible fix |
---|---|
The responses object for one or more operation objects in your API definition don't have a 2xx class status code. Operations are expected to succeed and return a 2xx success HTTP status code. It's rare for an operation to return a different code, such as a 3xx redirect code, instead. | Make sure that operations return a 2xx success status code. |
openapi: '3.0.3'
# ...
paths:
/resources:
get:
responses:
'200':
description: A success response
Issue description | Possible fix |
---|---|
The responses object for one or more operation objects in your API definition doesn't have a 5xx class status code. Since operations may fail, they need to return a 5xx server error HTTP status code. | Make sure that all operations return a 5xx status code. |
openapi: '3.0.3'
# ...
paths:
/resources:
get:
responses:
'500':
description: A server error response
Issue description | Possible fix |
---|---|
One or more response objects in your API definition don't have an example. It's important to provide undocumented examples (using the example property) or documented examples (using the examples property) to help your API's consumers understand what data they'll receive. It may also help them to generate mock servers or a collection. | Add an example or examples field to all response objects. |
openapi: '3.0.3'
# ...
paths:
/resources:
get:
responses:
'200':
description: A success response
content:
'application/json':
schema:
# ...
example:
aProperty: example
openapi: '3.0.3'
# ...
paths:
/resources:
get:
responses:
'200':
description: A success response
content:
'application/json':
schema:
# ...
examples:
anExample:
summary: An example
description: This is an example description
value:
aProperty: example value
Issue description | Possible fix |
---|---|
The responses object for one or more DELETE operation objects has a 204 HTTP status code but also defines a response body. A 204 status means "no content," so there shouldn't be a response body defined. | Make sure that DELETE methods with a 204 status code don't have a response body. |
openapi: '3.0.3'
#...
paths:
/resources:
delete:
responses:
'204':
description: a success response
This rule category deals with how to model various data types.
Issue description | Possible fix |
---|---|
A schema property in one or more response objects or body parameter objects doesn't reference a reusable schema. A schema reference ($ref ) that targets reusable schemas in definitions supports design consistency and OpenAPI document and API documentation readability, and facilitates maintainability by avoiding duplication of models. | Consolidate all your responses and body parameter schemas into definitions . |
openapi: '3.0.3'
# ...
paths:
/resources:
get:
responses:
'200':
description: a success response
content:
'application/json':
schema:
$ref: '#/components/schemas/Resources'
components:
schemas:
Resources:
type: object
Issue description | Possible fix |
---|---|
One or more schema objects in the components object don't have a description . When the schema name and context don't provide enough information for your API's designers and consumers, a description can provide them with useful information about the reusable schema. | Add a description for every reusable schema in your API definition. |
openapi: '3.0.3'
# ...
components:
schemas:
aReusableSchema:
description: A reusable schema description
type: object
Issue description | Possible fix |
---|---|
One or more properties in a schema object in your API definition don't have a description . When the schema name and context don't provide enough information for your API's consumers, a description can provide them with useful information about the element. A complicated description may indicate a problem in the API's definition or design, so spending the time to create a description can be clarifying. | Add a description for every property in your schema object. |
openapi: '3.0.3'
# ...
paths:
/resources:
get:
responses:
'200':
description: A success response
content:
'application/json':
schema:
properties:
aProperty:
description: A property description
type: string
minItems
and maxItems
definedIssue description | Possible fix |
---|---|
One or more schema objects in your API definition have an array type property but don't define minItem or maxItem . Consumers and providers can't handle an infinite number of elements. Setting the minimum and maximum boundaries helps in defining limits and enabling pagination. | Make sure that properties that have array type in your API definition have minItem and maxItem defined. |
openapi: '3.0.3'
# ...
components:
schemas:
anObject:
properties:
aList:
type: array
minItems: 1
maxItems: 100
items:
type: object
Last modified: 2024/07/12
Additional resources
Videos
Blog posts
Public workspaces