
<p>Although many in the industry consider GraphQL a replacement for existing API technologies, it is at its most powerful when used as a central orchestration layer between apps and existing services. This layer, implemented as a federated graph (or <a href="https://www.apollographql.com/blog/announcement/backend/the-supergraph-a-new-way-to-think-about-graphql/">supergraph</a>, for short), acts as a self-service API platform that accelerates development velocity for both frontend and backend teams. However, speed of delivery can’t come at the expense of a strong authorization model that protects personal identifiable information, financial data, and other sensitive information.</p>



<p><a href="https://www.apollographql.com/graphos">Apollo GraphOS</a> provides GraphQL-native workflows to implement access control declaratively across an entire supergraph. Rather than relying only on distributed enforcement or fragile custom gateway logic to secure the graph, teams using GraphOS can enforce policies at the type or field level in their router by decorating schemas with the <code>@requiresScopes</code>, <code>@authenticated</code>, and new <code>@policy</code> directives. These directives provide the freedom to integrate with any authorization system, including policy engines like <a href="https://casbin.org/">Casbin</a> or <a href="https://www.openpolicyagent.org/">Open Policy Agent</a> (OPA). By proactively enforcing policies as code, API platform teams can ensure compliance at all times without sacrificing developer velocity.</p>



<p>These directives are generally available for all GraphOS Enterprise customers starting today.</p>



<h2 class="wp-block-heading"><a href="#durable-auditable-authorization-for-supergraphs" aria-hidden="true" class="aal_anchor" id="durable-auditable-authorization-for-supergraphs"><svg aria-hidden="true" class="aal_svg" height="16" version="1.1" viewBox="0 0 16 16" width="16"><path fill-rule="evenodd" d="M4 9h1v1H4c-1.5 0-3-1.69-3-3.5S2.55 3 4 3h4c1.45 0 3 1.69 3 3.5 0 1.41-.91 2.72-2 3.25V8.59c.58-.45 1-1.27 1-2.09C10 5.22 8.98 4 8 4H4c-.98 0-2 1.22-2 2.5S3 9 4 9zm9-3h-1v1h1c1 0 2 1.22 2 2.5S13.98 12 13 12H9c-.98 0-2-1.22-2-2.5 0-.83.42-1.64 1-2.09V6.25c-1.09.53-2 1.84-2 3.25C6 11.31 7.55 13 9 13h4c1.45 0 3-1.69 3-3.5S14.5 6 13 6z"></path></svg></a>Durable, auditable authorization for supergraphs</h2>



<p>Supergraphs expose a unified, versionless GraphQL endpoint for all connected services. While this offers a host of benefits for frontend development, it makes it tricky to centralize authorization with traditional API gateways designed to enforce policies at the endpoint level. These gateways are unaware of the shape of the supergraph, so policies need to be mapped to individual types and fields with custom logic that must be kept in lockstep coordination with any schema changes.</p>



<p>An authorization model that is instead integrated directly into a supergraph’s schema is far more durable and can still be centrally audited and enforced in the router. <code>@authenticated</code> and <code>@requiresScopes</code>, <a href="https://www.apollographql.com/blog/announcement/backend/build-centralized-graphql-authorization-with-apollo-graphos/">which we launched in preview</a> earlier this year, allow you to define access control policies for types and fields directly in the schema, restricting access to only authenticated requests or requests with certain scopes, respectively. Subgraph developers simply add the directives to the parts of the schema they want to enforce.</p>



<p>For example, let’s say you’re building a simple social media app. The app should allow unauthenticated users to view a post&#8217;s title, author, and content, but only authenticated users to see the number of views a post has received, and only certain users with required permissions to view email addresses. The relevant part of your schema may look something like this:</p>



<pre class="wp-block-prismatic-blocks"><code class="language-graphql">type Query {
  me: User @authenticated 
  post(id: ID!): Post
}

type User {
  id: ID!
  username: String
  email: String @requiresScopes(scopes: [[&quot;read:email&quot;]])
  posts: [Post!]!
}

type Post {
  id: ID!
  author: User!
  title: String!
  content: String!
  views: Int @authenticated 
}</code></pre>



<p>However, many organizations may require more complex policy evaluation and often leverage external tools like OPA or Casbin. For these more complex scenarios, GraphOS now supports a third authorization directive: <code>@policy</code>.</p>



<h2 class="wp-block-heading"><a href="#offload-policy-definition-and-resolution-with-policy" aria-hidden="true" class="aal_anchor" id="offload-policy-definition-and-resolution-with-policy"><svg aria-hidden="true" class="aal_svg" height="16" version="1.1" viewBox="0 0 16 16" width="16"><path fill-rule="evenodd" d="M4 9h1v1H4c-1.5 0-3-1.69-3-3.5S2.55 3 4 3h4c1.45 0 3 1.69 3 3.5 0 1.41-.91 2.72-2 3.25V8.59c.58-.45 1-1.27 1-2.09C10 5.22 8.98 4 8 4H4c-.98 0-2 1.22-2 2.5S3 9 4 9zm9-3h-1v1h1c1 0 2 1.22 2 2.5S13.98 12 13 12H9c-.98 0-2-1.22-2-2.5 0-.83.42-1.64 1-2.09V6.25c-1.09.53-2 1.84-2 3.25C6 11.31 7.55 13 9 13h4c1.45 0 3-1.69 3-3.5S14.5 6 13 6z"></path></svg></a>Offload policy definition and resolution with @policy</h2>



<p>The new <code>@policy</code> directive allows you to integrate your predefined policies from policy engines like OPA and Casbin into your supergraph schema and enforce them in your router. For example, let’s say in your example social media app, you only want users to have access to their own personal information and credit card information. Validating this requires more than the scopes of an access token, so you can use <code>@policy</code> to offload policy resolution for the relevant parts of your schema:</p>



<pre class="wp-block-prismatic-blocks"><code class="language-graphql">type Query {
  me: User @authenticated @policy(policies: [[&quot;read_profile&quot;]])
  post(id: ID!): Post
}

type User {
  id: ID!
  username: String
  email: String @requiresScopes(scopes: [[&quot;read:email&quot;]])
  posts: [Post!]!
  credit_card: String @policy(policies: [[&quot;read_credit_card&quot;]])
}

type Post {
  id: ID!
  author: User!
  title: String!
  content: String!
  views: Int @authenticated
}</code></pre>



<p>The <code>@policy</code> directive allows you to use your supergraph as a central enforcement point for any services you’ve connected to your graph without refactoring the authorization model that you’ve already defined.</p>



<figure class="wp-block-image size-full"><img loading="lazy" decoding="async" width="1600" height="800" src="https://wp.apollographql.com/wp-content/uploads/2023/12/external-policy-diagram.png" alt="" class="wp-image-23033" srcset="https://wp.apollographql.com/wp-content/uploads/2023/12/external-policy-diagram.png 1600w, https://wp.apollographql.com/wp-content/uploads/2023/12/external-policy-diagram-300x150.png 300w, https://wp.apollographql.com/wp-content/uploads/2023/12/external-policy-diagram-1024x512.png 1024w, https://wp.apollographql.com/wp-content/uploads/2023/12/external-policy-diagram-768x384.png 768w, https://wp.apollographql.com/wp-content/uploads/2023/12/external-policy-diagram-1536x768.png 1536w, https://wp.apollographql.com/wp-content/uploads/2023/12/external-policy-diagram-1200x600.png 1200w" sizes="(max-width: 1600px) 100vw, 1600px" /></figure>



<p><code>@policy</code> loosely couples policy enforcement in your GraphOS router and the policy definition in your existing policy engine, giving you the flexibility to evolve how your application resolves policies without altering your GraphQL schema or infrastructure. For example, if your application needs to perform complex authorization validation, such as inspecting specific values in headers, <code>@policy</code> can be used to validate in a coprocessor or Rhai script.&nbsp;</p>



<h2 class="wp-block-heading"><a href="#get-started" aria-hidden="true" class="aal_anchor" id="get-started"><svg aria-hidden="true" class="aal_svg" height="16" version="1.1" viewBox="0 0 16 16" width="16"><path fill-rule="evenodd" d="M4 9h1v1H4c-1.5 0-3-1.69-3-3.5S2.55 3 4 3h4c1.45 0 3 1.69 3 3.5 0 1.41-.91 2.72-2 3.25V8.59c.58-.45 1-1.27 1-2.09C10 5.22 8.98 4 8 4H4c-.98 0-2 1.22-2 2.5S3 9 4 9zm9-3h-1v1h1c1 0 2 1.22 2 2.5S13.98 12 13 12H9c-.98 0-2-1.22-2-2.5 0-.83.42-1.64 1-2.09V6.25c-1.09.53-2 1.84-2 3.25C6 11.31 7.55 13 9 13h4c1.45 0 3-1.69 3-3.5S14.5 6 13 6z"></path></svg></a>Get started</h2>



