Warnings in OpenAPI 2.0 in postman

Introduction

Any two independent programs can transport and share data thanks to API. Additionally, they facilitate action execution for program users by removing the need for the GUI. From the developers' perspective, it's a simple method to use some software features and test them. Because one may need to utilize or try dozens or even hundreds of APIs daily, using APIs can be challenging. Consequently, it is challenging to remember their specific request's address(es), header(s), authorization credential(s), etc. Additionally, it makes it more challenging to test the API's usability, security, and error handling.

Postman advises that you heed any security and formatting cautions at the API specification stage of API development. Your API schema is not broken just because you received a warning! Instead, it suggests that there might be security risks to which your API is exposed or usability problems due to probable design flaws. These cautions are highlighted by Postman, who also explains their ramifications and suggests potential solutions. For API definitions in OpenAPI 3.0 and OpenAPI 2.0 format, Postman supports warnings.

Postman can help you find any possible security and formatting problems when creating your API.

Warnings for OpenAPI 2.0

The list below includes probable warning messages for each API defined in OpenAPI 2.0 and alternative solutions. Let us see all the warnings in detail. 

Broken object-level authorization

The securityDefinition declaration does not indicate the scope of the OAuth scheme used in the security field. The security schemes field must define the OAuth2 contents used in the global security field. If not, a hacker can insert their scopes to close the hole and take advantage of the system. Ensure that all the OAuth2 ranges utilized must be defined as one potential fix in the OAuth2 security scheme.

Broken user authentication 

By default, the API doesn't require any authentication if the global security field isn't specified. The API operations without a defined security field are accessible to everyone. The potential remedy is that the schema needs to determine the security field.

• No items in the security field: By default, no security scheme is applied to operations if the security field is empty. The security field must contain at least one item from the array as a potential solution.
   
• Nothing in the security field refers to a scheme: The authentication is fully disabled when the security field contains an empty object. Anybody can access the API operations without authentication if security attributes are not set for each operation. The possible solution is that items in a security field array cannot contain a null object.
   
• Security definition object not defined: A security definition object that can be used in the security field of the API or specific actions are not declared in the components object of the API. Security definitions must be included in the component's schema as a solution.
   
• Security definition object lacks any scheme information: Anyone can access the API operations without authentication if an empty object in the reusable security definition indicates no authentication scheme is set for each activity. The answer is that security definitions must include at least one object-containing item.
   
• The security definition object does not define the scheme used in the security field: The security definition object does not define the authentication method used in the global or operation security fields. The remedy is The security definition object must define the scheme used in the security field.

Excessive data exposure

The access tokens are transmitted across an unencrypted network in plain text, exposing much data. Attackers can intercept access tokens by monitoring network traffic on a public Wi-Fi network. The potential remedy is to Ensure that HTTPS is the scheme used in the array of schemes.

• The API accepts plain text: API keys transmitted via an unsecured channel. Attackers can intercept API keys by monitoring network activity on a public Wi-Fi network. The remedy for this is Ensure that HTTPS is the scheme used in the array of schemes.
   
• API accepts plain text basic authentication credentials: The certificates are transmitted across an unencrypted network in plain text. An attacker can intercept the credentials by monitoring network activity when using a public Wi-Fi network. The remedy for this is Ensure that HTTPS is the scheme used in the array of schemes.
   
• Global schemes specify the HTTP scheme: All requests and responses will be transmitted in the open when using the server, which allows unencrypted HTTP connections. The calls can be intercepted by anyone monitoring the network traffic as they are being made. The remedy for this is Ensure that HTTPS is the scheme used in the array of schemes.
   
• The operation supports plain-text OAuth authentication credentials: The API accepts access tokens from flows sent via unencrypted channels in plain text. Attackers can retrieve unencrypted tokens by intercepting API calls. Then, they can utilize the tokens to call different APIs. Assure that HTTPS is used as the scheme in the operation's array as one potential fix.
   
• Plain text APThe operation accepts plain text API keysAPI keys sent over an unencrypted channel are taken by the API operation. Attackers can retrieve the API key from intercepted API calls and use it to make other API calls. The remedy for this is Verify that HTTPS is the scheme being used in the operation's scheme array.
   
• The operation takes plain-text basic authentication credentials: The API accepts the credentials sent over an unencrypted channel in plain text. Attackers can retrieve unencrypted tokens by intercepting API calls. Then, they can utilize the tokens to call different APIs. The cure is Verify that HTTPS is the scheme used in the operation's scheme array.

Injection

The API may accept any data as input if the global consumption field is left undefined. This could expose your API to various threats, including buffer overflows, encoding mistakes, and SQL injection attacks. The consumes field has to be defined in the schema, which is one potential solution.

• Nothing is in the Consumes field: The API can automatically accept any form of input if the consumes field is empty and contains an empty array. The global consumption field must have at least one valid MIME type item in the array as a potential remedy.
   
• There is no item in the operation's consumes field: Since there is no consumes field in action, the API can, by default, accept any input. The potential remedy is In PUT, PATCH, and POST operations. The consumes field must contain at least one element from the array.
   
