WunderGraph API Security: Expose multiple APIs to the public internet and consume them from insecure clients like Browsers

As described in the sections on API-Mesh and the Query Compiler, WunderGraph merges all your DataSources into a unified "virtual Graph". Based on this virtual Graph, Developers can then define their Actions by writing GraphQL Operations against the Graph. Each Operation will be turned into a JSON-RPC Endpoint that can be invoked with the variables defined in the Operation.

This section describes the security model of WunderGraph, helping you to understand how WunderGraph can protect your APIs.

Compiled Operations vs. interpreted GraphQL#

Let's start by recapping the execution flow of a traditional GraphQL Server vs. WunderGraphs compiled Operations.

Traditional GraphQL Server:

1. Parse JSON Body
2. Extract GraphQL Operation
3. Lexing / Tokenizing of Operation
4. Parsing of Operation
5. Normalization (cleaning the AST, deduplication of fields)
6. Validation
7. Interpretation of GraphQL AST
   1. Recursively visiting all AST Nodes
   2. For each Node, check if a resolver exists
   3. Execute Resolver if any
   4. Resolvers itself might access AST to retrieve meta-data
   5. Collection of all resolved fields
   6. Assembly of the Response
8. Returning the Response

WunderGraph compiled Operations:

1. Parse Variables
2. Call user function with variables and return Response

Regular GraphQL Servers can easily be attacked by denial of service attacks. Amongst other attack vectors, authorization traversal attacks might be the most severe ones, allowing an attacker to retrieve data without being authorized to do so. We've discussed the 13 most common GraphQL Vulnerabilites in a dedicated post.

By removing almost all steps from the Execution Pipeline, WunderGraph reduces the attack surface dramatically.

Exposing a GraphQL Server to the public internet can be a huge risk. Putting WunderGraph in front is a huge step forward.

JSON-Schema validation for Input Variables#

However, just removing many of the vulnerable execution Steps from the Pipeline doesn't resolve all problems. For that reason, we've also added a way to validate the Inputs for each Operation. Instead of just relying on type checks, you're able to use JSON-Schema Validation to validate all Inputs in-depth.

Learn more about WunderGraphs JSON-Schema capabilities in the docs.

OpenID Connect Claims Injection#

WunderGraph comes with out-of-the box support for OpenID Connect (OIDC). OIDC has many benefits as it standardizes the process of authentication. On the one hand, thanks to OIDC WunderGraph can integrate with many Identity Providers that support the specification. On the other hand, OIDC allows us to inject claims into the compiled Operations, allowing for a seamless authorization developer experience.

Learn more on authentication using OIDC and how to inject Claims into Operations looking at our docs.

CSRF Protection for Mutations#

Finally, one commonly overlooked issue with APIs is protecting against CSRF. For the web, our default method of authentication is using secure encrypted cookies. With the correct SameSite configuration, HTTP only cookies are the go-to solution to manage user authentication in a stateless way.

However, cookie-based authentication comes with a trade-off, you have to protect against CSRF attacks.

Instead of pushing the problem to our users, we've taken the necessary actions to embed CSRF protection into the core of WunderGraph. Both, the server-side as well as the client-side part mitigate CSRF attacks for Mutations out of the box.

Learn more on CSRF protection looking at the docs.

Conclusion#

WunderGraphs Architecture helps a lot to expose APIs securely. Additionally, we've added a few more extras to make "securing your APIs" not just easy but also fun.

Our philosophy is to take away as much complexity as we can from our Users, allowing you to focus on delivering value instead of figuring out how to properly implement authentication & authrorization.