<p>Schema-driven authorization with <code>@authenticated</code>, <code>@requiresScopes</code>, and <code>@policy</code> is generally available for all GraphOS Enterprise customers today. To start centralizing authorization enforcement with GraphOS, head over to the <a href="https://www.apollographql.com/docs/router/configuration/authorization">Authorization in the Apollo Router documentation</a>.</p>



<p>If you’re new to GraphOS, you can <a href="https://studio.apollographql.com/signup?type=enterprise-trial&amp;_gl=1*1czaoty*_ga*NjU4MjMwOTQ0LjE2MzIxNTUyNDc.*_ga_0BGG5V2W2K*MTcwMTk3NjAwMy4xMDU4LjEuMTcwMTk3NjEwNy4wLjAuMA..">try out GraphOS Enterprise</a> free for 28 days.</p>


Centrally enforce policy as code for GraphQL APIs


<h1 class="wp-block-heading"><a href="#october-12-2023-update" aria-hidden="true" class="aal_anchor" id="october-12-2023-update"><svg aria-hidden="true" class="aal_svg" height="16" version="1.1" viewBox="0 0 16 16" width="16"><path fill-rule="evenodd" d="M4 9h1v1H4c-1.5 0-3-1.69-3-3.5S2.55 3 4 3h4c1.45 0 3 1.69 3 3.5 0 1.41-.91 2.72-2 3.25V8.59c.58-.45 1-1.27 1-2.09C10 5.22 8.98 4 8 4H4c-.98 0-2 1.22-2 2.5S3 9 4 9zm9-3h-1v1h1c1 0 2 1.22 2 2.5S13.98 12 13 12H9c-.98 0-2-1.22-2-2.5 0-.83.42-1.64 1-2.09V6.25c-1.09.53-2 1.84-2 3.25C6 11.31 7.55 13 9 13h4c1.45 0 3-1.69 3-3.5S14.5 6 13 6z"></path></svg></a>October 12, 2023 Update</h1>



<p>Yesterday, the curl project released <a href="https://curl.se/docs/CVE-2023-38545.html">details regarding CVE-2023-38545</a>. We want to provide an update on Apollo&#8217;s impact from this vulnerability.</p>



<p>As mentioned in our original post, Apollo Router, Apollo Client, Apollo Server, Apollo Kotlin, Apollo iOS, and Rover do not rely on curl and are not affected by this vulnerability. The build processes for these projects do utilize curl, but exclusively communicate with trusted domains and are therefore not impacted.</p>



<p>Additionally, as mentioned previously, Apollo provides installation instructions and installers that leverage curl. These installers exclusively communicate with trusted domains and are therefore not impacted. Nevertheless, we strongly encourage customers to consider applying the curl patch to their environments.</p>



<p>In our original post we also discussed GraphOS, which consists of many containerized microservices. Some of the containers that comprise GraphOS do include affected versions of curl. However, Apollo does not use SOCKS5 proxies to manage traffic within the GraphOS environment. As curl&#8217;s maintainers detail, usage of SOCKS5 proxies is a key requirement for exploitation of this CVE. This effectively safeguards GraphOS from exposure to the vulnerability. We will update affected containers as part of our routine vulnerability management processes.</p>



<p>This update contains the latest information we have regarding Apollo&#8217;s impact from this vulnerability and we anticipate that this is our final update. Should any new developments arise, we will promptly communicate them to keep you informed and provide any necessary actions to ensure the security of your systems. Thank you for your continued trust in Apollo.</p>



<h1 class="wp-block-heading"><a href="#original-post" aria-hidden="true" class="aal_anchor" id="original-post"><svg aria-hidden="true" class="aal_svg" height="16" version="1.1" viewBox="0 0 16 16" width="16"><path fill-rule="evenodd" d="M4 9h1v1H4c-1.5 0-3-1.69-3-3.5S2.55 3 4 3h4c1.45 0 3 1.69 3 3.5 0 1.41-.91 2.72-2 3.25V8.59c.58-.45 1-1.27 1-2.09C10 5.22 8.98 4 8 4H4c-.98 0-2 1.22-2 2.5S3 9 4 9zm9-3h-1v1h1c1 0 2 1.22 2 2.5S13.98 12 13 12H9c-.98 0-2-1.22-2-2.5 0-.83.42-1.64 1-2.09V6.25c-1.09.53-2 1.84-2 3.25C6 11.31 7.55 13 9 13h4c1.45 0 3-1.69 3-3.5S14.5 6 13 6z"></path></svg></a>Original Post</h1>



<p>On October 4, 2023, the curl project released a <a href="https://github.com/curl/curl/discussions/12026">pre-announcement for CVE-2023-38545</a>, a high-severity vulnerability found in curl and libcurl. However, the specific details of the vulnerability will not be disclosed until October 11. The curl project maintainers mentioned in their announcement that while this vulnerability will not affect all curl users, it will impact many.</p>



<p>Due to the lack of public details, it is not currently possible to determine who will be impacted by this vulnerability. To provide transparency for our customers, Apollo has conducted an initial review of our projects to identify those that rely on curl. Our goal is to help you understand if any updates for your applications might be necessary if Apollo&#8217;s products are affected.</p>



<p>We have not found usage of curl in any of the following projects:</p>



<ul class="wp-block-list">
<li>Apollo Router. Apollo Router containers prior to version 1.20.0 included curl but did not utilize it at runtime. Starting from version 1.20.0 of the container, curl was removed entirely. Apollo Router binaries also do not rely on curl.</li>



<li>Apollo Client</li>



<li>Apollo Server</li>



<li>Apollo Kotlin</li>



<li>Apollo iOS</li>



<li>Rover</li>
</ul>



<p>Regarding GraphOS Studio:</p>



<ul class="wp-block-list">
<li>GraphOS Studio consists of many microservices. Apollo is currently conducting a review of these microservices to identify any dependencies on curl. Appropriate updates will be applied to the services behind GraphOS Studio to address any impact from this vulnerability.</li>
</ul>



<p>Throughout the build processes for the mentioned projects, Apollo does utilize curl. However, our usage of curl in these processes involves requesting resources from trusted URLs. We do not pass externally-supplied URLs to curl. Depending on the nature of the vulnerability, this approach may help mitigate impact on these systems. Should any impact be discovered, Apollo will update our build processes accordingly.</p>



<p>In our documentation, we frequently provide installation instructions, installers, and code samples that involve invoking curl. These examples directly use curl, but they do not indicate a dependency on curl in our projects. We strongly advise our customers to apply any available updates to curl as they become available.</p>



<p>Once the specific details of the vulnerability are made public, Apollo will conduct additional internal reviews and update this blog post to provide further information and clarity regarding impacts we find. We understand the importance of keeping our customers informed, and we will promptly communicate any relevant updates or actions that need to be taken to address the vulnerability.</p>


Apollo’s Response to CVE-2023-38545


<p>GraphQL provides a self-service developer experience by enabling client teams to fetch all of the data they need with a single query. When implementing GraphQL at scale, it’s important to balance its flexibility with security measures that prevent bad actors from exploiting its self-serve nature.</p>



<p>A supergraph provides a unified but modular approach to GraphQL at scale. Not only does this simplify data fetching for client teams – it has immense benefits around visibility, security, and scalability for the platform teams who support these APIs. By using GraphOS, platform teams can block malicious traffic at the edge of the graph, define both cross-cutting and fine-grained security policies across any number of services, and provide defense in depth.</p>



<p>If you’re running a supergraph with Apollo GraphOS Enterprise, here are three ways you can use GraphOS to better secure the services in your GraphQL API:</p>



<h2 class="wp-block-heading"><a href="#centralize-authorization-in-the-router" aria-hidden="true" class="aal_anchor" id="centralize-authorization-in-the-router"><svg aria-hidden="true" class="aal_svg" height="16" version="1.1" viewBox="0 0 16 16" width="16"><path fill-rule="evenodd" d="M4 9h1v1H4c-1.5 0-3-1.69-3-3.5S2.55 3 4 3h4c1.45 0 3 1.69 3 3.5 0 1.41-.91 2.72-2 3.25V8.59c.58-.45 1-1.27 1-2.09C10 5.22 8.98 4 8 4H4c-.98 0-2 1.22-2 2.5S3 9 4 9zm9-3h-1v1h1c1 0 2 1.22 2 2.5S13.98 12 13 12H9c-.98 0-2-1.22-2-2.5 0-.83.42-1.64 1-2.09V6.25c-1.09.53-2 1.84-2 3.25C6 11.31 7.55 13 9 13h4c1.45 0 3-1.69 3-3.5S14.5 6 13 6z"></path></svg></a>Centralize authorization in the router</h2>



