Hasura Cloud is a fully managed, globally available, auto scaling version of Hasura that also includes features specifically designed to make it easier for you to run Hasura in production. These features range from the addition of monitoring/analytics features for increased observability to built-in caching for improved performance, to a suite of security features that help you safeguard your production Hasura applications. All of these are hard problems that all GraphQL Servers run into in production - with Hasura Cloud, these features are available out of the box with simple and intuitive configurations!

In this post, I will walk you through the security features available on Hasura Cloud, including a set of new enhancements launched in the latest Cloud release v 2.0.3. These features help you secure your production application, and safeguard your app against injection attacks, DDoS attacks, excessive data exposure, and more, whether malicious or accidental.

Global and Role-based API controls under the Security tab [new]

Hasura Cloud has a new Security tab under the API section of the console to make it easy to access API security settings.

We’ll focus our attention on five key security features that Hasura Cloud adds to the production checklist, and describe the use-cases those features are solving for.

Graph-like querying structures are susceptible to recursive querying patterns, both accidental and malicious. Without checking the level of nesting, it’s possible to generate large and expensive queries. While it is possible to create proxy services to a self-hosted GraphQL server to handle this problem, Hasura Cloud makes this a click-and-set configuration. Using our shapes and sets analogy, we might end up with the following example:

{
  shapes {
    set {
      name
      shapes { # duplicate reference!
        name
      }
    }
  }
}

Setting a depth limit will surface this problem for us.

In addition to depth limits, node limits are another “gotcha” to be aware of. Every field in GraphQL is a node, regardless if that’s nested five levels deep in a query structure or at the root level. GraphQL in particular has additional mechanisms that can quickly lead to excessive node usage if left unchecked. For example, creating reusable fragments and aliases is great for code cleanliness, but, when used incorrectly, you could end up with excessive egress from your database.

{
  set1: shapes {
    name
    set {
      name
    }
  }
  set2: shapes {
    name
    set {
      name
    }
  }
  set3: shapes {
    name
    set {
      name
    }
  }
}

Setting a limit on the total number of nodes helps ensure terse requests that don’t unintentionally inflate your database bill.

Hasura supports a wide variety of workload types, from heavily cached responses to real-time feeds. The majority of use cases will often end up somewhere in-between and having the ability to rate-limit requests is a great way to balance spiking user load. It’s also a vital and effective piece in the mitigation strategy against DDoS attacks or when a single API consumer is flooding your service with unoptimized requests. Rate limiting can also be applied conditionally to matching IPs or request parameters. This allows for throttling suspicious activity without restricting organically spiking usage.

The GraphQL specification states that all GraphQL endpoints must be introspectable, which has become the bedrock of much of the powerful tooling in the GraphQL ecosystem. However, persistent and immediately introspectable APIs have been the topic that security experts have included in nearly every formal review of a GraphQL endpoint. The reason behind this critique of an introspectable API is that it falls foul of the OWASP guidance to avoid excessive data exposure/disclosure. Imagine if an introspectable API from a public company now had a root level model for a vertical they’d previously not been associated with, this would lead to significant repercussions in the markets. Fortunately, Hasura Cloud makes disabling introspectable schemas as simple as a click.

One method for ensuring only approved content leaves your database is to require approval for the operations that can be used in production. This list of approved methods is then aptly named, the “allow list.” Hasura Cloud makes this a simple process of viewing the previously requested operations, selecting the ones that should be allowed in production, then adding them to the list. This becomes an effective “final-form” of the production application, where you can do a final review of all the operations making requests against the API, then add them to the allow list, thus blocking all non-sanctioned requests to your database.

Many of the leading cloud providers offer SSL-based DB connections for the highest security compliance. While not alone in the requirement, Google Cloud Platform (GCP has long required SSL based database authentication – and Hasura Cloud now makes it simple to use Google’s robust database offerings.

Hasura Cloud is able to offer a lot of this functionality as it tightly integrates with the route handling and logging functionality at the server level. Try these out on Hasura Cloud and let us know if you have any questions.

Useful reads:

• Migrating from Hasura CE to Hasura Cloud
• Production Checking for Hasura CE
• Security and Compliance on Hasura Cloud