Our Enterprise API Security Solution

TLS, OpenID, and the OAuth standards address only part of the API security problem. API security needs be addressed holistically to address the end-to-end goals, including attacks protection, ensuring the confidentiality and integrity of transactions, and the availability of the API infrastructure. Most API security providers do not take such an approach. 42Crunch does.

Take A Holistic Approach To API Security

When you read about API security, you often see references to TLS and OAuth as the secret sauce to address the problem. However, the API security problem has a much wider scope, and those standards help address only parts of the problem. API security needs to be approached as a whole to address all security goals, including attacks protection, ensuring the confidentiality and integrity of transactions, and the availability of the API infrastructure.

Assess Risk Before Defining API Security

Not all APIs are equal. The security level that an API requires depends on the sensitivity of the data and operations applied to that data, who can access the API, and in which network zone the API is deployed. By defining a threat model and assessing the risk for each API, you can ensure that the API security policies are adequate for each API and prevent high-risk APIs from being deployed on poorly secured infrastructures.

Reuse Proven, And Standard-compliant API Security Policies

API security is hard. There are many ways you can get your security policies wrong, even when following a standard. Take OAuth, for example, a plethora of RFCs and profiles related to threats models, best practices, token theft, and Open Banking. Which configuration is right for you?

Distributed Enforcement Model, Compatible With Microservices Architectures

API security has traditionally been enforced at the edge through a gateway pattern. But modern applications have redefined the rules of the game: applications often rely on multiple internal, public, or partner APIs. In addition, the adoption of microservices architectures has multiplied the number of API endpoints to protect. These architectural changes require security to be handled as close to the API as possible.

Integrate API Security Fully As A Part Of Devops Initiatives

API security flaws are injected at many different levels of the API lifecycle: in requirements, during development, and during deployment. It is proven that detecting and fixing vulnerabilities during production or post-release time is up to 30 times more difficult than earlier in the API lifecycle. Security should be easy to apply during development by attaching pre-defined policies to APIs and ensuring that tests are performed as part of the continuous delivery of the APIs.

Foster Collaboration Across API Security Actors

API security is a cross-functional part of the IT organisation but IT security teams are rarely part of the development and deployment process of APIs. The security teams are often invited late in the game to review security in a rush, with limited time to fix potential vulnerabilities or put in place the proper protection layers in front of APIs. It is critical to manage APIs in a central place where the various stakeholders can see new APIs that are being deployed and enforce corporate security policies and processes.