<p>The Apollo Router provides client teams with a central access point for any number of GraphQL services.&nbsp; This isn’t just convenient for client teams – it also provides a policy enforcement point (PEP) for security teams. </p>



<p>Rather than relying on your services to block unauthorized access, GraphOS allows you to proactively and declaratively enforce authentication and authorization centrally in the router for your supergraph. Enforcing authorization in the router reduces the request load on your services by blocking unauthorized requests at the edge of the API stack and eliminates the need for any custom APIM code used to centralize enforcement.</p>



<figure class="wp-block-image size-large"><img loading="lazy" decoding="async" width="1024" height="512" src="https://wp.apollographql.com/wp-content/uploads/2023/10/GraphOS-Authorization-unauthorized-1024x512.png" alt="" class="wp-image-22690" srcset="https://wp.apollographql.com/wp-content/uploads/2023/10/GraphOS-Authorization-unauthorized-1024x512.png 1024w, https://wp.apollographql.com/wp-content/uploads/2023/10/GraphOS-Authorization-unauthorized-300x150.png 300w, https://wp.apollographql.com/wp-content/uploads/2023/10/GraphOS-Authorization-unauthorized-768x384.png 768w, https://wp.apollographql.com/wp-content/uploads/2023/10/GraphOS-Authorization-unauthorized-1536x768.png 1536w, https://wp.apollographql.com/wp-content/uploads/2023/10/GraphOS-Authorization-unauthorized-1200x600.png 1200w, https://wp.apollographql.com/wp-content/uploads/2023/10/GraphOS-Authorization-unauthorized.png 1600w" sizes="(max-width: 1024px) 100vw, 1024px" /></figure>



<p>To set up authz enforcement in your router:</p>



<ol class="wp-block-list">
<li>Ensure that your router is <a href="https://www.apollographql.com/docs/router/enterprise-features/#enabling-enterprise-features">authenticated with your GraphOS Enterprise credentials</a></li>



<li>Configure your router to add claims to requests’ contexts with the Apollo Router’s built-in support for <a href="https://www.apollographql.com/docs/router/configuration/authn-jwt">JWT authentication</a> or with an <a href="https://www.apollographql.com/docs/router/customizations/coprocessor#adding-authorization-claims-via-coprocessor">external coprocessor</a>.</li>



<li>Create a declarative access control model in your schema with the <code>@requiresScopes</code> and <code>@authenticated</code> directives</li>
</ol>



<h2 class="wp-block-heading"><a href="#safelist-registered-operations" aria-hidden="true" class="aal_anchor" id="safelist-registered-operations"><svg aria-hidden="true" class="aal_svg" height="16" version="1.1" viewBox="0 0 16 16" width="16"><path fill-rule="evenodd" d="M4 9h1v1H4c-1.5 0-3-1.69-3-3.5S2.55 3 4 3h4c1.45 0 3 1.69 3 3.5 0 1.41-.91 2.72-2 3.25V8.59c.58-.45 1-1.27 1-2.09C10 5.22 8.98 4 8 4H4c-.98 0-2 1.22-2 2.5S3 9 4 9zm9-3h-1v1h1c1 0 2 1.22 2 2.5S13.98 12 13 12H9c-.98 0-2-1.22-2-2.5 0-.83.42-1.64 1-2.09V6.25c-1.09.53-2 1.84-2 3.25C6 11.31 7.55 13 9 13h4c1.45 0 3-1.69 3-3.5S14.5 6 13 6z"></path></svg></a>Safelist registered operations</h2>



<p>One of the most common objections to GraphQL is that it allows unbounded operations — a trait that can degrade performance or result in denial-of-service if too many complex queries are sent to the endpoint. But in the case that your GraphQL endpoint only serves first-party apps, there is no need for it to allow unbounded operations. Instead, you should reduce the surface area of your graph by only allowing the exact operations required by your applications.&nbsp;</p>



<p>GraphOS allows you to do exactly that by registering and safelisting operations that you trust. Create a list of registered operations in GraphOS Studio, and turn on safelisting in your router to block any non-registered operations. To further improve performance, you can also generate unique IDs for each operation and send only the ID in the request to your router rather than the full query string.</p>



<figure class="wp-block-image size-large"><img loading="lazy" decoding="async" width="1024" height="512" src="https://wp.apollographql.com/wp-content/uploads/2023/10/PQs_new-1-1024x512.png" alt="" class="wp-image-22696" srcset="https://wp.apollographql.com/wp-content/uploads/2023/10/PQs_new-1-1024x512.png 1024w, https://wp.apollographql.com/wp-content/uploads/2023/10/PQs_new-1-300x150.png 300w, https://wp.apollographql.com/wp-content/uploads/2023/10/PQs_new-1-768x384.png 768w, https://wp.apollographql.com/wp-content/uploads/2023/10/PQs_new-1-1536x768.png 1536w, https://wp.apollographql.com/wp-content/uploads/2023/10/PQs_new-1-1200x600.png 1200w, https://wp.apollographql.com/wp-content/uploads/2023/10/PQs_new-1.png 1600w" sizes="(max-width: 1024px) 100vw, 1024px" /></figure>



<h2 class="wp-block-heading"><a href="#limit-operation-complexity" aria-hidden="true" class="aal_anchor" id="limit-operation-complexity"><svg aria-hidden="true" class="aal_svg" height="16" version="1.1" viewBox="0 0 16 16" width="16"><path fill-rule="evenodd" d="M4 9h1v1H4c-1.5 0-3-1.69-3-3.5S2.55 3 4 3h4c1.45 0 3 1.69 3 3.5 0 1.41-.91 2.72-2 3.25V8.59c.58-.45 1-1.27 1-2.09C10 5.22 8.98 4 8 4H4c-.98 0-2 1.22-2 2.5S3 9 4 9zm9-3h-1v1h1c1 0 2 1.22 2 2.5S13.98 12 13 12H9c-.98 0-2-1.22-2-2.5 0-.83.42-1.64 1-2.09V6.25c-1.09.53-2 1.84-2 3.25C6 11.31 7.55 13 9 13h4c1.45 0 3-1.69 3-3.5S14.5 6 13 6z"></path></svg></a>Limit operation complexity</h2>



<p>In addition to safelisting operations, it’s also prudent to enforce general complexity limits on operations to prevent any intentional or unintentional misuse of your graph. For example, allowing operations with thousands of root fields or aliases is neither efficient nor necessary.&nbsp;</p>



<p>With GraphOS, you can implement simple limits on operation depth, height, aliases, and root fields to prevent malformed operations from degrading performance.</p>



<figure class="wp-block-image size-large"><img loading="lazy" decoding="async" width="1024" height="512" src="https://wp.apollographql.com/wp-content/uploads/2023/10/operation_limits_new-1024x512.png" alt="" class="wp-image-22698" srcset="https://wp.apollographql.com/wp-content/uploads/2023/10/operation_limits_new-1024x512.png 1024w, https://wp.apollographql.com/wp-content/uploads/2023/10/operation_limits_new-300x150.png 300w, https://wp.apollographql.com/wp-content/uploads/2023/10/operation_limits_new-768x384.png 768w, https://wp.apollographql.com/wp-content/uploads/2023/10/operation_limits_new-1536x768.png 1536w, https://wp.apollographql.com/wp-content/uploads/2023/10/operation_limits_new-1200x600.png 1200w, https://wp.apollographql.com/wp-content/uploads/2023/10/operation_limits_new.png 1600w" sizes="(max-width: 1024px) 100vw, 1024px" /></figure>



<h2 class="wp-block-heading"><a href="#learn-security-best-practices-at-graphql-summit" aria-hidden="true" class="aal_anchor" id="learn-security-best-practices-at-graphql-summit"><svg aria-hidden="true" class="aal_svg" height="16" version="1.1" viewBox="0 0 16 16" width="16"><path fill-rule="evenodd" d="M4 9h1v1H4c-1.5 0-3-1.69-3-3.5S2.55 3 4 3h4c1.45 0 3 1.69 3 3.5 0 1.41-.91 2.72-2 3.25V8.59c.58-.45 1-1.27 1-2.09C10 5.22 8.98 4 8 4H4c-.98 0-2 1.22-2 2.5S3 9 4 9zm9-3h-1v1h1c1 0 2 1.22 2 2.5S13.98 12 13 12H9c-.98 0-2-1.22-2-2.5 0-.83.42-1.64 1-2.09V6.25c-1.09.53-2 1.84-2 3.25C6 11.31 7.55 13 9 13h4c1.45 0 3-1.69 3-3.5S14.5 6 13 6z"></path></svg></a>Learn security best practices at GraphQL summit</h2>



