With recent explosion of Kubernetes adoption and Wallarm’s consistent effort to deliver Kubernetes native security offerings, I feel tremendous confidence in our collective ability to stay ahead of the emerging threats in the cloud native ecosystem.
There is a new attack surface when the app tech stack includes GraphQL. It’s Batched Attacks on GraphQL APIs. How can these apps be protected? Read more to find out.
Intro In the last post, we touched on the topic of GraphQL security. As a reminder, GraphQL is a popular alternative to REST APIs. A single article can not encapsulate all the things one wants to know about such an interesting technology. This installment of the series will look at the first step of analyzing how well GraphQL is protected, specifically securing the GraphQL schema by disabling introspection query which is enabled by default. What…
Wallarm can protect North-South API in the applications that use Envoy as an alternative Ingress controller at the front end of a Kubernetes cluster. Wallarm can also protect edge traffic and also East-West Envoy API for Service-Mesh and Istio.
Andrew Jenkins of Aspen Mesh identifies three deployment options with regards to how a Service Mesh delivers its services:
- As a sidecar that runs alongside your microservice container
- As a library that can be built into each of the microservices
- As an agent that sit in the container infrastructure and provide the service to all the containers on that node
GraphQL is an alternative to the REST concept that allows working with the data in a more structured and object-oriented way. This technology is very famous and used by many enterprise companies such as Facebook, Walmart, Intuit among other. Whether you know it or not, GraphQL has a significant impact on your business. Many products you rely on, such as GitLab, New Relic, and WordPress use GraphQL under the covers. In this series of articles,…