Skip to main content
Version: v2.x

Security Best Practices


This guide reviews security best practices that should be implemented when working on a Hasura Project. Applying API security beyond RBAC (role-based access control) permissions is mandatory for any API moving towards a Hasura deployment. We recommend that all HTTP layer security work be done at the API gateway level and GraphQL-specific policies be applied at the Hasura level.

Security Announcements

Join the Hasura Security Announcements group for emails about security announcements.

Hasura/API security architecture

Specifics about each security best practice can be found below.

Hasura GraphQL Engine

Restrict Access

Restrict knowledge of admin secrets to the minimally required team members as an admin secret provides unrestricted access to the Hasura GraphQL Engine. SSO collaboration should be used to grant project access without sharing an admin key. Subsequently, implement a plan to rotate admin secrets to limit the exposure of an admin secret being shared too broadly.

Multiple admin secrets should be used in situations where admin secrets have different rotation timelines or when granting temporary access is needed.

Leverage allowed operations lists whenever possible to restrict unbounded or unexpected operations from being executed against the GraphQL endpoint. Allow lists must be enabled via environment variable. These lists can be configured globally or at the role level which allows for each role to have a differently defined set of permissible operations. The allow list should include the complete set of expected operations for a given role to restrict the ability for a user to execute non-permissible operations. Consider using the Hasura Allow List codegen plugin to automatically generate allow list Metadata from your application code.


The admin role will bypass the allowed operations list.

Limit the API

The allowed operations lists workflow is ideal for private/internal APIs or APIs with well understood and clearly defined operations. Public APIs or APIs with less defined expected operations should additionally configure depth limits and node limits.


The row-based access control configuration dictates permissions for the GraphQL API. It is critical that these permissions be configured correctly in order to prevent unauthorized or unintended access to the GraphQL API.

Disable development components

There are several components of Hasura GraphQL Engine that are crucial for development efforts but should be disabled for a production environment. However, it should be expected that some of these components may need to be temporarily re-enabled if a situation arises where a production environment specific issue requires troubleshooting.

Additional environment variables

There are specific environment variables that should be configured to ensure appropriate communication to the Hasura GraphQL Engine server.

Database connections

Hasura GraphQL Engine communicates with your data sources(s) via ODBC connection strings. This means Hasura has the same permissions as the provided credentials in the connection string.

  • Use environment variables rather than a hardcoded value when configuring the database connection string. This environment variable can then be reused in the other environments (e.g., staging or production) while containing a reference to the environment-specific database connection string. Please see Metadata Best Practices for more information.

  • Review the database permissions allocated via the provided credentials to ensure the level of access granted to Hasura is appropriate.

  • Use database connections strings with the least privileges required for API operations.

  • Configure read replicas to route read-only operations (queries) to one (or many) read replicas.

Networking/API gateway

We recommend the following HTTP layer security policies to be configured at the API gateway:

  • Configure HTTPS on your reverse proxy to ensure encrypted communication between your client and Hasura.
  • Implement request and response size restrictions.
  • Restricted allowed connection time to prevent incidents such as slowloris attacks.
  • Apply both IP filtering and IP rate limiting.

Consider using a a web application firewall (WAF) as the first line of defense. A firewall can provide extra protection against common attack types such as cross-site request forgery (CSRF) by filtering and monitoring HTTP traffic between the application and the internet based on a rule set configured by your team. Common WAF solutions include Cloudflare, Akamai and Imperva.