<p>Join API architects, engineers, and experts from Apollo at <a href="https://summit.graphql.com/event/c51538f6-4b76-44e3-871e-54180c77cad8/websitePage:aa37bf00-dba5-4e19-912a-01aad46f7426">GraphQL Summit</a> October 9-12, 2023 to discuss real-world GraphQL security challenges and best practices. If GraphQL security is your thing, these are a few sessions you won’t want to miss:</p>



<h3 class="wp-block-heading"><a href="#free-graphql-security-consultations-with-doyensec" aria-hidden="true" class="aal_anchor" id="free-graphql-security-consultations-with-doyensec"><svg aria-hidden="true" class="aal_svg" height="16" version="1.1" viewBox="0 0 16 16" width="16"><path fill-rule="evenodd" d="M4 9h1v1H4c-1.5 0-3-1.69-3-3.5S2.55 3 4 3h4c1.45 0 3 1.69 3 3.5 0 1.41-.91 2.72-2 3.25V8.59c.58-.45 1-1.27 1-2.09C10 5.22 8.98 4 8 4H4c-.98 0-2 1.22-2 2.5S3 9 4 9zm9-3h-1v1h1c1 0 2 1.22 2 2.5S13.98 12 13 12H9c-.98 0-2-1.22-2-2.5 0-.83.42-1.64 1-2.09V6.25c-1.09.53-2 1.84-2 3.25C6 11.31 7.55 13 9 13h4c1.45 0 3-1.69 3-3.5S14.5 6 13 6z"></path></svg></a>Free GraphQL security consultations with Doyensec</h3>



<p>Doyensec, the premier GraphQL security consultancy, will be onsite at GraphQL Summit! Stop by on Wednesday, October 11 and Thursday, October 12 for a free consultation to discuss technical security recommendations and engineering best practices with the experts who led the Apollo Router security audits.</p>



<h3 class="wp-block-heading"><a href="#graphql-security-best-practices-and-hardening" aria-hidden="true" class="aal_anchor" id="graphql-security-best-practices-and-hardening"><svg aria-hidden="true" class="aal_svg" height="16" version="1.1" viewBox="0 0 16 16" width="16"><path fill-rule="evenodd" d="M4 9h1v1H4c-1.5 0-3-1.69-3-3.5S2.55 3 4 3h4c1.45 0 3 1.69 3 3.5 0 1.41-.91 2.72-2 3.25V8.59c.58-.45 1-1.27 1-2.09C10 5.22 8.98 4 8 4H4c-.98 0-2 1.22-2 2.5S3 9 4 9zm9-3h-1v1h1c1 0 2 1.22 2 2.5S13.98 12 13 12H9c-.98 0-2-1.22-2-2.5 0-.83.42-1.64 1-2.09V6.25c-1.09.53-2 1.84-2 3.25C6 11.31 7.55 13 9 13h4c1.45 0 3-1.69 3-3.5S14.5 6 13 6z"></path></svg></a>GraphQL Security Best Practices and Hardening</h3>



<p>This talk will discuss, in depth, how to defend against hackers conducting Reconnaissance, Denial of Service, Information Disclosure, Authentication and Authorization Bypass, Injection, Request Forgery and Hijacking, XSS, SQLi and Code Execution.</p>



<h3 class="wp-block-heading"><a href="#understanding-graphql-security-protecting-your-server-from-abuse" aria-hidden="true" class="aal_anchor" id="understanding-graphql-security-protecting-your-server-from-abuse"><svg aria-hidden="true" class="aal_svg" height="16" version="1.1" viewBox="0 0 16 16" width="16"><path fill-rule="evenodd" d="M4 9h1v1H4c-1.5 0-3-1.69-3-3.5S2.55 3 4 3h4c1.45 0 3 1.69 3 3.5 0 1.41-.91 2.72-2 3.25V8.59c.58-.45 1-1.27 1-2.09C10 5.22 8.98 4 8 4H4c-.98 0-2 1.22-2 2.5S3 9 4 9zm9-3h-1v1h1c1 0 2 1.22 2 2.5S13.98 12 13 12H9c-.98 0-2-1.22-2-2.5 0-.83.42-1.64 1-2.09V6.25c-1.09.53-2 1.84-2 3.25C6 11.31 7.55 13 9 13h4c1.45 0 3-1.69 3-3.5S14.5 6 13 6z"></path></svg></a>Understanding GraphQL Security: Protecting Your Server from Abuse</h3>



<p>GraphQL&#8217;s &#8220;ask for what you need and get exactly that&#8221; is great, but it can also be exploited to &#8220;get what they want without your permission and crash your app&#8221;. To protect your GraphQL server, it is important to understand the different ways in which it can be abused.</p>



<h3 class="wp-block-heading"><a href="#supergraph-authz-security-in-apollo-gateway-and-router-with-external-co-processing" aria-hidden="true" class="aal_anchor" id="supergraph-authz-security-in-apollo-gateway-and-router-with-external-co-processing"><svg aria-hidden="true" class="aal_svg" height="16" version="1.1" viewBox="0 0 16 16" width="16"><path fill-rule="evenodd" d="M4 9h1v1H4c-1.5 0-3-1.69-3-3.5S2.55 3 4 3h4c1.45 0 3 1.69 3 3.5 0 1.41-.91 2.72-2 3.25V8.59c.58-.45 1-1.27 1-2.09C10 5.22 8.98 4 8 4H4c-.98 0-2 1.22-2 2.5S3 9 4 9zm9-3h-1v1h1c1 0 2 1.22 2 2.5S13.98 12 13 12H9c-.98 0-2-1.22-2-2.5 0-.83.42-1.64 1-2.09V6.25c-1.09.53-2 1.84-2 3.25C6 11.31 7.55 13 9 13h4c1.45 0 3-1.69 3-3.5S14.5 6 13 6z"></path></svg></a>Supergraph AuthZ Security in Apollo Gateway and Router with External Co-processing</h3>



<p>In an enterprise supergraph like T-Mobile&#8217;s, clients will require fine-grained permissions for different operations and fields. With the flexibility in Apollo Gateway and Router to add external co-processing of requests, attribute-based access control (ABAC) and other customizations can control client traffic at the supergraph entry point.</p>



<h3 class="wp-block-heading"><a href="#observability-and-graphql" aria-hidden="true" class="aal_anchor" id="observability-and-graphql"><svg aria-hidden="true" class="aal_svg" height="16" version="1.1" viewBox="0 0 16 16" width="16"><path fill-rule="evenodd" d="M4 9h1v1H4c-1.5 0-3-1.69-3-3.5S2.55 3 4 3h4c1.45 0 3 1.69 3 3.5 0 1.41-.91 2.72-2 3.25V8.59c.58-.45 1-1.27 1-2.09C10 5.22 8.98 4 8 4H4c-.98 0-2 1.22-2 2.5S3 9 4 9zm9-3h-1v1h1c1 0 2 1.22 2 2.5S13.98 12 13 12H9c-.98 0-2-1.22-2-2.5 0-.83.42-1.64 1-2.09V6.25c-1.09.53-2 1.84-2 3.25C6 11.31 7.55 13 9 13h4c1.45 0 3-1.69 3-3.5S14.5 6 13 6z"></path></svg></a>Observability and GraphQL</h3>



<p>This lab will provide a hands-on tour of observability tools that can be configured in a supergraph. You&#8217;ll learn how to observe the behavior and performance of your supergraph using both GraphOS reporting and cloud-native telemetry.</p>



<p><strong>For a full list of talks on GraphQL security and more, check out the </strong><a href="https://summit.graphql.com/event/c51538f6-4b76-44e3-871e-54180c77cad8/websitePage:aa37bf00-dba5-4e19-912a-01aad46f7426"><strong>GraphQL Summit agenda</strong></a><strong>. We hope to see you there!</strong></p>


Enforcing GraphQL security best practices with GraphOS


<p>Federation unlocks superpowers for our queries, enabling us to split up business logic and improve performance with features like&nbsp;<code>@defer</code>. However, these same powers can be abused if placed in the wrong hands, so it’s essential to limit who has access to them.</p>