• No consumes field in operation: If neither the global consumes field nor the consumes field for the operation (for PUT/PATCH/POST) are defined, anyone can abuse your API. Define a consumes field in the operation if one is not already specified globally.

Improper assets management

• OAuth authentication uses the deprecated implicit flow: Access tokens are issued by the authorization server to answer the authorization request in OAuth implicit flow. Attackers can retrieve access tokens from intercepted API calls and use them to make other API calls. It's advised to use accessCode flow as a possible remedy. Verify that the OAuth authentication protocol is not using the implicit flow.
   
• The deprecated password flow is used for OAuth authentication: The user's credentials are used in the Oauth password grant flow to retrieve the access token. Attackers can retrieve access tokens from intercepted API calls and use them to make other API calls. The potential remedy is the Use of the accessCode flow is advised. Verify that the password flow is not used in the OAuth authentication process.

API details

The OpenAPI info object, which includes API metadata, is the subject of this category of linting rules. There are more things related to this API details, which are as follows: 

• API must include a way to get in touch: A contact object, which consists of a name and email address for contacts, is missing from your API schema's info object. The potential remedy is, Although it's not necessary, providing your contact details enables users to get in touch with you. Include a contact object in the info object of your API schema.
   
• API must have an available contact email address: The contact object in your API schema does not have an email address. One potential solution is, Although it's not necessary, providing your contact details enables users to get in touch with you. Include an email address in the contact object of your API schema.
   
• API must have an available contact name: There is no name for the contact person or business in the contact object of your API schema. The potential remedy is, Although it's not necessary, providing your contact details enables users to get in touch with you. The contact object in your API schema should have a name.
   
• API must provide a contact URL: The URL of the contact person or business is not present in the contact object of your API schema. The potential remedy is, Although it's not necessary, providing your contact details enables users to get in touch with you. The contact object in your API schema should have a URL.
   
• A description, licensing URL, terms of service, API ID extension, and audience extension should all be present in the info object.
   
• There must not be any dead ends: The pathways object in your API schema contains one or more empty path item objects. The potential remedy is that Access-control list (ACL) restrictions allow you to leave a path item object empty, but doing so doesn't give your users a positive experience. In your API schema, include information about any open path item objects.

Operations

This group of linting rules focuses on actions that can be taken on an API path. Several features should be considered performing operations. 

• There should be descriptions for each operation: Your API schema has one or more operation objects that lack descriptions. The potential remedy is Giving your users a thorough explanation of the operation's conduct gives them crucial context. Each operation object should include a description.
   
• Every action should have summaries: Your API schema has one or more operation objects that lack outlines. The potential remedy is A concise description of the operation's goals to give your users crucial context. For each operation object, include a summary.
   
• Tags should be used for all operations: Your API schema lacks one or more operation objects with a tag array. Operation tags can be used to arrange operations in logical groups in API documentation as a potential fix. For each operation object, provide a tags array.
   
• Every operation needs at least one tag: A tag array is present in one or more operation objects in your API schema, but the array is empty. Operation tags can be used to arrange operations in logical groups in API documentation as a potential fix. For each operation object, add a tag to the tags array at the very least.
   
• All parameters should have descriptions and examples. 
   
• Request bodies should be used using POST methods: Your API schema lacks a request body object for one or more POST operation objects. The potential remedy is A request body object that includes details on what constitutes an acceptable response body and a brief description of the response body. Any POST operation objects should consist of a request body object.
   
• DELETE operations should not have a response body. It should have a 204 status code for the response and a 500 status code for the response.
   
• A 200 status code should be returned for PUT operations: The 200 status code is missing from the replies object for one or more PUT operation objects in your API schema. Ensure all PUT methods return a 200 status code as a viable solution.

Models

This group of linting rules discusses how to model different data forms like schema descriptions, schema properties, and many more. 

• There should be descriptions for each schema: The components object of your API schema contains one or more schema objects that need descriptions. Add a description for each schema object in your API schema as one potential fix.
   
• All schemas ought to have properties: The components object for your API schema has one or more schema objects that don't have at least one property. Add a property for each schema object in your API schema as one potential fix.
   
• Integers should be formatted as int32 or int64: The components object of your API schema has one or more schema objects with an integer type property but don't mention the int32 or int64 formats. Make sure that attributes with integer types in your API schema have an int32 or int64 format as a potential remedy.
   
• Decimal32, decimal64, float, double, or decimal128 should be used as the number format: The number type attribute of one or more schema objects in your API schema's components object lacks a decimal32, decimal64, float, double, or decimal128 format specification. Making ensuring properties with number types in your API schema have a format of decimal32, decimal64, float, double, or decimal128 is one potential fix.
   
• One or more schema objects in your API schema's components object contain an array type property but don't define minItem or maxItem, which is required for arrays. Specifying the minimum and maximum bounds for arrays in your API schema could be the solution to avoid overloading this type of attribute. Ensure that the minItem and maxItem values are defined for properties with array types in your API schema.
   
• All schema properties should have descriptions and type properties.
   
• All schemas should have the required property and type of property.