An API Validation Aggravation

Mike Rozner — Thu, 25 Aug 2022 09:48:00 +0000

API specification validation

API specification validation is the process of verifying that an API meets all the requirements specified in its documentation. This includes making sure that the API responds correctly to all requests, that it gives back the right data, and that it doesn't give back any data that wasn't expected.

It is an important part of the development process as it ensures that the API behaves as expected and that it meets all the requirements of its users. It is also a good way to catch any errors or bugs in the API before they are released to the public.

API specification validation can be done manually or automatically. By running a series of tests against an API and looking at the results, automated testing tools can make it easier to check if it meets its requirements.

Hand testing API

An API can also be tested by hand, but this can take more time and may require more knowledge of the API and how it works.

API validation is an important part of developing and releasing a new API. It helps to ensure that the API behaves as expected and that it meets all the requirements of its users. Validating an API can be made easier with automated testing tools and CI/CD integrated validation 💡 tools, but it can also be done by hand.

When it comes to documenting APIs, there are few tools as widely used and supported as Swagger. In fact, Swagger has become so popular that it is now known as the de facto standard for API documentation.

The swagger flaws

But Swagger is not without its flaws, and there’s a new kid on the block that promises to address some of the shortcomings of Swagger 2.0: OpenAPI 3.0.

In this article, we’ll also take a look at the key differences between Swagger 2.0 and OpenAPI 3.0.

OpenAPI 3.0 is the latest version of the OpenAPI Specification, and it’s not backwards compatible with Swagger 2.0.

One of the most significant changes in OpenAPI 3.0 is the addition of a new required field: info. This field takes the place of the old swagger.info field. It has information about the API, like the title, description, and how to get in touch with the developers.

Here are some of the changes.

"Host" and "BasePath" combine to form a "Target". In Swagger 2, you declare a single host and base path for all of your resources and operations.
The parameters are defined at the top level of the resources. In Swagger 2, you define parameters in the operations.
You can define multiple paths for a resource. In Swagger 2, you can only define one path per resource.
You can define multiple operations for a resource. In Swagger 2, you can only define one operation per resource.
You can define multiple responses for an operation. In Swagger 2, you can only define one response per operation.

Another notable change is the removal of the consume and produce fields in favor of a new field called requestBody. This new field is used to describe the request body of an API operation.

In OpenAPI 3.0, the term "schema" has been replaced with the term "media type". This change was made to be more consistent with the way media types are used in HTTP.

Significant change in OpenAPI 3.0

Perhaps the most significant change in OpenAPI 3.0 is the addition of the Components object. This object contains a collection of reusable objects that can be used in the specification. Examples of objects that can be stored in the Components object include schemas, responses, parameters, and examples.

One of the main goals of OpenAPI 3.0 is to be more easily readable and understandable by humans. To that end, the specification includes a new feature called links. Links are used to describe relationships between resources.

Another goal of OpenAPI 3.0 is to make it easier for tools to generate code and documentation from the specification. To that end, OpenAPI 3.0 includes the concept of callbacks. Callbacks are functions that the API provider can use when certain events happen.

Overall, OpenAPI 3.0 is a major evolution of the OpenAPI Specification. Even though it doesn't work with Swagger 2.0, it fixes many of the problems with its predecessor.

Not everything is fairytale

There are a few reasons why it might not be possible to convert a Swagger file to OpenAPI 3.0 specification:

The Swagger file might be using features that are not yet supported in OpenAPI 3.0. For example, Swagger 2.0 supports arrays and objects as data types, but these are not yet supported in OpenAPI 3.0.
The Swagger file might be using features that are no longer supported in OpenAPI 3.0. For example, Swagger 2.0 supported the "any" data type, but this has been replaced with the more specific "oneOf" in OpenAPI 3.0.
The Swagger file might be using deprecated features that have been replaced in OpenAPI 3.0. For example, the "paths" object in Swagger 2.0 has been replaced by the "paths" and "servers" objects in OpenAPI 3.0.
The Swagger file might be using a different file format than OpenAPI 3.0. Swagger 2.0 used the "swagger.json" or "swagger.yaml" format, while OpenAPI 3.0 uses the "openapi.json" or "openapi.yaml" format.
The Swagger file might be using a different version of the Swagger specification than OpenAPI 3.0. For example, Swagger 2.0 is based on the Swagger specification version 2.0, while OpenAPI 3.0 is based on the Swagger specification version 3.0.0.

Conclusion

Even if all of these factors are accounted for, it might still not be possible to convert a Swagger file to OpenAPI 3.0 due to incompatibilities between the two specifications. Swagger 2.0 and OpenAPI 3.0 are both based on the same underlying data model, but there are a number of subtle differences between the two specifications. These differences can lead to problems when converting files from one format to the other.

Don't forget to visit my API Security website

Closing that busines logic attack vector

Mike Rozner — Mon, 27 Jun 2022 12:16:55 +0000

Lets start with the steps

🩴The first step in protecting your data is knowing where it is stored and who has access to it. Make sure you have a list of all the places where your sensitive data is stored, including both digital and physical locations. Then, review who has access to each location. If possible, restrict access to only those who absolutely need it.

2. Implement security measures like firewalls and encryption.

Once you know where your sensitive data is stored, you can start implementing security measures to protect it. Firewalls and encryption are two of the most important measures you can take. Firewalls can help prevent unauthorized access to your network, while encryption can make it difficult for hackers to read your data even if they are able to access it.

3. Educate your employees about security risks and best practices.

Your employees are one of your biggest assets when it comes to protecting your data. Make sure they are aware of the risks and that they know the best practices for keeping their information safe. This includes things like using strong passwords, not sharing passwords with others, and not clicking on links from unknown sources.

4. Stay uptodate on the latest security threats.

Threats are constantly evolving, so it’s important to stay uptodate on the latest security risks. One way to do this is to subscribe to security newsletters or RSS feeds. This will help you stay informed about new threats so you can take steps to protect your business.

5. Have a plan in place in case of a data breach.

Despite taking all the precautions, there’s always a chance that your business could be affected by a data breach. That’s why it’s important to have a plan in place for how you would handle such a situation. This plan should include steps for how you would notify customers, what steps you would take to secure your data, and how you would prevent future breaches from happening

The Consequences of a Data Breach

The above steps will bring your security to a good balance, but your F$%&ed if you got to this point reading, as none of the above will help you in stopping a dedicated business logic attack.

What is business logic attacks 🧠

A business logic attack is an attack on the application layer of a system that targets the consistency, correctness, and integrity of the data and processes. This type of attack exploits vulnerabilities in the way that the business logic is implemented, often resulting in data or process corruption.

There are many reasons why it is complex to defend against business logic attacks. One reason is that attackers can exploit many different types of vulnerabilities to gain access to sensitive data or systems. Another reason is that attackers can use a variety of techniques to bypass security controls or to disguise their activities. Finally, businesses often have complex networks and systems, which makes it difficult to identify and fix vulnerabilities.

In my next articles I will begin a series talking about way to defend from business logic attacks.

DEV Community: Mike Rozner