<h2 class="wp-block-heading"><a href="#the-threats" aria-hidden="true" class="aal_anchor" id="the-threats"><svg aria-hidden="true" class="aal_svg" height="16" version="1.1" viewBox="0 0 16 16" width="16"><path fill-rule="evenodd" d="M4 9h1v1H4c-1.5 0-3-1.69-3-3.5S2.55 3 4 3h4c1.45 0 3 1.69 3 3.5 0 1.41-.91 2.72-2 3.25V8.59c.58-.45 1-1.27 1-2.09C10 5.22 8.98 4 8 4H4c-.98 0-2 1.22-2 2.5S3 9 4 9zm9-3h-1v1h1c1 0 2 1.22 2 2.5S13.98 12 13 12H9c-.98 0-2-1.22-2-2.5 0-.83.42-1.64 1-2.09V6.25c-1.09.53-2 1.84-2 3.25C6 11.31 7.55 13 9 13h4c1.45 0 3-1.69 3-3.5S14.5 6 13 6z"></path></svg></a>The threats</h2>



<p>Many coordination features of a federated graph rely on an important assumption:&nbsp;<strong>clients always query your router—never individual subgraphs</strong>. If this assumption is violated and clients query your subgraphs directly, you might expose data and capabilities that you&nbsp;<em>shouldn’t</em>:</p>



<ul class="wp-block-list">
<li>The&nbsp;<code>@inaccessible</code>&nbsp;directive enables subgraphs to define schema fields that&nbsp;<em>other</em>&nbsp;subgraphs might need, but that the router&nbsp;<em>shouldn’t&nbsp;</em>expose to clients. If clients can query a subgraph directly, those queries&nbsp;<em>can</em>&nbsp;include&nbsp;<code>@inaccessible</code>&nbsp;fields. And even if you don’t have any sensitive&nbsp;&nbsp;<code>@inaccessible</code>&nbsp;fields in your graph today, you might in the future!</li>



<li>The&nbsp;<code>@requires</code>&nbsp;directive enables a subgraph to define schema fields that depend on entity fields from&nbsp;<em>other</em> subgraphs. Subgraphs rely on the router to resolve this dependency, ensuring that trusted data is provided. But if clients have direct access to subgraph entity resolvers, that data can&nbsp;<em>no longer</em>&nbsp;be trusted.</li>



<li>The&nbsp;<code>@override</code>&nbsp;directive enables a subgraph to take responsibility for a schema field away from&nbsp;<em>another</em> subgraph. With direct subgraph access, clients can still query the&nbsp;<em>original</em>&nbsp;subgraph field, which can result in inconsistent and unexpected behavior.</li>
</ul>



<p>This is just a small selection of the available features today, and more will be added over time. The key takeaway is that federation is a microservice architecture that expects a&nbsp;<em>single</em>&nbsp;entry point through a controlled router. If subgraphs can be accessed directly, it’s only a matter of time before something unexpected happens, and that unexpected event could be a security breach.</p>



<h2 class="wp-block-heading"><a href="#protecting-your-subgraphs" aria-hidden="true" class="aal_anchor" id="protecting-your-subgraphs"><svg aria-hidden="true" class="aal_svg" height="16" version="1.1" viewBox="0 0 16 16" width="16"><path fill-rule="evenodd" d="M4 9h1v1H4c-1.5 0-3-1.69-3-3.5S2.55 3 4 3h4c1.45 0 3 1.69 3 3.5 0 1.41-.91 2.72-2 3.25V8.59c.58-.45 1-1.27 1-2.09C10 5.22 8.98 4 8 4H4c-.98 0-2 1.22-2 2.5S3 9 4 9zm9-3h-1v1h1c1 0 2 1.22 2 2.5S13.98 12 13 12H9c-.98 0-2-1.22-2-2.5 0-.83.42-1.64 1-2.09V6.25c-1.09.53-2 1.84-2 3.25C6 11.31 7.55 13 9 13h4c1.45 0 3-1.69 3-3.5S14.5 6 13 6z"></path></svg></a>Protecting your subgraphs</h2>



<p>Exposing subgraphs publicly opens the door to several attacks. To mitigate them, we prevent anything but our routers from accessing our subgraphs. First, we can protect our subgraphs at the application level by adding an extra layer of authorization on top of whatever user auth may be in place. We can configure our routers to send a header containing a shared secret to each of our subgraphs:</p>



<pre class="wp-block-prismatic-blocks"><code class="language-yaml">headers:
  subgraphs:
    orders:
      request:
        - insert:
          name: &quot;Router-Authorization&quot;
          value: &quot;${env.ORDERS_SUBGRAPH_SECRET}&quot;
    users:
      request:
        - insert:
          name: &quot;Router-Authorization&quot;
          value: &quot;${env.USERS_SUBGRAPH_SECRET}&quot;</code></pre>



<p>Notice that we use a unique secret per subgraph, following a security best practice called “the principle of least privilege”. If there’s no reason for the&nbsp;<code>orders</code>&nbsp;subgraph to have direct access to the&nbsp;<code>users</code>&nbsp;subgraph, then we should not give it the ability to do so (by sending it valid tokens for another subgraph).</p>



<p>These values come from environment variables, so how you set them will depend on where you’re running your routers. Most secret managers have a way to inject values via an environment variable. For example, in GraphOS, you can&nbsp;<a href="https://www.apollographql.com/docs/graphos/routing/cloud-configuration#managing-secrets" target="_blank" rel="noreferrer noopener">set secrets via the UI</a>.</p>



<p>How this looks on the subgraph side depends on your implementation. Here’s an example using FastAPI in Python:</p>



<pre class="wp-block-prismatic-blocks"><code class="language-python">@app.middleware(&quot;http&quot;)
async def check_router_security(
    request: Request, call_next: Callable[[Request], Awaitable[Response]]
) -&gt; Response:
    router_secret = environ.get(&quot;ROUTER_SECRET&quot;)
    if router_secret is None:
        return await call_next(request)
    if request.headers.get(&quot;Router-Authorization&quot;) != router_secret:
        return Response(status_code=HTTPStatus.UNAUTHORIZED)
    return await call_next(request)</code></pre>



<p>Here, we’re setting up the expected token as an environment variable called&nbsp;<code>ROUTER_SECRET</code>&nbsp;in our subgraph. This value would be injected via the secret manager for your hosting platform. If the secret is not set (such as in local development), we turn off this enforcement; you may want to add a more sophisticated method of ensuring this is never turned off in production. If the secret&nbsp;<em>is</em>&nbsp;set, we ensure every request has a matching&nbsp;<code>Router-Authorization</code>&nbsp;header. Requests without a valid header will get a bare response with a&nbsp;<code>401 Unauthorized</code>&nbsp;code—we don’t send any additional information that clients don’t need, and unauthenticated requesters don’t even need to know that this is a GraphQL server.</p>



<p>We have examples for many languages and frameworks in our&nbsp;<a href="https://www.apollographql.com/docs/graphos/graphs/creating-a-subgraph#starting-from-a-template">subgraph templates</a>, so check them out for more inspiration!</p>



<h4 class="wp-block-heading"><a href="#extra-credit-network-protections" aria-hidden="true" class="aal_anchor" id="extra-credit-network-protections"><svg aria-hidden="true" class="aal_svg" height="16" version="1.1" viewBox="0 0 16 16" width="16"><path fill-rule="evenodd" d="M4 9h1v1H4c-1.5 0-3-1.69-3-3.5S2.55 3 4 3h4c1.45 0 3 1.69 3 3.5 0 1.41-.91 2.72-2 3.25V8.59c.58-.45 1-1.27 1-2.09C10 5.22 8.98 4 8 4H4c-.98 0-2 1.22-2 2.5S3 9 4 9zm9-3h-1v1h1c1 0 2 1.22 2 2.5S13.98 12 13 12H9c-.98 0-2-1.22-2-2.5 0-.83.42-1.64 1-2.09V6.25c-1.09.53-2 1.84-2 3.25C6 11.31 7.55 13 9 13h4c1.45 0 3-1.69 3-3.5S14.5 6 13 6z"></path></svg></a>Extra credit: network protections</h4>



<p>As an additional step, depending on your hosting environment, you may be able to use network-level protections to prevent any incoming connections to your subgraphs except your routers. This is typically done via firewall rules (such as access control lists). Not all platforms or architectures will have this option, but if you do, we recommend adding it as a “defense in depth”.&nbsp;</p>



<h2 class="wp-block-heading"><a href="#ruling-out-alternatives" aria-hidden="true" class="aal_anchor" id="ruling-out-alternatives"><svg aria-hidden="true" class="aal_svg" height="16" version="1.1" viewBox="0 0 16 16" width="16"><path fill-rule="evenodd" d="M4 9h1v1H4c-1.5 0-3-1.69-3-3.5S2.55 3 4 3h4c1.45 0 3 1.69 3 3.5 0 1.41-.91 2.72-2 3.25V8.59c.58-.45 1-1.27 1-2.09C10 5.22 8.98 4 8 4H4c-.98 0-2 1.22-2 2.5S3 9 4 9zm9-3h-1v1h1c1 0 2 1.22 2 2.5S13.98 12 13 12H9c-.98 0-2-1.22-2-2.5 0-.83.42-1.64 1-2.09V6.25c-1.09.53-2 1.84-2 3.25C6 11.31 7.55 13 9 13h4c1.45 0 3-1.69 3-3.5S14.5 6 13 6z"></path></svg></a>Ruling out alternatives</h2>



