Skip to main content

Automatic Persisted Queries


The absence of Automatic Persisted Queries can cause backend performance problems at scale.

GraphQL clients send queries to Apollo Servers as HTTP requests, including the GraphQL query string. Depending on your GraphQL schema, the size of a valid query string might be arbitrarily large. As query strings become larger, increased latency and network usage can noticeably degrade client performance. A persisted query is a query string cached on the server-side, along with its unique identifier (SHA-256 hash of the query). Clients can send this identifier instead of the full query string, drastically reducing request sizes.

To make a query string persist, your GraphQL server must first receive it from a requesting client. Each unique query string must therefore be sent to the server at least once. Once a client has sent a query string to persist, any other client executing that query can benefit from APQ.


To improve network performance for large query strings, enable APQ if your GraphQL server supports it.

GraphQL Specific


To mitigate the risks associated with Automatic Persisted Queries (APQs) in the Apollo framework, ensure that you have proper security measures in place. This includes validating and sanitizing all user inputs, implementing a strict Content Security Policy (CSP), and using query whitelisting to allow only predefined queries. Additionally, monitor and rate-limit the APQs to prevent abuse. Keep the Apollo Engine and all dependencies up to date to benefit from the latest security patches.


To mitigate the risks associated with Automatic Persisted Queries in the Yoga framework, ensure that the server only accepts predefined queries. This can be achieved by maintaining a whitelist of allowed query hashes and rejecting any queries that do not match the known hashes. Additionally, implement proper rate limiting and monitoring to detect and prevent abuse.


To mitigate performance issues and reduce network traffic, implement Automatic Persisted Queries (APQs) with AWS AppSync. APQs allow clients to send a short hash instead of the full query, reducing the request size. When the server receives a hash, it retrieves the full query from a cache if available. To enable APQs in AWS AppSync, configure your client to support APQs and modify your AWS AppSync settings to enable caching of the queries. This will improve the efficiency of data retrieval and reduce latency.


To mitigate potential performance issues and improve the security of your GraphQL Go framework engine, implement Automatic Persisted Queries (APQs). APQs allow clients to send a unique identifier generated from the query instead of the full query itself, reducing the size of the request and protecting against certain types of attacks. Ensure that your GraphQL server is configured to handle APQs by storing the mapping between the identifier and the query, and validate the queries to prevent unauthorized operations. This approach also enables caching at the network level, further enhancing the performance and scalability of your GraphQL service.


To mitigate potential performance issues and improve the efficiency of GraphQL queries within the Ruby framework, implement Automatic Persisted Queries (APQs). APQs allow clients to send a unique identifier generated from the query instead of the entire query string, reducing the size of the request. Ensure that the GraphQL-Ruby library is configured to support APQs by integrating with a compatible caching mechanism, such as Redis, to store the mapping between the identifiers and the query strings. This will also help in protecting against certain types of Denial of Service (DoS) attacks that involve sending large and complex queries to the server.


To mitigate the risk of denial-of-service (DoS) attacks when using Automatic Persisted Queries (APQs) with Hasura, ensure that only known queries are allowed by maintaining a list of allowed persisted queries. Implement a strict content security policy, and monitor and rate-limit incoming requests to prevent abuse. Additionally, consider using a unique identifier for each persisted query to avoid collisions and to make it easier to manage the list of allowed queries.


Identifier: configuration/graphql_apq


Ignore this check

skip: true


  • Escape Severity: LOW


  • OWASP: API8:2023
  • pci: 6.5.10
  • gdpr: Article-32
  • soc2: CC1
  • psd2: Article-97
  • iso27001: A.12.6
  • nist: SP800-53
  • fedramp: AC-2



  • CVSS_SCORE: 4.9