OpenAPI’s Achilles Heel
So this week Github adopted OpenApi to much fanfare and jeers. Yes OpenAPI is both loved and hated because of various reasons. But the what I am going to talk about today is something that both Swagger, Mulesoft, Apigee and all other makers of Api Gateways (and pushers of specs for Gateways) don’t want you to know… that the OpenApi is a security hole to your application.
The Api Pattern Call Flow
To understand why OpenAPI creates a security hole, first you must understand one core principle: where the single version of truth for the data for your endpoints exists.
The api pattern for the web is based on a 1970’s pattern for centralized single tier architectures wherein communication(I/O) data/logic are bound to controllers (MVC).
This makes it IMPOSSIBLE to share/syncronize the data!
So gateway providers create DUPLICATIONS of that data (like OpenApi)in order to copy the functionality at the controllers further out at the proxy/gateway.
The problem?
The problem lies in the fact that the single version of truth changes in the controllers and their document doesn’t synchronize with the changes.
This leads to:
- escalated/de-escalated privileges
- badly routed api’s
OpenApi’s Response?
Now, the OpenApi communities solution is to put all the blame on the end user saying the end user is required to:
- take down all the services
- regenerate all documents
- bring back up all services
This is not reasonable. Especially when you can use a single document and synchronize on the fly as seen here:
The above uses a schema at the api server which can be reloaded and push out to all subscribing services like the gateway/proxy, cache, message queue or even dependent api servers.
This keeps EVERYTHING constantly up to date with ZERO DOWNTIME!
So why does OpenAPI keep pushing a subpar spec?
Easy. They all have a product to sell and it sells product. Api Gateways. Mulesoft, Apigee, Kong, etc.
Almost every single company behind the spec is a vendor with a product to sell and they are NOT address the issues… nor do they want to. They only want people dependent on a spec that makes them dependent on their products.
Vendors like Amazon and Netflix have fixed these issues internally and even on some of their products while others have not and continue to adopt this spec.
Avoid at all costs and create your own if you need to.