<p>There are a few other solutions to this problem that might&nbsp;<em>seem</em>&nbsp;viable but can cause issues. Let’s go over them!</p>



<p>First, you might be tempted to apply router authorization checks only for federation-specific subgraph fields (<code>_service</code> and&nbsp;<code>_entities</code>&nbsp;), but there are problems with this approach:</p>



<ul class="wp-block-list">
<li>Newer versions of federation might add&nbsp;<em>more</em>&nbsp;subgraph fields in the future, which would introduce new vulnerabilities that special-case checks don’t handle.</li>



<li>This approach doesn’t solve the problem of reaching&nbsp;<code>@inaccessible</code>&nbsp;or&nbsp;<code>@requries</code>&nbsp;fields via a top-level&nbsp;<code>Query</code> field (a standard, non-federated query).</li>
</ul>



<p>Second, you might be tempted to enforce router authorization per field, maybe even automatically for any field that implements a federated directive. However, federation enables any single subgraph to influence the behavior of the entire supergraph. For example, if&nbsp;<code>@inaccessible</code>&nbsp;is applied to a field in&nbsp;<em>any</em>&nbsp;subgraph, it’s expected to be enforced on&nbsp;<em>every</em>&nbsp;subgraph. This means that per-field, per-subgraph enforcement is fundamentally inconsistent and can lead to unexpected data leakage.</p>



<p>Finally, you might consider disabling introspection as a solution—if attackers can’t discover the hidden fields, they can’t use them, right? This is called “security by obscurity” and is widely considered not security at all. A sufficiently determined attacker&nbsp;<em>will</em>&nbsp;eventually guess the names of fields that you don’t want them to find.</p>



<p>The only consistent approach to preventing undesired access to subgraph capabilities is to disable access to subgraphs&nbsp;<em>entirely</em>&nbsp;to any client besides the router.</p>



<h2 class="wp-block-heading"><a href="#get-secure" aria-hidden="true" class="aal_anchor" id="get-secure"><svg aria-hidden="true" class="aal_svg" height="16" version="1.1" viewBox="0 0 16 16" width="16"><path fill-rule="evenodd" d="M4 9h1v1H4c-1.5 0-3-1.69-3-3.5S2.55 3 4 3h4c1.45 0 3 1.69 3 3.5 0 1.41-.91 2.72-2 3.25V8.59c.58-.45 1-1.27 1-2.09C10 5.22 8.98 4 8 4H4c-.98 0-2 1.22-2 2.5S3 9 4 9zm9-3h-1v1h1c1 0 2 1.22 2 2.5S13.98 12 13 12H9c-.98 0-2-1.22-2-2.5 0-.83.42-1.64 1-2.09V6.25c-1.09.53-2 1.84-2 3.25C6 11.31 7.55 13 9 13h4c1.45 0 3-1.69 3-3.5S14.5 6 13 6z"></path></svg></a>Get secure</h2>



<p>Now that you know the dangers of exposing subgraphs publicly and the best approach to mitigating the threat, there’s nothing left to do but start implementing! Start securing your subgraphs immediately.</p>



<p>Have any questions, comments, or concerns about this post? I’d love to hear about it in our <a rel="noreferrer noopener" href="https://discord.com/invite/graphos" target="_blank">Discord server</a>! That&#8217;s also where you&#8217;ll be notified of upcoming security-related live streams.</p>


Secure your GraphQL Microservices


<p>We’re excited to announce that Apollo is now SOC 2 Type II certified, an incredibly important milestone for us that demonstrates the investment we’ve put into building a safe and secure product and organization over the years.&nbsp;</p>



<p>SOC 2 Type II certification is a third-party audit that’s part of the American Institute of CPA’s (AICPA) <a href="https://us.aicpa.org/interestareas/frc/assuranceadvisoryservices/aicpasoc2report">Service Organization Control reporting platform</a>. It’s a necessity for any cloud SaaS business today. In order to achieve SOC 2 compliance, companies like Apollo must undergo a rigorous audit of the security policies and controls it has in place to protect its customers’ data. This certification means that Apollo has written – and operates our business – based on a set of comprehensive information security policies and procedures.</p>



<p>You can request a copy of our Type II audit through your customer success team.</p>



<h2 class="wp-block-heading"><a href="#apollo-values-your-security" aria-hidden="true" class="aal_anchor" id="apollo-values-your-security"><svg aria-hidden="true" class="aal_svg" height="16" version="1.1" viewBox="0 0 16 16" width="16"><path fill-rule="evenodd" d="M4 9h1v1H4c-1.5 0-3-1.69-3-3.5S2.55 3 4 3h4c1.45 0 3 1.69 3 3.5 0 1.41-.91 2.72-2 3.25V8.59c.58-.45 1-1.27 1-2.09C10 5.22 8.98 4 8 4H4c-.98 0-2 1.22-2 2.5S3 9 4 9zm9-3h-1v1h1c1 0 2 1.22 2 2.5S13.98 12 13 12H9c-.98 0-2-1.22-2-2.5 0-.83.42-1.64 1-2.09V6.25c-1.09.53-2 1.84-2 3.25C6 11.31 7.55 13 9 13h4c1.45 0 3-1.69 3-3.5S14.5 6 13 6z"></path></svg></a><strong>Apollo values your security</strong></h2>



<p>One of our core company values is empowering others –&nbsp;setting people up, both inside and outside the company, to do their best work. This certification demonstrates that value by letting our customers know that every bit of information they put into their supergraph is being handled safely and securely. We will continue to focus on, and extend our commitment to security so that,&nbsp;as more and more companies use the supergraph to power the world&#8217;s most important apps, they will know Apollo takes their data security seriously.</p>


Apollo earns SOC 2 Type II compliance

9 Ways To Secure your GraphQL API — GraphQL Security Checklist

Why You Should Disable GraphQL Introspection In Production – GraphQL Security


<p>With GraphQL you can query exactly what you want whenever you want. That is amazing for working with an API, but also has complex security implications. Instead of asking for legitimate, useful data, a malicious actor could submit an expensive, nested query to overload your server, database, network, or all of these. Without the right protections you open yourself up to a DoS (Denial of Service) attack.</p>



<p>For example, in our GraphQL API at&nbsp;<a rel="noreferrer noopener" href="https://spectrum.chat/" target="_blank">Spectrum</a>&nbsp;we have a relationship like this:</p>



<pre class="wp-block-prismatic-blocks"><code class="language-graphql">type Thread {
  messages(first: Int, after: String): [Message]
}

type Message {
  thread: Thread
}

type Query {
  thread(id: ID!): Thread
}</code></pre>



<p>As you can see, you can query both the messages of a thread or the thread of a message. This circular relationship allows a bad actor to construct an expensive nested query like so:</p>



<pre class="wp-block-prismatic-blocks"><code class="language-graphql">query maliciousQuery {
  thread(id: &quot;some-id&quot;) {
    messages(first: 99999) {
      thread {
        messages(first: 99999) {
          thread {
            messages(first: 99999) {
              thread {
                # ...repeat times 10000...
              }
            }
          }
        }
      }
    }
  }
}</code></pre>



<p>Letting this kind of query through is very bad, since it exponentially increases the amount of objects loaded and will crash your entire server. While there are certain mitigations at other layers which make sending the query in the first place a bit harder (e.g. CORS), they can’t fully prevent it from happening.</p>



<h2 class="wp-block-heading" id="2031"><a href="#size-limiting" aria-hidden="true" class="aal_anchor" id="size-limiting"><svg aria-hidden="true" class="aal_svg" height="16" version="1.1" viewBox="0 0 16 16" width="16"><path fill-rule="evenodd" d="M4 9h1v1H4c-1.5 0-3-1.69-3-3.5S2.55 3 4 3h4c1.45 0 3 1.69 3 3.5 0 1.41-.91 2.72-2 3.25V8.59c.58-.45 1-1.27 1-2.09C10 5.22 8.98 4 8 4H4c-.98 0-2 1.22-2 2.5S3 9 4 9zm9-3h-1v1h1c1 0 2 1.22 2 2.5S13.98 12 13 12H9c-.98 0-2-1.22-2-2.5 0-.83.42-1.64 1-2.09V6.25c-1.09.53-2 1.84-2 3.25C6 11.31 7.55 13 9 13h4c1.45 0 3-1.69 3-3.5S14.5 6 13 6z"></path></svg></a>Size Limiting</h2>



<p>A first, naïve approach we considered was to limit the incoming query size by raw bytes. Since the query is sent as a string, a quick length check would suffice:</p>



<pre class="wp-block-prismatic-blocks"><code class="language-javascript">app.use(&#039;*&#039;, (req, res, next) =&gt; {
  const query = req.query.query || req.body.query || &#039;&#039;;
  if (query.length &gt; 2000) {
    throw new Error(&#039;Query too large&#039;);
  }
  next();
});</code></pre>



<p>Unfortunately, that doesn’t work very well in the real world: the check might allow nasty queries using short field names or block legitimate queries using long field names or nested fragments.</p>



<h2 class="wp-block-heading" id="2222"><a href="#query-whitelisting" aria-hidden="true" class="aal_anchor" id="query-whitelisting"><svg aria-hidden="true" class="aal_svg" height="16" version="1.1" viewBox="0 0 16 16" width="16"><path fill-rule="evenodd" d="M4 9h1v1H4c-1.5 0-3-1.69-3-3.5S2.55 3 4 3h4c1.45 0 3 1.69 3 3.5 0 1.41-.91 2.72-2 3.25V8.59c.58-.45 1-1.27 1-2.09C10 5.22 8.98 4 8 4H4c-.98 0-2 1.22-2 2.5S3 9 4 9zm9-3h-1v1h1c1 0 2 1.22 2 2.5S13.98 12 13 12H9c-.98 0-2-1.22-2-2.5 0-.83.42-1.64 1-2.09V6.25c-1.09.53-2 1.84-2 3.25C6 11.31 7.55 13 9 13h4c1.45 0 3-1.69 3-3.5S14.5 6 13 6z"></path></svg></a>Query Whitelisting</h2>



<p>A second approach we considered was to have a whitelist of approved queries we use in our own application, and telling the server to not let any query pass except for those.</p>



<pre class="wp-block-prismatic-blocks"><code class="language-javascript">app.use(&#039;/api&#039;, graphqlServer((req, res) =&gt; {
  const query = req.query.query || req.body.query;
  // TODO: Get whitelist somehow
  if (!whitelist[query]) {
    throw new Error(&#039;Query is not in whitelist.&#039;);
  }
  /* ... */
}));</code></pre>



<p>Maintaining that list of approved queries manually would obviously be a pain, but thankfully the Apollo team created&nbsp;<a rel="noreferrer noopener" href="https://github.com/apollographql/persistgraphql" target="_blank">persistgraphql</a>, which automatically extracts all queries from your client-side code and generates a nice JSON file out of it.</p>



<pre class="wp-block-prismatic-blocks"><code class="language-json">{
  &quot;scripts&quot;: {
    &quot;postbuild&quot;: &quot;persistgraphql src api/query-whitelist.json&quot;
  }
}</code></pre>



<p>This technique works beautifully and will block all vicious queries reliably. Unfortunately, it also has two major tradeoffs:</p>



<ol class="wp-block-list">
<li><strong>We can never change or delete queries, only add new ones</strong><strong>:</strong>&nbsp;if any user is running an outdated client we can’t just block their request. We’d likely have to keep a history of all queries ever used in production which is a lot more complex.</li>



<li><strong>We cannot open our API to the public:</strong>&nbsp;sometime in the future we’d like to open up our API to the public so that other developers can build their interpretation of what the Spectrum interface could look like. If we only let a whitelist of queries through that severely limits their options already and defeats the point of having a GraphQL API (super flexible system restrained by a synthetic whitelist).</li>
</ol>



<p>Those were constraints we couldn’t work with, so we went back to the drawing board.</p>



<h2 class="wp-block-heading" id="66f5"><a href="#depth-limiting" aria-hidden="true" class="aal_anchor" id="depth-limiting"><svg aria-hidden="true" class="aal_svg" height="16" version="1.1" viewBox="0 0 16 16" width="16"><path fill-rule="evenodd" d="M4 9h1v1H4c-1.5 0-3-1.69-3-3.5S2.55 3 4 3h4c1.45 0 3 1.69 3 3.5 0 1.41-.91 2.72-2 3.25V8.59c.58-.45 1-1.27 1-2.09C10 5.22 8.98 4 8 4H4c-.98 0-2 1.22-2 2.5S3 9 4 9zm9-3h-1v1h1c1 0 2 1.22 2 2.5S13.98 12 13 12H9c-.98 0-2-1.22-2-2.5 0-.83.42-1.64 1-2.09V6.25c-1.09.53-2 1.84-2 3.25C6 11.31 7.55 13 9 13h4c1.45 0 3-1.69 3-3.5S14.5 6 13 6z"></path></svg></a>Depth Limiting</h2>



<p>One harmful aspect of the malicious query above is the nesting, classified by its&nbsp;<em>depth</em>, which makes the query exponentially more expensive. Each layer adds a lot more work for your backend, which can quickly add up when combined with lists.</p>



<p>We looked around and found&nbsp;<a rel="noreferrer noopener" href="https://github.com/stems/graphql-depth-limit" target="_blank">graphql-depth-limit</a>, a lovely module by&nbsp;<a rel="noreferrer noopener" href="https://twitter.com/acarl005" target="_blank">Andrew Carlson</a>, which enables us to easily limit the maximum depth of incoming queries. We checked our client and the deepest query we use has 7 levels, so we went with a (quite lenient) maximum depth of 10 and added it to our validation rules:</p>



<pre class="wp-block-prismatic-blocks"><code class="language-javascript">app.use(&#039;/api&#039;, graphqlServer({
  validationRules: [depthLimit(10)]
}));</code></pre>



<p>That’s how simple depth limiting is!</p>



<h2 class="wp-block-heading" id="1a60"><a href="#amount-limiting" aria-hidden="true" class="aal_anchor" id="amount-limiting"><svg aria-hidden="true" class="aal_svg" height="16" version="1.1" viewBox="0 0 16 16" width="16"><path fill-rule="evenodd" d="M4 9h1v1H4c-1.5 0-3-1.69-3-3.5S2.55 3 4 3h4c1.45 0 3 1.69 3 3.5 0 1.41-.91 2.72-2 3.25V8.59c.58-.45 1-1.27 1-2.09C10 5.22 8.98 4 8 4H4c-.98 0-2 1.22-2 2.5S3 9 4 9zm9-3h-1v1h1c1 0 2 1.22 2 2.5S13.98 12 13 12H9c-.98 0-2-1.22-2-2.5 0-.83.42-1.64 1-2.09V6.25c-1.09.53-2 1.84-2 3.25C6 11.31 7.55 13 9 13h4c1.45 0 3-1.69 3-3.5S14.5 6 13 6z"></path></svg></a>Amount Limiting</h2>



<p>The second harmful aspect of the query above is fetching 99999 of an object. No matter what that object is, fetching a ton of it will always be expensive. (Although the database stress might be mitigated by DataLoader, the network and processing stress won’t)</p>



<p>Instead of setting the type of the first argument to Int (which allows any arbitrary number) we have a custom scalar created with&nbsp;<a rel="noreferrer noopener" href="https://github.com/joonhocho/graphql-input-number" target="_blank">graphql-input-number</a>, that restricts the maximum value to 100:</p>



<pre class="wp-block-prismatic-blocks"><code class="language-javascript">const PaginationAmount = GraphQLInputInt({
  name: &#039;PaginationAmount&#039;,
  min: 1,
  max: 100,
});</code></pre>



<p>This will throw an error, if anybody queries for more than 100 objects. We then use that across our API anywhere we have a connection:</p>



<pre class="wp-block-prismatic-blocks"><code class="language-graphql">type Thread {
  messages(first: PaginationAmount, after: String): [Message]
}</code></pre>



<p>Now we’ve entirely prevented the malicious query from above! 🎉</p>



<h2 class="wp-block-heading" id="9e7f"><a href="#query-cost-analysis" aria-hidden="true" class="aal_anchor" id="query-cost-analysis"><svg aria-hidden="true" class="aal_svg" height="16" version="1.1" viewBox="0 0 16 16" width="16"><path fill-rule="evenodd" d="M4 9h1v1H4c-1.5 0-3-1.69-3-3.5S2.55 3 4 3h4c1.45 0 3 1.69 3 3.5 0 1.41-.91 2.72-2 3.25V8.59c.58-.45 1-1.27 1-2.09C10 5.22 8.98 4 8 4H4c-.98 0-2 1.22-2 2.5S3 9 4 9zm9-3h-1v1h1c1 0 2 1.22 2 2.5S13.98 12 13 12H9c-.98 0-2-1.22-2-2.5 0-.83.42-1.64 1-2.09V6.25c-1.09.53-2 1.84-2 3.25C6 11.31 7.55 13 9 13h4c1.45 0 3-1.69 3-3.5S14.5 6 13 6z"></path></svg></a>Query Cost Analysis</h2>



<p>Unfortunately, there’s still a potential to overwhelm the server under the right conditions: there are certain app-specific queries that are neither too deep nor request too many objects but are still very expensive. For us at Spectrum, such a query could look like this:</p>



<pre class="wp-block-prismatic-blocks"><code class="language-graphql">query evilQuery {
  thread(id: &quot;54887141-57a9-4386-807c-ed950c4d5132&quot;) {
    messageConnection(first: 100) { ... }
    participants(first: 100) {
      threadConnection(first: 100) { ... }
      communityConnection { ... }
      channelConnection { ... }
      everything(first: 100) { ... }
    }
  }
}</code></pre>



<p>Neither the depth nor the individual amounts are exceptionally high in this query, so it would pass through our current protections. Yet, it potentially fetches tens of thousands of records, meaning it’s intensive on the database, server and network, a worst-case scenario.</p>



<p>To prevent this we would need to analyze queries before we run them to calculate their complexity and block them if were too expensive. While this is more work than both of our previous protections, it’ll make 100% sure no malicious query can get to our resolvers.</p>



<p><strong>Before you go ahead and spend a ton of time implementing query cost analysis be certain you need it.</strong>&nbsp;Try to crash or slow down your staging API with a nasty query and see how far you get — maybe your API doesn’t have these kinds of nested relationships, or maybe it can handle fetching thousands of records at a time perfectly fine and doesn’t need query cost analysis!</p>



<p>I ran the above query locally on my maxed-out 2017 MacBook Pro and it took our API server a good 10–15 seconds to respond with a megabyte of JSON. We really need it since we never want anybody bombarding our API with that. (<a href="https://developer.github.com/v4/guides/resource-limitations/" target="_blank" rel="noreferrer noopener">The GitHub GraphQL API also uses Query Cost Analysis</a>)</p>



<h3 class="wp-block-heading" id="6723"><a href="#implementing-query-cost-analysis" aria-hidden="true" class="aal_anchor" id="implementing-query-cost-analysis"><svg aria-hidden="true" class="aal_svg" height="16" version="1.1" viewBox="0 0 16 16" width="16"><path fill-rule="evenodd" d="M4 9h1v1H4c-1.5 0-3-1.69-3-3.5S2.55 3 4 3h4c1.45 0 3 1.69 3 3.5 0 1.41-.91 2.72-2 3.25V8.59c.58-.45 1-1.27 1-2.09C10 5.22 8.98 4 8 4H4c-.98 0-2 1.22-2 2.5S3 9 4 9zm9-3h-1v1h1c1 0 2 1.22 2 2.5S13.98 12 13 12H9c-.98 0-2-1.22-2-2.5 0-.83.42-1.64 1-2.09V6.25c-1.09.53-2 1.84-2 3.25C6 11.31 7.55 13 9 13h4c1.45 0 3-1.69 3-3.5S14.5 6 13 6z"></path></svg></a>Implementing Query Cost Analysis</h3>



<p>There are a couple of packages on npm to implement query cost analysis. Our two front-runners were&nbsp;<a href="https://github.com/4Catalyzer/graphql-validation-complexity" target="_blank" rel="noreferrer noopener">graphql-validation-complexity</a>, a plug-n-play module, or&nbsp;<a href="https://github.com/pa-bru/graphql-cost-analysis" target="_blank" rel="noreferrer noopener">graphql-cost-analysis</a>, which gives you more control by letting you specify a @cost directive. There’s also&nbsp;<a href="https://github.com/ivome/graphql-query-complexity" target="_blank" rel="noreferrer noopener">graphql-query-complexity</a>, but I wouldn’t recommend choosing it over graphql-cost-analysis since it’s the same idea without directive or multiplier support.</p>



<p>We went with&nbsp;<a href="https://github.com/pa-bru/graphql-cost-analysis" target="_blank" rel="noreferrer noopener">graphql-cost-analysis</a>&nbsp;because we have a large discrepancy between our fastest resolvers (20μs) and our slowest ones (10s+), so we needed the control we got from it. That being said, maybe graphql-validation-complexity is enough for you, try it out for sure!</p>



<p>The way it works is that you specify the relative cost of resolving a certain field or type. It also has multiplication support, so if you requested a list any nested field within would be multiplied by the pagination amount, which is very neat.</p>



<p>This is what the @cost directive looks like in practice:</p>



<pre class="wp-block-prismatic-blocks"><code class="language-graphql">type Participant {
  # The complexity of getting one thread in a thread connection is 3, and multiply that by the amount of threads fetched
  threadConnection(first: PaginationAmount, after: String): ThreadConnection @cost(complexity: 3, multipliers: [&quot;first&quot;])
}

type Thread {
  author: Author @cost(complexity: 1)
  participants(first: PaginationAmount,...): [Participant] @cost(complexity: 2, multipliers: [&quot;first&quot;])
}</code></pre>



<p>This is just a snippet of our API types, but you get the point. You specify how complex a certain field is, which argument to multiply by and the maximum cost and graphql-cost-analysis does the rest for you.</p>



<p>I determined how complex certain resolvers are via the performance tracking data exposed by <a href="https://studio.apollographql.com/signup?referrer=blog">Apollo Studio</a>. I went through the entire schema and assigned a value based on the p99 service time. Then we looked through all the queries on our client to figure out the most expensive one, which got ~500 complexity points. To give us a bit of leeway for the future we set the maximum complexity to 750.</p>



<p>Running the evilQuery from above, now that we’ve added graphql-cost-analysis, I get an error message telling me that the “GraphQL query exceeds maximum complexity, please remove some nesting or fields and try again. (max: 750, actual: 1010319)”</p>



<p><strong>1 million complexity points? Rejected!</strong></p>



<h2 class="wp-block-heading" id="c620"><a href="#summary" aria-hidden="true" class="aal_anchor" id="summary"><svg aria-hidden="true" class="aal_svg" height="16" version="1.1" viewBox="0 0 16 16" width="16"><path fill-rule="evenodd" d="M4 9h1v1H4c-1.5 0-3-1.69-3-3.5S2.55 3 4 3h4c1.45 0 3 1.69 3 3.5 0 1.41-.91 2.72-2 3.25V8.59c.58-.45 1-1.27 1-2.09C10 5.22 8.98 4 8 4H4c-.98 0-2 1.22-2 2.5S3 9 4 9zm9-3h-1v1h1c1 0 2 1.22 2 2.5S13.98 12 13 12H9c-.98 0-2-1.22-2-2.5 0-.83.42-1.64 1-2.09V6.25c-1.09.53-2 1.84-2 3.25C6 11.31 7.55 13 9 13h4c1.45 0 3-1.69 3-3.5S14.5 6 13 6z"></path></svg></a>Summary</h2>



<p>To summarize, I’d recommend using Depth and Amount Limiting as the minimum protection for any GraphQL API — they’re easy to implement and will give ample safety. Depending on your specific security requirements and schema, you might also want to investigate Query Cost Analysis. While it is a bit more work than the other tools, it does provide full coverage in the defense against malicious actors.</p>



<hr class="wp-block-separator has-css-opacity"/>



<p><a href="https://spectrum.chat/thread/dc17eab7-fe14-44de-967b-79d5e6ab6e6a" target="_blank" rel="noreferrer noopener"><em>Discuss this post in the GraphQL community on Spectrum</em></a></p>


GraphQL

Centrally enforce policy as code for GraphQL APIs

Apollo’s Response to CVE-2023-38545

Enforcing GraphQL security best practices with GraphOS

Secure your GraphQL Microservices

Apollo earns SOC 2 Type II compliance

9 Ways To Secure your GraphQL API — GraphQL Security Checklist

Why You Should Disable GraphQL Introspection In Production – GraphQL Security

Past posts

Securing Your GraphQL API from Malicious Queries

GraphQL

Centrally enforce policy as code for GraphQL APIs

Apollo’s Response to CVE-2023-38545

Enforcing GraphQL security best practices with GraphOS

Secure your GraphQL Microservices

Apollo earns SOC 2 Type II compliance

9 Ways To Secure your GraphQL API — GraphQL Security Checklist

Why You Should Disable GraphQL Introspection In Production – GraphQL Security

Past posts

Securing Your GraphQL API from Malicious Queries

Stay in our orbit