large_blog_intellyx_platform_innovation.webp

medium_blog_intellyx_platform_innovation.webp

small_blog_intellyx_platform_innovation.webp

thumbnail_blog_intellyx_platform_innovation.webp

blog_intellyx_platform_innovation.webp

We’re proud to announce that the Inigo platform has earned the 2023 Intellyx Digital Innovator Award.

We’re proud to announce that the Inigo platform has [earned the 2023 Intellyx Digital Innovator Award](https://intellyx.com/2023/05/22/inigo-wins-the-2023-digital-innovator-award-from-intellyx/) from enterprise analyst firm Intellyx. The award adds to Inigo’s recent recognition from DevOps.com, in the Best New DevOps Tools Provider category.

As our customers know, Inigo’s solution for end-to-end GraphQL API management and security quickly becomes a must-have toolset. From query production and rate limiting to schema checks and lifecycle management, Inigo is built to accelerate our customers’ GraphQL deployments as efficiency, securely, and cost-effectively as possible.

We’re excited to roll out even more features and capabilities this year, providing a complete one-stop shop for enterprise GraphQL security and management at scale.


Inigo Earns New Analyst Recognition for Platform Innovation

large_1_inigo_aws_appsync_header.webp

medium_1_inigo_aws_appsync_header.webp

small_1_inigo_aws_appsync_header.webp

thumbnail_1_inigo_aws_appsync_header.webp

1_inigo_aws_appsync_header.webp

We are excited to announce Inigo’s integration with AWS AppSync. This integration allows you to add in-depth GraphQL analytics to your AppSync instance in just a few straightforward steps.

We are excited to announce Inigo’s integration with AWS AppSync. This integration allows you to add in-depth GraphQL analytics to your AppSync instance in just a few straightforward steps. 

## The Challenge: Unveiling AppSync to the World

AWS AppSync is a fully managed “GraphQL-as-a-service” platform that abstracts away much of the grunt work involved in building GraphQL APIs. For example, AppSync handles the parsing and resolution of requests as well as the connections to other services, data stores, and APIs.

Developers predominantly use AppSync to quickly and robustly build internal GraphQL APIs, that are then consumed by internal clients within the same network or cloud environment. But sometimes organizations want to turn their internal AppSync APIs into public-facing external APIs. This means making the AppSync GraphQL API endpoint accessible over the internet.

Exposing your API endpoint to the world, so that other applications and users can interact with it, can be nerve-wracking. To do so in a safe, secure, performant way requires that you have more visibility into who is hitting your API, how often, and which parts of your schema can be optimized. 

This is exactly what Inigo provides in our comprehensive GraphQL management platform.

## The Solution: Add Inigo to your AppSync instance

Inigo provides enhanced security and detailed analytics for your AppSync service. With Inigo, you get out-of-the-box features like:

### Query-level inspection and analytics

Inigo’s platform lets you dive deep into individual queries. From the analytics dashboard, you can easily check for high-latency queries and track down specific user bugs.

![2_inigo_aws_appsync_query.webp](/uploads/2_inigo_aws_appsync_query_df4365c643.webp)

### Error breakdowns

On the Inigo dashboard, you’re able to see a breakdown of common errors. You are also able to filter queries based on whether they responded with an error.

![3_inigo_aws_appsync_errros.webp](/uploads/3_inigo_aws_appsync_errros_0d0644571a.webp)

### Performance metrics
Inigo makes it easy to identify resource-heavy or unused objects in your schema.

![4_inigo_aws_appsync_analytics.webp](/uploads/4_inigo_aws_appsync_analytics_d74aeed835.webp)

### Actionable alerts

Inigo automatically surfaces errors in mission-critical objects and mutations and routes them to the appropriate team.

### Access control 
Inigo makes it easy for you to add role-based access control to your AppSync server, by writing declarative config.

![5_inigo_aws_appsync_invalid_access.webp](/uploads/5_inigo_aws_appsync_invalid_access_e70087df62.webp)

### Rate-limiting

Inigo uses object-based rate limiting - counting each query’s requested objects and returned objects against a time frame limit (e.g. 1000 objects per minute). This protects your AppSync server against potential performance degradation while still maintaining flexibility.

Altogether, this information helps ensure that your AppSync API is secure against potential abusers and optimized for production. Finally, Inigo can scale to support the highest volume of GraphQL messages for large enterprises.


## How to connect Inigo and AWS AppSync

### 1. Create an Inigo Service

To create a new Inigo service, head to [app.inigo.io](https://app.inigo.io) and open the service configuration menu under the Settings icon on the top navigation.

![6_inigo_aws_appsync_service_create.webp](/uploads/6_inigo_aws_appsync_service_create_b6aeb85e75.webp)

On the next page, choose the “Docker Standalone” option, decide on a service name and label, and proceed to save the INIGO_SERVICE_TOKEN value for later use.

![7_inigo_aws_appsync_service_type.webp](/uploads/7_inigo_aws_appsync_service_type_2f827746dc.webp)

![8_inigo_aws_appsync_service_name.webp](/uploads/8_inigo_aws_appsync_service_name_84e43838d3.webp)

## AWS Marketplace

### 2. Subscribe to the AWS Inigo Agent

Navigate to the Inigo GraphQL Analytics product page in [AWS Marketplace](https://aws.amazon.com/marketplace/pp/prodview-lmo76xfvzarck). Hit the "Continue to Subscribe" button and accept the terms and conditions. 

On the configuration page, select “Cloudformation stack for AppSync”, and the latest version, from the dropdown menus, then hit the “Continue to Launch” button.

![9_inigo_aws_appsync_marketplace.webp](/uploads/9_inigo_aws_appsync_marketplace_cfdbc4d771.webp)

### 3. Deploy the AWS Agent Stack

Here, you'll only need:

1. The previously stored INIGO_SERVICE_TOKEN
2. Your AppSync GraphQL endpoint and its API Key

Follow the instructions [here](https://docs.inigo.io/deployment/aws_appsync#aws-agent-stack-deployment) to deploy an AWS agent stack.

At the end of this step, you will have deployed an Inigo agent. You may use the built-in playground or any preferred client to start sending queries.

![10_inigo_aws_appsync_playground.webp](/uploads/10_inigo_aws_appsync_playground_66de0efa20.webp)

After making a few requests, you should be able to see your analytic data with [Inigo’s dashboards](https://app.inigo.io).

![11_inigo_aws_appsync_aws_data_home.webp](/uploads/11_inigo_aws_appsync_aws_data_home_6efd9876d7.webp)

![12_inigo_aws_appsync_aws_data_analytics.webp](/uploads/12_inigo_aws_appsync_aws_data_analytics_65309d0fcf.webp)

## Get started with Inigo and AppSync

Visit [Inigo's documentation](https://docs.inigo.io/deployment/aws_appsync#aws-agent-stack-deployment) for more information on how to get started adding Inigo to your AppSync instance for powerful GraphQL analytics.

You can [sign up for Inigo](https://app.inigo.io/signup) directly or [schedule a demo](https://inigo.io/demo). The initial setup is free, so you can start gaining in-depth query analytics and performance metrics for your AppSync service without any charge.







NEW: Inigo's integration with AWS AppSync

large_graphql_in_development.webp

medium_graphql_in_development.webp

small_graphql_in_development.webp

thumbnail_graphql_in_development.webp

graphql_in_development.webp

As applications evolve over time, it's essential for their GraphQL APIs to keep pace with these changes.

## Overview

As applications evolve over time, it's essential for their GraphQL APIs to keep pace with these changes. In this blog post, we provide best practices for different aspects of the GraphQL development pipeline, including schema planning, schema checks, and performance optimization.

## Managing schemas

GraphQL was built on the principle that each client should only retrieve the data it requires, effectively addressing the over-fetching issue. This approach anticipates that your API will be consumed by a wide range of clients, so that existing client queries should continue to function properly even as you expand and update your graph.
It’s therefore important to determine which changes are permissible and which might break your schema.

### Handling schema-breaking changes
A schema-breaking in a GraphQL schema is an update that causes the API contract to change in a way that is not backward-compatible. To better understand this concept, let's consider an example.
Imagine you have a simple schema with a single query to fetch a user by ID, which returns a user type containing two fields: id and name. Your business then decides that they want to split the name field into two separate fields: firstName and lastName. You might be tempted to remove the name field and replace it with firstName and lastName, but doing so would break any existing clients relying on the name field.
```
# Original schema
type User {
  id: ID!
  name: String!
}

# Breaking change schema
type User {
  id: ID!
  firstName: String!
  lastName: String!
}
```
Instead, you can make this change in a backward-compatible manner by using the @deprecated directive. This allows you to indicate that the name field is deprecated in favor of the new firstName and lastName fields.
```
# Backward-compatible schema
type User {
  id: ID!
  name: String! @deprecated(reason: "Use firstName and lastName instead")
  firstName: String!
  lastName: String!
}
```
When you need to introduce schema-breaking changes, follow these four steps to minimize their impact: add, deprecate, migrate, and remove. 

![development_flow.webp](/uploads/development_flow_6e6ed8fef3.webp)

In our example, we already added the new fields and deprecated the old one. Now, let's go through the remaining steps:

- **Migrate:** At this stage, it's crucial to update all the clients consuming this API to stop using the deprecated fields and start using the newly added fields. Once this migration is complete, deploy the updated versions of your website and applications.
- **Remove:** Once you're confident that there are no more clients that are using the deprecated fields anymore, you can safely remove them from the schema. In our example, you would remove the name field from the User type and deploy the new version of the API.

How can you be confident that no clients are using the deprecated fields anymore? This is where Inigo’s GraphQL Gateway can help. Inigo highlights the usage of each GraphQL object and tags them by client so you get visibility to your APIs usage in depth.
By providing insights into usage patterns and real traffic data, developers using Inigo are empowered to plan their schema roadmaps effectively. 

### Schema checks

While the example shown above assumes that the developer already knows that adding firstName and lastName can potentially break the schema, in other cases, it’s not so clear. This is where GraphQL schema checks can be helpful. GraphQL schema checks help developers identify and prevent breaking changes in the schema, such as field removals or type modifications.

Schema checks for GraphQL are typically implemented by using tools and libraries designed for this purpose, and then integrating them into your development workflow and CI/CD pipeline. Here's an overview of the process:
1. **Choose a tool or library for schema checking:** there are several popular tools for GraphQL schema checks, such as GraphQL Inspector, Apollo Engine, or Inigo. These tools can compare the current schema with the proposed changes and report any breaking changes or potential issues.
2. **Implement schema checks in development:** during development, use the tool you chose to validate schema changes locally, ensuring that breaking changes are detected early in the development process. Developers can also use these tools to validate queries and mutations against the schema to guarantee their correctness.
3. **Integrate schema checks into your CI/CD pipeline:** add schema checks to your continuous integration (CI) and continuous deployment (CD) pipelines. This can be done using plugins, scripts, or pre-built integrations with popular CI/CD platforms like GitHub Actions, GitLab CI, Jenkins, or CircleCI. Whenever code changes are pushed or pull requests are created, the CI system will automatically perform schema checks and report any issues before the code is merged and deployed.
4. **Monitor and review schema changes:** configure the schema check tool to generate reports, logs, or notifications when breaking changes are detected. This enables your team to review the changes and decide on the best course of action, such as fixing the issue, updating client applications to handle the change, or reverting the change entirely.

Let's consider a scenario where you have an existing GraphQL schema for an e-commerce application, and a developer wants to make changes to the User type. 
Here's the initial schema:
```
type User {
  id: ID!
  name: String
  age: String
  email: String
}
```
The developer decides to change the age field from a String to an Int. They update the schema as follows:
```
type User {
  id: ID!
  name: String
  age: Int # type used to be String
  email: String
}
```
Inigo will alert you to any clients that are still using age as a String.

![illustration_graphql.webp](/uploads/illustration_graphql_e68c9fd0b7.webp)

## Subgraph visibility for different teams 

In GraphQL, subgraph visibility refers to the ability to control access to specific parts of a schema, such as types or fields, based on the client or user's permissions. Managing subgraph visibility is crucial for maintaining data security and privacy in a GraphQL API, as it helps prevent unauthorized access to sensitive data or internal implementation details. To implement subgraph visibility, developers can use a combination of schema directives and custom middleware, such as GraphQL Shield or custom resolvers, to conditionally expose or hide certain parts of the schema based on the client's authorization levels (typically controlled by a security orchestration product).
With Inigo, subgraph visibility is built in.

![dropdown_56.webp](/uploads/dropdown_56_f064d186c4.webp)

## Finding performance issues

### Identifying resource-heavy and/or unused objects in schemas

In GraphQL, identifying resource-heavy queries and types is crucial for optimizing performance and minimizing unnecessary data retrieval. 
Similarly, identifying unused objects is also important, as it can result in unnecessary costs for data sources in terms of lookup and computation.
Identifying these “long-tail” objects typically involves:
1. **Query logging:** Set up logging for your GraphQL server to capture information about incoming queries, including execution time, response size, and any errors. This data will help you identify slow-performing or resource-intensive queries.
2. **Query complexity analysis:** Calculate the complexity of each query. A high complexity score may indicate that a query is resource-intensive and may need optimization.
3. **Monitoring server metrics:** Keep an eye on server metrics like CPU usage, memory consumption, and response time. Spikes in these metrics could signal that certain queries or types are putting excessive strain on your server.
4. **Field usage tracking:** Identify which fields are frequently requested and which are rarely used.

![analytics (1).webp](/uploads/analytics_1_881accdabb.webp)

## Conclusion

The growing adoption of GraphQL in production environments highlights the importance of integrating it seamlessly into the development pipeline. As organizations face new challenges, such as schema planning, schema optimization, query monitoring, and [error handling](https://inigo.io/blog/graphql_error_handling), Inigo provides a valuable solution to what would otherwise be unscalable and costly development cycles. 
Rather than functioning as a GraphQL server, Inigo offers a comprehensive suite of tools designed to contextualize GraphQL traffic, deliver granular query-level analytics, and ensure that dev teams have all the information they need to maintain a clean and efficient schema.





GraphQL in development

large_Expedite Your GraphQL Roadmap.webp

medium_Expedite Your GraphQL Roadmap.webp

small_Expedite Your GraphQL Roadmap.webp

thumbnail_Expedite Your GraphQL Roadmap.webp

Expedite Your GraphQL Roadmap.webp

The enterprise path to full-fledged GraphQL adoption in production —and API modernization at scale—often begins with a single developer or a single API in the journey of digital transformation.

## Overview

The enterprise path to full-fledged GraphQL adoption in production —and API modernization at scale—often begins with a single developer or a single API in the journey of digital transformation.

That developer recognizes the advantages of the GraphQL open source API query language for workflow efficiency, and begins championing it within the organization. If you’re reading this, you may be that champion.

You understand GraphQL’s vast potential to accelerate application development and expedite roadmaps. You’re the one telling every colleague you can how GraphQL allows applications to collect all required data within a singular API request, and how GraphQl can do that with speed and control that REST APIs can’t match.

If you find yourself in this champion role, however, you may have also already encountered a few all-too-common roadblocks to your ideal GraphQL adoption roadmap. For those newer to GraphQL, here are some obstacles you might come across—and how to navigate them.

## Obstacle #1 for GraphQL champions: the myth that “GraphQL is not mature enough for enterprises”

First of all, starting out with GraphQL isn’t the hard part. Developers can deploy a GraphQL server and get going pretty darn easily. The harder challenge is winning organizational buy-in and standing up a stable, secure, and enduring enterprise-grade implementation.

An early obstacle to enterprise GraphQL adoption—which its champions must address head-on—is the perception that it isn’t ready for primetime. Skeptical stakeholders within your organization may claim that GraphQL isn’t mature enough for enterprise use cases. If you deploy GraphQL in a haphazard and unsustainable manner that also makes it an easy target for hackers, you’re all but doomed to failure. It’s dangerous to the future of GraphQL at your organization if you end up making the skeptics look like they’re right. That’s why it’s crucial it deploy GraphQL with a strong and secure foundation from day one. And that’s completely doable.

The truth is that GraphQL is mature enough for production in large enterprises and is already deployed in large production environments across the biggest and most data-intensive companies in the world (Meta, Rakuten, PayPal, Lyft, KLM, Starbucks, Shopify, the list goes on). Champions can answer skeptics by demonstrating that enterprise-grade, purpose-built GraphQL tooling and expert support are available to guide a seamless deployment and allow the development team to hit the ground running toward their GraphQL goals. This is why we built Inigo; our one-stop-shop GraphQL management gateway eliminates the learning curve to managing a secure enterprise GraphQL deployment.

## Obstacle #2 for GraphQL champions: the myth that it’s “too early to add enterprise support”

It’s a frustrating catch-22 for champions: while some skeptics accuse GraphQL of not being enterprise-ready, other stakeholders will say it’s too early to invest in GraphQL management, security, and support because the organization has yet to use it much. 

Champions need to deliver this message: it’s never too early to apply GraphQL best practices and doing so from the beginning pays dividends in the long term. Implementing best practices in a greenfield environment means fully benefitting from efficient operations, secure access control and visibility, granular analytics and BI insights, schema planning, API lifecycle tools, and an improved developer experience from the start. In contrast, aligning brownfield deployments with GraphQL best practices often means fixing thorny legacy issues—such as access controls hard-coded into servers and resolvers—which can be harder to deal with. You would never hear that it’s too early to use Jira in the development process. it’s given that you want everything there from day one. Similarly, the sooner an enterprise starts with GraphQL best practices for workflow management and security, the easier it is to operate and scale, and the more inisghts you have to optimize your schema and design things right from the start. 

## Explore Inigo

GraphQL champions know that their enterprises are ready to harness GraphQL, and that they should highlight the right complementary tooling to help make their case and convince stakeholders. With Inigo, enterprises gain the visibility to operate GraphQL seamlessly, and the security to operate it safely and with confidence. The Inigo platform also removes obstacles to GraphQL adoption, eliminating unknowns to make migration quicker and easier while expediting GraphQL’s (many) benefits.

## Developers Use Inigo for: GraphQL Visibility
 
![Developers Use Inigo for GraphQL Visibility.webp](/uploads/Developers_Use_Inigo_for_Graph_QL_Visibility_c048c5d015.webp)

Seeing is believing, and visibility into GraphQL data is critical to ensure success and find any issues before they become…big issues. For both at-a-glance visibility into GraphQL deployments and granular deep dives, the Inigo platform delivers. A health dashboard details any server error breakdowns, with a complete view of service and subgraph states. The dashboard is built to enable developers to take quick action when needed.
 
While standard monitoring tools overlook GraphQL query insights—and the valuable business intelligence those insights hold—the Inigo platform is built for query-level analytics. Developers get a uniquely in-depth understanding of their GraphQL usage (at scale) through detailed insights into the field level, query paths, and server health, among other metrics.

## Developers Use Inigo for: GraphQL Planning
 
![Developers Use Inigo for GraphQL Planning.webp](/uploads/Developers_Use_Inigo_for_Graph_QL_Planning_a96a246340.webp)

Inigo takes the guesswork (and time) out of GraphQL planning. Straightforward schema navigation enables developers to quickly identify, review, and share schema version differences, and also flag any deprecated and tagged fields. The platform’s heatmap of GraphQL usage—with real traffic data—is critical for gathering unique BI that drives more effective and efficient planning.
 
As the API lifecycle progresses, Inigo gives developers the tools they need to be well-prepared for schema changes and field deprecation with absolute minimal (and often zero) impact to the customer experience. Inigo’s gateway inspects changes and compares them against real traffic, instantly alerting developers to any API outages.

## Developers Use Inigo for: GraphQL Security
 
 
![Developers Use Inigo for GraphQL Security.webp](/uploads/Developers_Use_Inigo_for_Graph_QL_Security_9f121c3a21.webp)

All of GraphQL’s productivity, developer experience, and availability gains fall apart if security can’t keep up. Inigo protects GraphQL environments from spec abuse with query-level protections that thwart DoS attacks and provide real-time protection against data tampering, malicious traffic, and slow (or unresponsive) API responses.
 
Object-level rate limiting is critical for GraphQL security, and Inigo achieves this by counting each query’s requested objects and returned objects against a time frame limit (such as 1000 objects per minute). Developers using object-based rate limiting know that their servers will be protected against potential performance degradation while still allowing for flexible and efficient API use.
 
Lastly, one of the biggest developer misconceptions around GraphQL security is that you need to disable introspection. [You don’t](https://inigo.io/blog/you-dont-need-to-disable-introspection). Inigo’s schema-based access control is built with introspection separation, so access control can be completely enforced at the edge. Users only get schema visibility to pre-allowed operations, types, and fields.
 
## Is Inigo right for me?
 
Because Inigo uses a traffic-based pricing model and costs nothing to install, champions can explore Inigo and demonstrate its benefits on dev environments practically for free. Champions should also showcase how Inigo delivers a huge ROI by eliminating the need to hire top-tier GraphQL talent. With Inigo, there’s no need for enterprises to wait to deploy GraphQL, no huge budget expenditures, and no need to hire in-house experts to take advantage of an expertly managed and secured GraphQL deployment.


Expedite your GraphQL roadmap by making it enterprise-ready from day one

Harnessing Materialized Views and ClickHouse for High-Performance Analytics

large_Harnessing Materialized Views and ClickHouse for High-Performance Analytics.webp

medium_Harnessing Materialized Views and ClickHouse for High-Performance Analytics.webp

small_Harnessing Materialized Views and ClickHouse for High-Performance Analytics.webp

thumbnail_Harnessing Materialized Views and ClickHouse for High-Performance Analytics.webp

Harnessing Materialized Views and ClickHouse for High-Performance Analytics.webp

In this post, we share our findings after loading billions of rows of data and conducting measurements.

## Overview
At Inigo, we were seeking a database solution that could handle a high volume of raw data for analytics. After exploring various alternatives, including SQLite, Snowflake, PostgreSQL, we decided to experiment with Materialized Views using ClickHouse on a relatively slow machine. In this post, we share our findings after loading billions of rows of data and conducting measurements.

## Database Alternatives Considered
Before arriving at ClickHouse, we tried several other databases:
1. Snowflake - too slow and costly for our needs. While it performs well for processing in-house data, it becomes quite expensive when handling real-time customer data within a product, which negatively impacts the product's unit economics. The lack of a local Snowflake emulator further complicates development, as it prevents running continuous unit tests against the database. Additionally, the user interface did not align with our preferred database usage. Since each service had its own separate table, we had to obtain and hardcode table names in the UI. This made it impossible to retrieve data from all tables using a single query in the user interface.
2. PostgreSQL - An excellent database, but its transactional nature made it unsuitable for large analytic workloads. We were able to get it to work with around 100K rows, but past that, the indexes were growing out of control and the cost of running a Postgres cluster didn’t make sense.

## What is ClickHouse?
Clickhouse is a columnar database specifically designed to handle high volumes of data while providing fast query execution. Materialized views in Clickhouse serve as pre-aggregated datasets that can significantly improve the performance of analytical queries. Furthermore, Clickhouse's ability to automatically manage and update materialized views as new data is ingested simplifies the maintenance process, making it an attractive choice for those seeking an efficient and powerful analytical database solution.

## Why Clickhouse
We ended up choosing Clickhouse for its general high performance, ability to handle large scale, and ability to run it locally for testing purposes.

## Inigo’s ClickHouse Setup
Our current ClickHouse setup is a single database where nearly every Inigo service has its own table, with some tables containing billions of rows of data. It runs on 4 vCPUs, 32GB RAM for the development environment and 16 vCPUs, 128GB RAM for the production environment. 
Setting up ClickHouse was challenging, as understanding the nuances of each index, sharding, and materialized views required considerable effort. However, the end result has been a system capable of loading and querying vast amounts of analytics data in a scalable manner, both in terms of hardware cost and engineering development time.

## Materialized Views in ClickHouse
Given that we have billions of rows in some of our raw tables, we strive to minimize joins whenever possible. Instead, we have consolidated the data into several materialized views, each grouping the data into distinct time window buckets. As a result, most of the time, we are querying thousands of aggregated rows instead of millions of raw data rows, resulting in faster real-time filtering.

### Creating materialized views
Our raw tables all contain a timestamp column observed_at.
We then aggregate the data rows into specified intervals for the materialized tables. For example, if the interval is 1 minute, we use the toStartOfInterval(observed_at, INTERVAL 1 minute) function to aggregate data into one minute intervals. Each row in the materialized views contains several raw data values, all corresponding to a particular minute based on the observed_at column.
By creating materialized views with different intervals, such as 6 minutes, 40 minutes, and 3 hours, we can further enhance query performance and enable more efficient data analysis across various timeframes.

We exclude all columns containing unique data, such as trace_id, from materialized views. When we need to filter by trace_id, we query the raw data. It is worth noting that raw data queries are reasonably quick in Clickhouse, as Clickhouse can efficiently sift through a large number of rows in real-time using the appropriate index for each column.

### Grouping data
In our analytics, we primarily use grouped queries to obtain data. Standard queries and materialized view queries use the same SQL files, but there is a slight modification in the way they handle counting. Instead of using count(1) to count the rows, materialized view queries use sum(calls) with a derived column named calls. The column calls is created by using count(1) as calls in the materialized view definition. This change allows us to aggregate the count of rows from the materialized view, resulting in more efficient querying and better performance.

### Merge and State Suffix
In Clickhouse, the State and Merge suffixes are used with aggregation functions to handle intermediate aggregation states and merge them efficiently. These suffixes are particularly useful when working with distributed databases or when we need to combine aggregated results from multiple sources.

- The State suffix: The aggregation functions with the State suffix return an intermediate aggregation state rather than the final result. These intermediate states are stored in a compact binary format that represents the aggregation in progress.

For example, if we want to calculate the 95th (0.95) and 99th (0.99) percentiles of a column called server_process_time, we can use the quantilesState(value) function. This function returns the intermediate state of the quantiles calculation, which we can store in a separate table or combine with other intermediate states.

- The Merge suffix: The aggregation functions with the Merge suffix take the intermediate aggregation states produced by their corresponding State functions and merge them to produce the final aggregation result. This is useful when we have multiple intermediate states that we need to combine into a single aggregated result.

For instance, to obtain the 99th percentile of the aggregated server_process_time, we would use quantileMerge(0.99)(quantiles_server_process_time), where quantiles_server_process_time is the intermediate state resulting from the quantilesState function.

## Results
By leveraging Materialized Views and ClickHouse, we achieved the following:

1. The database is now faster than our Golang code, allowing us to use pooling and improving our UI responsiveness.
2. Confidence in query speed, enabling us to identify issues outside the database, such as in tracing extensions.

The scalability of this solution depends on various factors, including the scaling setup. ClickHouse officially offers a cloud service with 720 GiB RAM, 180 vCPU, and 10 TB of data, indicating its potential for handling significant workloads. However, we have been able to easily scale to 1B rows and still growing.

## Conclusion
While ClickHouse does have limitations, such as the absence of transactions and potential inaccuracies in Materialized Views, these drawbacks are minor for our analytics use case. Overall, ClickHouse, when paired with Materialized Views, has proven to be an excellent solution for handling large-scale analytics data with impressive performance and scalability.


Are Your Developers Using GraphQL Without Your Knowledge.webp

large_Are Your Developers Using GraphQL Without Your Knowledge.webp

medium_Are Your Developers Using GraphQL Without Your Knowledge.webp

small_Are Your Developers Using GraphQL Without Your Knowledge.webp

thumbnail_Are Your Developers Using GraphQL Without Your Knowledge.webp

Your organization could be running GraphQL right now…and you might not even know it.

## Overview
Your organization could be running GraphQL right now…and you might not even know it. As a platform lead responsible for optimized operations, or a security operations person responsible for security of the environment, that’s not exactly a sleep-well-at-night scenario. It’s relatively simple for a lone developer to deploy GraphQL and, while you have no idea it’s happening, they almost certainly have no idea how to manage and secure GraphQL APIs.

Developers tend to prioritize efficiency and speed over security. These priorities have been the main drivers of GraphQL adoption (see, for example, [PayPal’s GraphQL adoption story](https://medium.com/paypal-tech/graphql-at-paypal-an-adoption-story-b7e01175f2b7)). The reasons are clear: GraphQL enables faster release of new versions to clients, easier API integration, easier testing, and an overall better developer experience. But while GraphQL increases developer productivity and improves end-user experiences, it is also a paradigm shift for platform teams who must ensure security and availability. 

Developers’ priorities frequently conflict with those of platform teams. That’s not unique to GraphQL, but the difference is that when that happens with GraphQL, your existing web application gateway or other gateways won’t raise a red flag. A GraphQL server offering paths for attackers to expose data, or loading extremely resource-heavy burdens on your platform, could already be running and you would not know it because you will only see “200 OK” response codes (see why in our blog on [GraphQL error handling](https://inigo.io/blog/graphql_error_handling)). 

Should you be worried about using GraphQL? Not at all, if you have the right tools and safeguards in place: deep analytics, tight access controls, and granular visibility into how GraphQL APIs use your resources. Without these, you cannot guarantee your SLAs and you certainly cannot meet compliance requirements because your GraphQL APIs would be exposed to [injection attacks](https://inigo.io/blog/graphql_injection_attacks), [vulnerabilities](https://inigo.io/blog/analysis_of_public_graphql_vulnerability_reports), and other kinds of attacks we discuss in other [blogs](https://inigo.io/blog). 

GraphQL rewards organizations that implement best practices and place controls as early as possible. Getting GraphQL management and security right within a greenfield environment is far simpler than undoing hardcoded mistakes in legacy deployments later. It’s why we’ve built out all the GraphQL-specific capabilities required for platform teams and developers to benefit from a secure, resource-efficient, easily scalable GraphQL deployment from the start (and the visibility to know if your developers have, well, started without you).

Platform teams managing GraphQL should have these capabilities in place from Day One, or as soon as possible:

## Access control

GraphQL access control is an essential Day One feature, but requires strategy and forethought. Going down the wrong path can lead to hairy situations, such as introducing overly-specific code inside resolvers and servers that becomes a challenge to remove. Deploying Inigo’s solution to get access control right from the start means avoiding major headaches in the future. 

Many platform teams are also led astray by the [false advice to disable introspection](https://inigo.io/blog/you-dont-need-to-disable-introspection). Inigo’s schema-based access control features RBAC introspection separation to enforce access control at the edge and limits users’ visibility to the correct operations, types, and fields. GraphQL resolvers stay clean and tight, with complex code logic replaced by easily managed role-based declarative configurations. Query-level audit trails, data leak protection with PII detection, and remediation alerts ensure proper governance that aligns with compliance mandates.

## Schema planning

GraphQL schema planning must be part of the development and API lifecycle from the onset in order to identify errors and protect against production failures that would cause degradation in service levels (and put SLA commitments at risk). Optimized schema planning is key not only to guaranteeing SLAs and reducing costs, but to the broader goals of API modernization. Using GraphQL without proper schema planning could results in poor results, causing your management to assume that GraphQL isn’t mature enough, rather than supporting your team in the process. Inigo’s enterprise-grade tools solve this issue by equipping platform teams and developers with access to real traffic usage data and unique business intelligence—enabling strong foundational and future schema planning. Teams see all their APIs and all the queries in depth, for ongoing control and schema optimization. 

## Federated subgraph visibility

If GraphQL does take root in your organization—but grows into a brownfield deployment with a federated graph before the platform team implements the right visibility tooling—you’ll need some extra help. A federated graph combines multiple subgraphs to expose a singular data graph via an API. Unfortunately for unprepared organizations, reaching this point means that the platform team has no visibility into what traffic goes to which subgraph within this federated architecture. When an issue occurs, such as slow performance or resource-gobbling server behavior, the team can’t see the cause or have the right information for resource allocation discussions. Tapping Inigo provides a clear breakdown of the resources, data, and load among federated subgraphs, making it simple to sort out otherwise painful issues.

## Help your developers help themselves

For platform teams, developers that lack the tools to solve their own issues can be the biggest nightmare of all. Providing each developer with well-configured access control to address their own needs keeps issues off of the platform team’s plate. At the same time, powerful visibility allows platform teams to quickly solve any issues they do need to address. With Inigo, platform teams can eliminate friction with dev teams and ease the organizational learning curve toward secure and optimized GraphQL adoption, applying expertise from day one without needing to become GraphQL experts.


Are Your Developers Using GraphQL Without Your Knowledge?

large_API Gateway are blind to GraphQL.webp

medium_API Gateway are blind to GraphQL.webp

small_API Gateway are blind to GraphQL.webp

thumbnail_API Gateway are blind to GraphQL.webp

API Gateway are blind to GraphQL.webp

Rediscover your GraphQL API Experience: Learn how GraphQL breaks free from traditional API Gateways.

## Overview
For those coming from the world of REST/HTTPs APIs, GraphQL’s error handling paradigm can feel undisciplined and inconsistent. **Unlike in REST/HTTP APIs, where error handling is based on status codes returned by the API, GraphQL request are always made using the same `/graphql` url and always return a 200 OK response**. Instead of being signalled via status codes, errors reside inside the response payload, alongside any data returned.

This makes GraphQL error handling a blind spot for most engineers and security teams. Standard WAFs will generally only look at HTTP headers; thus with GraphQL they are unable to contextualize and differentiate between:

- Successful calls 
- Server errors
- Rate limiting
- Operation errors
- Authorization errors
- Subgraph owner

Additionally, there is little visibility when mission-critical objects and mutations, like purchase orders, fail. In this blog post, we cover some of the top problems with GraphQL’s default error handling, some best practice solutions, and how Inigo can help elevate GraphQL errors so they are quickly handled by the proper team.

## Error Handling in GraphQL
GraphQL is transport agnostic, which means that it does not rely on the underlying transport mechanism used to transmit data between the client and the server. GraphQL APIs can use Web Sockets instead of HTTP for client-server communication if it suits the use case. As a result, GraphQL APIs do not rely on HTTP methods like GET, PUT, and POST, nor are HTTP status codes relevant. 

In GraphQL, errors are returned as part of the server responses from the server. When an error occurs, the server returns a response with an `errors` field that contains information about the error. Clients can determine whether the request was successful or not by looking at this errors field. 


### Example 1:
Here is an example of a GraphQL response with an error:
```
{
  "data": {
    "createUser": null
  },
  "errors": [
    {
      "message": "Email already in use",
      "locations": [
        {
          "line": 2,
          "column": 3
        }
      ],
      "path": [
        "createUser"
      ]
    }
  ]
}
```

In the above example, the errors field in the response is an array of errors. Each error contains  three fields:

- **Message:** Provides a description of the error
- **Location:** Indicates where in the query the error occurred
- **Path:** Indicates which field in the query caused the error

In this case, the error message "Email already in use" indicates that the email address specified in the `createUser` mutation is already in use by another user.

In addition to the above three fields, there is an `extensions` field that can be used to add extra information about the error.

### Example 2:
The following mutation should result in the creation of a user:
```
mutation {
  createUser(name: "XYZ", email: "xyz@abc.com") {
	  name, 
	  email,
	  password
  }
}
```

The mutation results in the following response:
```
{ "errors": [ {
  "message": "Cannot query field \"password\" on type \"User\".", 
  "locations": [ { "line": 5, "column": 6 } ], 
  "extensions": { 
    "code": "GRAPHQL_VALIDATION_FAILED", 
    "stacktrace": [ 
      "GraphQLError: Cannot query field \"password\" on type    \"User\".", " at Object.Field (/my_project/node_modules/graphql/validation/rules/FieldsOnCorrectTypeRule.js:48:31)", " ...additional lines..." 
      ] 
  } 
} ] }
```

Note that the path element is missing from the error object because, unlike the error in Example 1, this error is raised before execution. These are commonly referred to as request errors, and they include parsing and validation failures. Since this mutation was run on an Apollo server, the error extensions are specific to Apollo’s implementation. These may be different when using other GraphQL implementations. 

## Problems with GraphQL's Error Handling
As you can see, GraphQL's error-handling mechanismis substantially different from how we are accustomed to dealing with errors. As a result, GraphQL error handling presents several challenges:

### Difficult to parse
A GraphQL response may contain both data and errors. The presence of errors does not imply the absence of data. In the absence of errors, the errors key is absent from the response.

In the following snippet, for example, if you merely parse the errors key and assume the entire response is erroneous, you will miss out on the partial data returned.
```
{
  "data": {
	  "user": {
	      "name": "Inspector Spacetime",
	      "userFriends": [{
		      "id": 1,
		      "name": "Constable Reggie"
	      }, {
		      "id": 2,
		      "name": null
	      }]
	  }    
  },
  "errors": [{
	  "message": "Could not fetch name of friend "
	  "locations": [{
		  "line": 2,
		  "column": 5
	  }],
	  "path": [
	  "user", "userFriends", 1, "name"
	  ]
  }]
}
```
### No standard format
Different GraphQL implementations might report errors in different formats, or utilize different error-handling conventions, making it difficult for a standard API gateway to parse.

The following is an erroneous response for failed validation in Hasura:
```
{
 "errors": [{
    "extensions": {
    "path": "$.selectionSet.users.selectionSet.name",
    "code": "validation-failed"
   },
   "message": "field \"name\" not found in type: 'users'"
 }]
}
```
The following is an erroneous response for failed validation in Apollo:
```
{ 
 "errors": [{ 
	"message": "Cannot query field \"name\" on type \"User\".",   
	"locations": [{ 
	 "line": 2, 
	 "column": 3
	}], 
	"extensions": {
	 "code": "GRAPHQL_VALIDATION_FAILED", 
	 "exception": { 
	   "stacktrace": [
	      "GraphQLError: Cannot query field \"name\" on type \"User\".", "...additional lines..." 
	    ]} 
	} 
}], 
"data": null 
}
```
It's always a good idea to consult the documentation for the specific implementation you are using for more information on error handling.

### Hard to differentiate

A GraphQL response may be the result of many requests to distinct data sources. Certain fields may fail due to a lack of authorization, while others may fail due to faulty validation, and we may only obtain a partial response for the remainder. The `errors` list might contain a wide range of errors, making it difficult for the client to handle and respond.

Here's an example of multiple errors being returned in response to a query:
```
{
  "errors": [
    {
      "message": "The provided argument value '9999999999' is invalid for the input argument 'id' on field 'node' of type 'ID'.",
      "locations": [
        {
          "line": 2,
          "column": 3
        }
      ],
      "path": [
        "query",
        "node"
      ],
      "extensions": {
        "code": "GRAPHQL_VALIDATION_FAILED",
        "field": "id"
      }
    },
    {
      "message": "Access Denied",
      "locations": [
        {
          "line": 6,
          "column": 3
        }
      ],
      "path": [
        "query",
        "customerAccessTokenCreate"
      ],
      "extensions": {
        "code": "ACCESS_DENIED"
      }
    }
  ]
}
```
In this example, the HTTP status code is 200 OK, but the response body includes two error objects in the errors key. The first error object indicates that the provided value for the "id" argument on the "node" field is invalid. The second error object indicates that access was denied when attempting to create a customer access token.

### No prioritization of business-critical errors
This last example demonstrates how multiple errors might be returned in a GraphQL response. In addition to being difficult to distinguish, multiple errors are also difficult to prioritize.  

In some cases, a `data not found` error may be for a single item in the list, which may not affect the client and would be safe to disregard. In another scenario, even if partial data is received, it might make sense to regard the full response as erroneous. Prioritizing distinct error types and creating a hierarchy is therefore difficult to accomplish with GraphQL. It is also important to be able to distinguish and prioritize handling of business-critical errors, for instance, those involving payments.

### Disclosure of sensitive information
Field recommendations in the error message may reveal sensitive information or expose unexpected functionality that is not intended to be utilized by clients, such as fields that allow clients to manipulate resources or execute arbitrary code. This information might then be used in “fuzzing” attacks executed on the server.

The following is a query that requests product categories:
```
query {
    searchCategories {
        name
        description
    }
}
```
The server returns the following response:
```
{
	"errors": [
    	{
            "message": "Cannot query field \"searchCategories\" on type \"Query\". Did you mean \"searchUsers\" or \"searchRoles\"?",
            "locations": [{
            		"line": 144,
            		"column": 3
			}]
		}
    ]
}
```
The response reveals functionality and exposes sensitive information to the client, thus putting the application (and data) at risk.

### Hard to debug errors in subgraphs
A federated GraphQL architecture refers to a way of organizing a GraphQL API as a network of independent GraphQL services that work together to provide a single, unified GraphQL API. Each of the independent GraphQL APIs are known as subgraphs. A router API is exposed to the client in such an architecture and requests are routed by the router to the subgraph that can resolve the query or fields of the query.

![API Gateway are blind to GraphQL Federated](/uploads/API_Gateway_are_blind_to_Graph_QL_Federated_3674bebe0a.webp)

In the context of error handling, a federated GraphQL architecture can be confusing. Each service subgraph may return different error messages, making it more difficult to understand the overall context of the errors and their relationships to the original queries.

For example, let's say we have two subgraphs - customer subgraph and a product subgraph, and there is an error while querying a customerInfo field. The following is a snippet of the error received:
```
{
  "errors": [
    {
      "message": "Internal server error",
      "path": ["customerInfo"]
    }
  ]
}
```
This error message provides very little information about what went wrong and why the user is unable to retrieve their customer information. In some cases, tracing an error like this in a subgraph can be very time-consuming and require a deep understanding of the underlying architecture. 

## Best Practices for Error Handling
Error handling and debugging may be difficult for GraphQL APIs, but there are industry-wide practices and approaches that can help us deal with them more effectively. Some of the solutions to the problems we discussed above are as follows:

### Write custom error handling middleware
Since all errors in GraphQL result in a 200 status code, in order to provide “HTTP-readable” errors to the client, a developer might write custom error handling middleware that intercepts all errors before they are returned to the client. This middleware categorizes each error based on its type and then translates it into a readable error message.

The following is an example of custom error handler for a GraphQL server:
```
customErrorHandler = (err, req, res, next) => {
 const error = formatError(err);
  const { message, locations, path, extensions } = error;

  let statusCode = 500;
  let errorType = 'INTERNAL_SERVER_ERROR';
  let errorMessage = 'Internal server error. Please try again later.';

  if (extensions && extensions.exception) {
    const { name } = extensions.exception;

    if (name === 'ValidationError') {
      statusCode = 400;
      errorType = 'VALIDATION_ERROR';
      errorMessage = 'Invalid input. Please provide valid data for the following fields:';
    }
  }

  const response = {
    errorType,
    message: errorMessage,
    locations,
    path,
  };

  res.status(statusCode).json(response);
};

const app = express();
app.use('/graphql', graphqlHTTP({
  schema,
  rootValue,
  customErrorHandler,
  graphiql: true
}));

app.listen(4000, () => {
  console.log('Running a GraphQL API server at localhost:4000/graphql');
});
```
This middleware intercepts GraphQL errors and categorizes them based on their name. In addition to categorization by name, you can also categorize them by:
- **Error location:** You can categorize errors based on where they occurred in the query or mutation. For example, you can categorize errors by the name of the field or argument that caused the error. 
- **Error severity:** You can classify errors based on their severity level, such as critical errors that prevent the server from processing the request, or non-critical errors that don't affect the functionality of the application.
- **Error source:** You can categorize errors based on their source, such as server-side errors or client-side errors. This can help you identify whether the error was caused by your server, your client, or a third-party service.
- **Error type:** You can classify errors based on their type, such as validation errors, authorization errors, or input errors.

You can also write custom error handlers to hide native GraphQL error messages that should not be seen by the client. For example, error messages in GraphQL often contain field suggestions which might be exploited later:
```
{
  "errors": [
    {
      "message": "Cannot query field \"hellooo\" on type \"Query\". Did you mean \"hello\"?",
      "locations": [
        {
          "line": 33,
          "column": 3
        }
      ]
    }
  ]
}
```
These sorts of error messages can be masked via a custom error formatting function as below:
```
const customFormatErrorFn = (error) => {
 if (error.message.startsWith("Cannot query")) {
   return {
     message: "Invalid request"
   };
 }
 return error
};
```

### Treating errors as data

An alternative to the custom middleware approach is to use the “data as errors” approach. In the “data as errors” approach, error handling is baked into the GraphQL schema. You define different response types for when a response is successful and when it’s not. For example, say we are designing a GraphQL API for fetching books for a library catalog:
```
type Book {
   id: Id!
   title: String! 
}


type NotFound
{
   message: String!

}

type Overdue
{
    message: String!
    lateFee: Float
}
```
You can use a **union type** to represent all possibilities of the response:
```
union BookResult = Book | NotFound | Overdue

type Mutation {
  bookResult(id: Id!): BookResult
}
```
A client may then query for books based on the different states returned by the book result:
``` 
{
 bookResult(id: 1) {
   __typename
   ... on Book {
     id
     title
   }
   ... on NotFound {
     message
   }
   ... on Overdue {
     message,
     lateFee
   }
}
```
By modeling the errors in the schema itself, you leave it to the client handle the ones that are important.

### Disable debug mode in production

Dev Mode, supported in some GraphQL implementations but not all, provides a lot of helpful information for developers during the development and testing phase, such as detailed error messages and a comprehensive list of available fields and arguments. However, it is generally recommended to disable dev mode in production since it can expose sensitive information about your GraphQL API, such as the structure of your database, server configuration details, and API keys, to potential attackers. 

### Avoiding leakage of sensitive information through errors
It is recommended to limit the amount of information returned in error messages and include only the minimum amount of information necessary to identify the error and help developers debug it. You’d certainly want to avoid including sensitive information such as database queries, user information, or system configuration details.

### Configuring proper alerts and triggers for mission-critical business errors
Several critical business errors, if not rectified, have the ability to completely derail the system. Purchase orders, for example, are mission-critical objects and mutations that cannot fail, and when they do, unless there is sufficient error escalation and alerting in place, these mistakes might be missed, delaying redressal. In such situations, it is crucial that an event is triggered to alert the team responsible immediately.

### Improve traceability for subgraphs
It is best practice for each subgraph to log errors to a centralized logging system that aggregates logs from all the subgraphs. You can use log aggregation tools that provide error alerts and analysis to help you identify trends and patterns. It is also important to set up monitoring and have alerts configured to notify subgraph teams when an error occurs. It is critical to offer an internal key to the subgraph without disclosing too much information externally.

## How Inigo can help
Companies are increasingly implementing GraphQL in their production environments. With this growth comes a new set of challenges, including how to secure GraphQL, analyze blind spots, and gain visibility into GraphQL traffic and errors. This is where Inigo comes in.

Inigo is not a GraphQL server. Instead, it offers a comprehensive set of tools to contextualize GraphQL traffic, provide granular query-level analytics, and elevate errors to the appropriate team. 

For example, on the Inigo dashboard, you’re able to see all of the queries and errors coming into and going out of your GraphQL setup. These errors are likely returning a 200 status code, which means that if you're using a standard API gateway, you have little visibility into them.

![Top Errors.webp](/uploads/Top_Errors_18fcca0bf1.webp)

You’re also able to filter queries based on whether they responded with an error:

![Explore queries with errors.webp](/uploads/Explore_queries_with_errors_64e01a0040.webp)

These errors are categorized/labeled, and you can dig into them:

![Explore Detailed Query.webp](/uploads/Explore_Detailed_Query_121d4e085c.webp)

Additionally, Inigo makes it easier to implement GraphQL error handling best practices, for example, by blocking errors that contain PII, or by allowing users to automatically configure alerts that will escalate business-critical errors to responsible parties via Slack or email.

Finally, in the case of multiple errors, Inigo provides subgraph visibility. In a federated GraphQL system, when you get an error, you might not know which subgraph that error comes from. With Inigo, you can dive into specific subgraphs to explore the errors:

![Subgraph Analytics.webp](/uploads/Subgraph_Analytics_1b83597c7d.webp)

## Conclusion
Error handling is a key component of API development. For GraphQL APIs in particular, error handling requires careful thinking and design. You can learn more on why defending GraphQL APIs is challenging for security engineers [here](https://inigo.io/blog/what_makes_defending_graphql_apis_is_challenging_to_security_engineers). In conclusion, it is critical to have a contextualized way to surface GraphQL analytics and elevate alerts to improve the overall stability and usefulness of your GraphQL API. 

GraphQL Error Handling

large_Graphql_Injection.webp

medium_Graphql_Injection.webp

small_Graphql_Injection.webp

thumbnail_Graphql_Injection.webp

Graphql_Injection.webp

GraphQL’s complex payload expands attackers' ability to inject malicious payloads and compromise its underlying system.

## Overview
Injection attacks are a very common type of web attack, where an attacker sends malicious input to an API that has an interpreter or parser that processes the input and passes it on to a backend system or database. If the interpreter/parser doesn’t validate or sanitize the input, then the attacker can gain access to or manipulate confidential data.

## Why do injection attacks occur in GraphQL?
GraphQL is uniquely vulnerable to injection attacks for a few reasons:

1. GraphQL introduces new surfaces for injections, through features like operation names and aliases.
2. GraphQL introduces new steps in the processing flow. Each of the parser, the gateway, and the sub-graph resolvers can be targets for an attack.
3. GraphQL turns what would be multiple API calls with a REST API into a single call. This single call can target multiple areas and multiply injection combinations because of GraphQL’s free-form nature.

## How GraphQL injection attacks work
An injection attack can happen at any phase during the execution of a query:

1. Parsing: The GraphQL query string is parsed into an abstract syntax tree (AST), a tree-like representation of the query. This step verifies that the query is syntactically correct and adheres to the GraphQL query language specifications.
2. Validation: The AST is then validated against the GraphQL schema to check that the query is semantically correct and that it is requesting only valid fields and types. This step checks if the query adheres to the GraphQL schema and rules. Since the specification specifies no rules besides uniqueness on operation, argument, alias and directive names, these, if not validated, can be an entry point for an attacker.
3. Execution: The validated query is then executed by the server using resolvers. For each field requested, there is a resolver function that runs in the backend and fetches the data from the database. The resolver can also serve as an entry point for an attacker. For instance, the following is an example of a GraphQL resolver written using GraphQL.js. It executes a query that returns a customer that matches the supplied id. 

```
Query: {
 customer(obj, args, context, info) {
 const stmt = `SELECT * FROM customers where id = ${id};`;
 const customerData = db.query(stmt)
 return customerData
 }
}
```
If a value like id: "1' OR 1=1–" is provided, it will result in a SQL injection and the resolver will return all customers, triggering a data breach.

## Examples of Injection Attacks
GraphQL injection attacks can lead to a few different scenarios:

1. DoS (overloading the parser or resolver to a point they crash)
2. Extract data
4. Manipulate data

Below, we’ll cover some specific tactics that attackers might use in an injection attack, including Aliases, SQL injections, command injections, XSS assaults, LDAP and NoSQL injections.

## SQL injection
A SQL injection involves exploiting systems that use SQL to communicate with their databases. An attacker can inject SQL statements that manipulate a GraphQL query to access, modify or delete data.

For example, an attacker could include the following code in a GraphQL query that retrieves a particular customer's details:
```
query {
 customer(id: "22371' OR 1=1–") {
 name, 
 email, 
 address, 
 contact
 }
} 
```
During the execution phase, the above code would cause the query to return all the customer details instead of just the customer matching the original query.

## NoSQL injection
A NoSQL injection attack is similar to a SQL injection attack. It targets systems or applications that use NoSQL databases.

The following query is an example of a GraphQL query that accepts a JSON input to search for a user via user names or email addresses. 
```
query {
 users(search: "{\"username\": {\"$regex\": \"jan\"}, \"email\": {\"$regex\": \"jan\"}}",
 options: "{\"skip\": 0, \"limit\": 10}") {
 _id
 username
 fullname
 email
 }
}
```

The attacker could modify the JSON data type fields to include MongoDB or other NoSQL database-specific commands, which would then be executed by the database when the GraphQL query is processed.

```
query {
 users(search: "{\"email\": {\"$gte\": \"\"}}",
 options: "{\"fields\": {}}") {
 _id
 username
 fullname
 email
 }
}
```

During the execution phase, the above query will return all fields specified in the GraphQL schema for all users in the system. 

## LDAP injection
LDAP is commonly used for storing, retrieving, modifying and searching for data in a hierarchical directory. A GraphQL query that accepts LDAP input could be used to retrieve data from an LDAP directory. 

LDAP injection attacks typically target the search filter of an LDAP query, which is used to specify the conditions that must be met for a record to be returned. An attacker can modify the search filter to include malicious code, allowing them to retrieve sensitive information or perform other unauthorized actions. For example, an attacker might modify a search filter to include a wildcard character, which would return all records in the directory.

```
query {
 user(username: "*") {
 name
 email
 groups
 }
}
```

During the execution phase, the above query returns details of all users. 

## Command injection
Command injection is an exploit in which an attacker can inject shell commands or code into a GraphQL query. It allows the attacker to execute arbitrary commands on the server, thus potentially giving them wide access. For example, consider the following GraphQL query
```
query {
 getUser(id: "1") {
 name
 email
 }
}
```
An attacker can inject a command into the id field to execute a shell command on the server during the execution phase, such as:
```
query {
 getUser(id: "1; ls -la") {
 name
 email
 }
}
```
If the server is using an API that interprets a string as a shell command (for instance is using child_process.execFile), this would cause the server to execute the command `ls -la`.

## XSS (Cross-Site Scripting)
XSS attacks can occur when an attacker injects malicious code into trusted websites, generally in the form of browser scripts. For example, an attacker might inject malicious code into the comment field, such as:
```
query {
 getComment(id: "1") {
 user
 comment: "<script>alert('XSS Attack')</script>"
 }
}
```
When a user views the results of this query, the malicious script will be executed in their browser.

## Log spoofing
GraphQL actions can take an operation name as part of the query. For example, here is a query that uses CustomName as an operation name:
```
query CustomName {
 getCustomName
 {
 first
 last
 }
 }
```
In the audit log, the application will display all queries and mutations that users are executing on the system. If the query had an operation name, it will be recorded in the audit log under that operation name. This creates an opportunity for attackers to “spoof” the log by putting a query under a misleading operation name.
For example, the mutation below logs the mutation as getUser when actually, it’s creating a user.
```
mutation getUser {
 createUser(name:"<script>alert(1)</script>", content:"zzzz", public:true) {
 userId
 }
}
```
Or, the query below logs arbitrary strings to the audit log:
```
query arbitraryString {
 systemHealth
}
```

## HTML injection
HTML injection allows an attacker to inject malicious code into a vulnerable web page. HTML injections are similar to XSS attacks. The following query demonstrates how an attacker can create an HTML injection:
```
mutation {
 createPaste(title:"<h1>hello!</h1><script>alert('Attack')</script>", content:"zzzz", public:true) {
 paste {
 id
 }
 }
}
```

## Prevention and protection against GraphQL injection attacks
Below, we outline some ways to protect your server from GraphQL injection attacks.
### Input validation and sanitization
Input validation means having checks in place for GraphQL input. These checks validate that the input has an expected format and doesn’t include special characters frequently used in injection attacks.

For example, in the above SQL injection examples, we see that an attacker supplies input ( 1233' OR 1=1-) that includes the single quote special character.

The dynamic SQL statement in the resolvers might be: 
```
"SELECT * from customers where id='" + input + "'"
```

After concatenating it with the provided input, the statement is evaluated as:
```
SELECT * from customers where id='1233' OR 1=1—'
```
The single quote acts as a string delimiter in SQL. By adding it to the input, the statement searches for customers with an id of 1233 or 1=1. Since 1=1 is always true, it returns all customers. The last single quote is commented out, then, since – and any text after it is considered a comment in SQL. 

In this example, input validation would determine that the input contained dangerous special characters (single quote and -); input sanitization would then remove these characters. 

While input validation and sanitization can be performed in the resolvers (execution stage), it is recommended to do it earlier, in the validation stage, when the AST is validated against the GraphQL schema to determine that only valid types and fields are being requested. In addition to the basic Int, Float, String, Booleans, types, you can additionally enforce that inputs match custom scalar types, like email addresses. This helps you identify the data and validate it before even transferring it to the server.

### Prepared statements
Prepared statements bind the actual data values to the placeholders in the template at runtime. 
For example, instead of writing a query like this:
```
SELECT * FROM users WHERE id = '123';
```

You would use a prepared statement in your resolver like this:
```
SELECT * FROM users WHERE id = ?;
```

The ? is a placeholder that temporarily takes the place of the data. The SQL query is pre-compiled with placeholders, and the user’s data is added later. This means that even if a nefarious actor submits a GraphQL query that looks like:
```
query {
 user(id: "22371' OR 1=1 ") {
 name, 
 email, 
 address, 
 contact
 }
} 
```
The initial SQL query logic won’t be changed. Instead, the database will look for a user admin whose password is literally “22371' OR 1=1 ”.

### Secure libraries, secure implementations
Several well-known languages have libraries and implementations of the GraphQL specification. Attackers take advantage of flaws in these servers or implementations. For example, the use of exec and execSync in @graphql-tools/git-loader before 6.2.6. allows arbitrary command injection. Therefore, it's crucial to pick secure libraries and versions while creating GraphQL APIs. You can learn more about public GraphQL implementations [here](https://inigo.io/blog/how_threat_actors_fingerprint_your_graphql_apis).

## Conclusion
GraphQL injection attacks may undermine critical web applications and systems. To prevent GraphQL injection attacks, it is essential to follow best practices around input validation and the use of secure libraries.

Security tooling often focus on REST APIs input validation and sanitization, leaving GraphQL APIs unaddressed. With [Inigo](https://inigo.io/blog/operation_name_security_in_graphql), you can establish rigid guidelines for which operation names (as well as other elements of the document) to accept from clients. This ensures that your policy is rigid regardless of which GraphQL servers you use. The following is an example configuration that validates optional names for a GraphQL API:
```
kind: Security
name: my_server
spec:
 validation:
 alias_name: "^[a-zA-Z]+$"
 directive_name: "^[a-zA-Z]+$"
 operation_name: "^[a-zA-Z]+$"
 arguments:
 String: "^[a-zA-Z]+$"
```

## Additional Resources
There are many resources available to help developers learn about GraphQL security and injection attacks, including
1. "[GraphQL Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/GraphQL_Cheat_Sheet.html)" by OWASP: This guide from OWASP covers the most common security risks associated with GraphQL and provides best practices for mitigating them.
2. “[Damn Vulnerable GraphQL Application](https://github.com/dolevf/Damn-Vulnerable-GraphQL-Application)” - Damn Vulnerable GraphQL Application is an intentionally vulnerable implementation of GraphQL to learn and practice GraphQL Security. 
3. “[The complete GraphQL Security Guide](https://wundergraph.com/blog/the_complete_graphql_security_guide_fixing_the_13_most_common_graphql_vulnerabilities_to_make_your_api_production_ready)” - This blog post discusses fixes to the 13 most common GraphQL vulnerabilities to make your API production ready.

Protecting your GraphQL APIs is critical, and this process may be aided with GraphQL security platforms like as Inigo, which operate with any GraphQL server. Inigo has schema-based access control, detailed analytics, dynamic rate-limiting, an easy UI, and much more to help you accelerate API adoption.

GraphQL Injection Attacks

large_Post_8_Illustration_1.webp

medium_Post_8_Illustration_1.webp

small_Post_8_Illustration_1.webp

thumbnail_Post_8_Illustration_1.webp

Post_8_Illustration_1.webp

GraphQL is becoming increasingly popular among technology leaders as a modernized replacement for legacy REST APIs. But with this shift comes new security risks. Unmanaged APIs can pose a threat to the enterprise in terms of unauthorized data access and breaches.

## Overview
CIOs and technology leaders are now likely aware of the growing popularity of GraphQL, the open source API query language. Like how Kubernetes adoption unfolded within organizations over the past few years, developers are largely leading the internal charge—championing GraphQL as a modernized replacement for legacy REST APIs.

According to Gartner, more than half of enterprises will be using GraphQL in production by 2025; in 2021, fewer than 10% were. This rapid shift is driven in part by the need to expose API data and functionality to third-party developers, which has become increasingly popular. GraphQL is a far more flexible, scalable, and easier-to-use option than REST. It’s become the cornerstone of widespread API modernization initiatives, and it is vastly more efficient and effective to use for developers.

However, with over 50% of APIs being “unmanaged”—and with enterprises producing and consuming an exponentially growing number of APIs—come new security risks.

What is an “unmanaged” API? Unmanaged APIs are APIs that have been created by a developer but are not discovered by the people who manage the GraphQL schema (i.e., the engineers/architects/CIO teams who are responsible for making sure that API development is efficient and secure, and that the schema itself is always optimized).

These unmanaged APIs are commonly referred to as “shadow APIs.” Going undiscovered and/or invisible, shadow APIs also prevent enterprise architects from optimizing schema planning and business logic across the organization. They then cannot enforce standards across subgraphs and manage resource consumption, resulting in Service Level degradation (latency) as well as inefficient and costly development. 
 
Furthermore, both shadow APIs and unsecured APIs pose an ongoing threat to the enterprise. The compliance and security teams lack the ability to enforce access control, detect anomalies, and secure the code, opening the organization to threats of unauthorized data access and breaches, as well as heavy financial and reputation losses. 

This raises the question: why are existing application gateways not sufficient to help with the transition to GraphQL? Most API and web application gateways that enterprises have in place cannot discover GraphQL traffic and cannot provide the depth and context necessary to deliver visibility, discoverability, or real-time protection. Because GraphQL operations are sent as a single request, it’s difficult to understand how that request is being handled and what services are being called; all GraphQL traffic is seen at a high level, without details or granularity.
Inigo was created to specifically address these gaps in API management, governance, and security for GraphQL APIs. Our solution goes into depth for each query, and with our innovative intellectual property, it not only makes GraphQL APIs visible and manageable but also provides real-time protection, Importantly, it delivers these capabilities regardless of the measures put in place by the developer, enabling CIOs and platform teams to move into API modernization with GraphQL with confidence. 

Inigo’s GraphQL gateway provides schema-based access control, so your team can define and enforce access policies based on the schema of your GraphQL APIs, rather than the underlying code. Doing so ensures that only authorized users and applications can access the data and functionality exposed by the APIs.

Second, Inigo delivers compliance with a full audit trail and PII detection. This allows your enterprise to track and monitor all of the interactions related to your GraphQL APIs, and to detect and prevent the leakage of sensitive personal information.

Third, Inigo provides protection from spec abuse, injections, and object-level rate limiting. This helps organizations prevent and mitigate different types of attacks, such as query overloads, data breaches, and service disruptions.

In addition to security, Inigo’s platform enhances the developer experience and adds key workflow efficiencies, including:

- Operations and performance optimization, which allows developers to monitor and improve the performance of their GraphQL APIs in real time.
- API lifecycle management with CI tools, which helps developers automate the deployment and testing of their GraphQL APIs.
- Schema planning, which enables developers to design and implement GraphQL APIs in a modular and extensible way.
- Granular query sub-graph analytics, which gives developers insights into the usage and behavior of their GraphQL APIs, and helps them to optimize and evolve them over time.

Inigo offers a more affordable solution compared to other data and analytics tools. It delivers GraphQL-specific capabilities that other tools are too expensive to apply to GraphQL deployments. Additionally, [Inigo is SOC-2 compliant](https://www.globenewswire.com/news-release/2023/01/11/2587241/0/en/Inigo-Achieves-SOC-2-Type-II-Compliance-Certification-for-GraphQL-Security-and-Management-Platform.html)—which means that it meets the strict security and compliance standards required by many organizations.

If you want to experience our solution, or see a demo, reach out to us at [sales@inigo.io](mailto:sales@inigo.io)


GraphQL in Enterprise - Are you Ready?

large_Post_8_Illustration.webp

medium_Post_8_Illustration.webp

small_Post_8_Illustration.webp

thumbnail_Post_8_Illustration.webp

Post_8_Illustration.webp

Significant increase in the adoption of GraphQL throughout 2023. Companies are increasingly seeking a path to modernize the way they build and manage APIs; GraphQL is increasingly the answer.

### What should you expect from GraphQL this year?

In short, a lot. We’re expecting a significant increase in the adoption of GraphQL throughout 2023. Companies are increasingly seeking a path to modernize the way they build and manage APIs; GraphQL is increasingly the answer. 

Simply put, the benefits that GraphQL provides for developers (and users) have become too consequential to ignore. With GraphQL, developers can create APIs tailored to a client's specific needs, rather than being limited to a fixed set of endpoints. That GraphQL benefit has always been there, but as the technology has grown up, so has the development of GraphQL frameworks and tools supporting teams in their API modernization initiatives. These tools are making it far easier for organizations to work with GraphQL and, just as significantly, increasingly sophisticated solutions are being developed to support GraphQL at greater scale. 

In addition to the continuous development of GraphQL frameworks and tools, we expect to see further refinement of the GraphQL specification and its ecosystem in the coming year. The GraphQL community is growing rapidly—accelerated by the work of the [GraphQL Foundation](https://graphql.org/foundation)—and this will lead to an increased focus on the specification (as well as the tools that support it).

As GraphQL becomes more widely adopted, there will also be an increased focus on security. Like other developer-driven movements, GraphQL posed new and urgent security and management challenges as enterprises use it at scale. Among these hurdles are protecting against GraphQL injection attacks, rate limiting, and developing best practices to prevent these attacks.

In 2023, we expect to see a significant increase in the use of dedicated and sophisticated security solutions that can handle GraphQL and the sensitive data that it often handles—such as financial and medical information, along with other types of personally identifiable information. (This isn’t just good practice—getting it right is mandatory to achieve regulatory compliance mandates.) These purpose-built GraphQL solutions and tools will be increasingly necessary as mainstream firewalls and intrusion detection systems struggle to keep up with the rapid evolution of GraphQL.

GraphQL is maturing, the technologies supporting it are maturing, and 2023 will be a particularly significant year for the API query language. It’s an exciting time, but teams and their organizations need to have their plan for GraphQL-at-scale—and the right tools—ready to go.


GraphQL 2023 Predictions

large_Blog_5_Illustration.webp

medium_Blog_5_Illustration.webp

small_Blog_5_Illustration.webp

thumbnail_Blog_5_Illustration.webp

Blog_5_Illustration.webp

We’re excited to announce that Inigo has achieved SOC 2 Type II compliance. With this certification, we stand alone as the only SOC-2 Type-II-certified company focused on GraphQL API security and governance.

## Overview
We’re excited to announce that Inigo has achieved SOC 2 Type II compliance. With this certification, we stand alone as the only SOC-2 Type-II-certified company focused on GraphQL API security and governance.

SOC 2 Type II requires organizations to meet the rigorous security, availability, processing integrity, confidentiality, and privacy standards set by the American Institute of Certified Public Accountants (AIPCA). In our comprehensive SOC 2 audit—performed by a third-party, Sensiba San Filippo, LLP (SSF)—our GraphQL API security and management platform fully demonstrated the robust controls required to achieve this certification and safeguard our customers’ crucial systems and sensitive data.

Earning SOC 2 compliance is a testament to the strength of our end-to-end security capabilities and processes. The designation also underscores our commitment to ensuring our customers can restrict data access to only authorized users and protect their modernized GraphQL APIs with the highest level of data security and privacy available.

We’re proud to share this major milestone for our company as part of our ongoing investment into Inigo’s security infrastructure. Our customers can take confidence that their data is under the continuous protection of the trustworthy and SOC-2-compliant Inigo platform.

- [Press Release Link](https://www.globenewswire.com/news-release/2023/01/11/2587241/0/en/Inigo-Achieves-SOC-2-Type-II-Compliance-Certification-for-GraphQL-Security-and-Management-Platform.html)

Your security peace-of-mind: We’re SOC 2 Type II Compliant

large_Best_New_Dev_Ops_Tool_400x400.webp

medium_Best_New_Dev_Ops_Tool_400x400.webp

small_Best_New_Dev_Ops_Tool_400x400.webp

thumbnail_Best_New_Dev_Ops_Tool_400x400.webp

Best_New_Dev_Ops_Tool_400x400.webp

We’re proud to announce that Inigo has been named one of the very few DevOps Dozen finalists in the Best New DevOps Tools category.

We’re proud to announce that Inigo has been named one of the very few [DevOps Dozen finalists](https://devopsdozen.com/) in the _Best New DevOps Tools_ category. The awards hone in on the “best, brightest, and most impactful” DevOps and developer tools from the past year across several categories.

As always, the DevOps Dozen are put together by the Techstrong Group, the company behind some of the best developer-centric cloud native and security publications—including DevOps.com, Container Journal, and Security Boulevard.

Here’s what DevOps Dozen had to say about our platform:

>“Inigo is a new GraphQL API management platform for DevOps/DevSecOps teams that offers a unique one-stop-shop for GraphQL API security, analytics, and developer productivity at scale. Inigo enables developers to avoid resource-heavy in-house tools that are costly to maintain and prone to errors. Inigo offers the absolute best developer experience around GraphQL APIs, so developer teams can scale with confidence and efficiency.”

We’re excited to be named a finalist in this newcomer category alongside some great new tools. If you’d like to throw your vote to Inigo as the category winner, [you can do that right here](https://www.surveymonkey.com/r/DevOpsDozenAwards2022)!



Inigo named one of the Best New DevOps Tools by the Techstrong Group

large_Operation_Name_Security.webp

medium_Operation_Name_Security.webp

small_Operation_Name_Security.webp

thumbnail_Operation_Name_Security.webp

Operation_Name_Security.webp

Experimenting with Operation Name characters. Despite the specification describing what characters should and should not be interpreted, there are deviations from the norm. This is why it is important to know your implementation well.

Operation Names in GraphQL are an optional string a client can specify to describe the operation, also called Named Operation ([Section 5.2.1](https://spec.graphql.org/October2021/#sec-Named-Operation-Definitions)) of the GraphQL specification.

The specification outlines the following rules as they relate to Operation Names:

- For each operation definition operation in the document.
- Let operationName be the name of operation.
- If operationName exists
-- Let operations be all operation definitions in the document named operationName.
-- operations must be a set of one.

This means that a document with more than one query or mutation must include operation names for each, and they must be uniquely named.

For example, the following document is valid:
```
query First {
 pastes {
 content 
 }
}

query Second {
 pastes {
 content 
 }
}
```
And this document is invalid because two queries use the same operation name, violating the uniqueness requirement:
```
query First {
 pastes {
 content 
 }
}

query First {
 pastes {
 content 
 }
}
```
This document is also invalid because only one query has a defined operation name in the document:
```
query First {
 pastes {
 content 
 }
}

query {
 pastes {
 content 
 }
}
```
When a request is sent to a GraphQL API with more than one operation, a client would need to specify the operationName JSON key with the specific named operation of interest to run it:
```
{
 "query":"query First { pastes { content } } query Second { pastes { content } }", 
 "operationName":"First", 
 "variables":[]
}
```
If the operationName JSON key is not defined but the query document contains two named operations, the GraphQL server may respond with the following:
```
{
 "errors": [
 {
 "message": "Must provide operation name if query contains multiple operations.",
 "extensions": {
 "code": "INTERNAL_SERVER_ERROR"
 }
 }
 ]
}
```
So, operation names are optional if a document contains one operation, but once it contains more than one, operation names are required and must be unique (i.e. not repeated).

Applications may log the operation names used by client queries for analytics and debugging. They are used by analytic tools to determine, for example, performant and non-performant queries and often are used instead of logging the entire query payload.
 
Have you ever asked yourself: what characters can be used in a named operation? Let’s see what is accepted versus not accepted with some Python-fu.

![Operation Name Structure.png](/uploads/Operation_Name_Structure_9345f3fdee.png)

## Experimenting with Operation Name Characters

For the purpose of this test, we used Sangria, Apollo, graphql-ruby, Graphene and HyperGraphQL as the targeted GraphQL servers a mix of seasoned and newer implementations, and used the following script to test various combination of operation name characters, while removing [ignored tokens](https://spec.graphql.org/October2021/#sec-Language.Source-Text.Ignored-Tokens) such as hashes (#) commas (,) and whitespace. 
```
import string
import time
import random
import requests

def randomize(N):
 random_int = random.randint(1, 7)
 strings = {1: string.ascii_lowercase + string.digits,
 2: string.ascii_lowercase + random.choice(string.punctuation),
 3: string.digits + random.choice(string.punctuation),
 4: string.punctuation,
 5: string.ascii_lowercase,
 6: string.digits,
 7: string.printable}

 chosen = strings[random_int]
 chosen = chosen.replace(' ', '')
 chosen = chosen.replace('#', '')
 chosen = chosen.replace(',','')
 chosen = random.sample(chosen, len(chosen))


 return ''.join(random.choice(chosen) for _ in range(N))


while True:
 opName = randomize(5)
 query = """
 query {0} {{
 __typename
 }}""".format(opName)


 r = requests.post('http://test.inigo.local', json={"query":query})

 if r.ok:
 print(f'Accepted: {opName}')
 else:
 print(f'Not accepted: {opName}')
```

Running the code produces the following results:
```
Accepted: k4qcb
Accepted: lzort
Not accepted: ]}VKV
Not accepted: 69071
Not accepted: \|&!~
Accepted: fclue
Not accepted: 2kxq6
Not accepted: $&${}
Accepted: _5157
Not accepted: +_'!)
Accepted: ztb0v
```
## Tests Breakdown

![Experimenting with Operation Names.png](/uploads/Experimenting_with_Operation_Names_bea8ce6a46.png)

Symbols such as greater than (>) or less than (<) typically used in Cross-Site Scripting payloads aren’t allowed, neither single-quotes or double quotes, equal sign, and others in most cases. One anomaly was **HyperGraphQL**, a Java-based GraphQL server, which allowed characters such as: `+><;^%~+ as operation name.

![Operation Name HyperGraphQL.png](/uploads/Operation_Name_Hyper_Graph_QL_7cd392d24d.png)


This was an interesting experiment. Despite the specification describing what characters should and should not be interpreted, there are deviations from the norm. This is why it is important to know your implementation well.

With Inigo, you can define strict rules on what operation names (as well as other components of the document) to accept from clients, so no matter what GraphQL servers you use, your policy is strict across all of them.
```
kind: Security
name: demo
label: starwars
spec:
 validation:
 alias_name: "^[a-zA-Z]+$"
 directive_name: "^[a-zA-Z]+$"
 operation_name: "^[a-zA-Z]+$"
 arguments:
 String: "^[a-zA-Z]+$"
```
Inigo can help you enforce the use of operation names across all your queries, in addition to applying a strict security policy so that operation names are limited to a safer subset of characters. Reach out to us for more information on how we can enforce security policies across all your GraphQL fleet

Operation name security in GraphQL

large_Array_based_Query_Batching.webp

medium_Array_based_Query_Batching.webp

small_Array_based_Query_Batching.webp

thumbnail_Array_based_Query_Batching.webp

Array_based_Query_Batching.webp

Watch out from array batching. It is possible to batch queries together by adding them to an array and sending them to a GraphQL server. This option is not available in all implementations and also isn’t specifically mentioned in the GraphQL specification.

In the [previous post](https://inigo.io/blog/defeating_controls_with_alias-based_query_batching), we discussed the way threat actors can optimize attacks to defeat authentication controls using query batching based on GraphQL aliases.

Aliases are great because they are part of the [GraphQL specification](https://spec.graphql.org/October2021/#sec-Field-Alias) as shown in section 2.5. So, when you run into a GraphQL API, you should expect to have aliases available at your fingertips.

Aliases have one disadvantage - they can only be applied to either queries, or mutations, but not both at the same time in a single HTTP request. Another approach to query batching is by using arrays.

It is possible to batch queries together by adding them to an array and sending them to a GraphQL server. This option is not available in all implementations and also isn’t specifically mentioned in the GraphQL specification. 

It is quite easy to test whether a GraphQL API support arrays, here is how you can do this in Python using the requests library:
```
import requests

queries = [
  {"query":"query { __typename }"},
  {"query":"query { __typename }"}
]

requests.post('http://localhost:5013/graphql', json=queries)
```
If you prefer cURL, you can test whether the GraphQL server supports arrays like so:
```
curl -X POST http://example.inigo.local/graphql -H "Content-Type: application/json" -d '[{"query":"query { __typename }"}, {"query":"query { __typename }"}]' 
```
The response that comes back to queries sent in an array would include multiple data keys, each containing a separate response:
```
[
   {"data":{"__typename":"Query"}},
   {"data":{"__typename":"Query"}}
]
```
When GraphQL servers see an array (and when they support them), they will process each query one after another in sequence, and return a response once all of them are resolved. Here is how the [Graphene-django implementation handles arrays](https://github.com/graphql-python/graphene-django/blob/master/graphene_django/views.py#L168-L179). 

![Array GraphQL.png](/uploads/Array_Graph_QL_ea12888890.png)

The advantage of arrays is that you can mix queries and mutations together, like so:
```
import requests

queries = [
  {"query":"query { __typename }"},
  {"query":"mutation { createUser(user:”user1”) { id } }}"}
]

requests.post('http://example.inigo.local/graphql', json=queries)
```
So, if you have an API flow that requires sending a mix of queries and mutations together to get to some desired state, arrays make it easier.  Aliases on the other hand can only be used to batch queries of the same root type. 

Arrays have one major disadvantage - they aren’t available everywhere. We recommend reading the documentation of the GraphQL implementation in use in your production environment to learn if arrays are supported (or simply try a query against it to figure it out) and whether they can be disabled. 

Whether you are using a popular GraphQL server or you’ve built your own, using Inigo’s GraphQL Security and Management platform works independently and is completely server-agnostic, which protects any GraphQL APIs and helps introduce security controls no matter what GraphQL server you use.


Defeating controls with Array-based Query Batching

large_Alias_based_Query_Batching.webp

medium_Alias_based_Query_Batching.webp

small_Alias_based_Query_Batching.webp

thumbnail_Alias_based_Query_Batching.webp

Alias_based_Query_Batching.webp

GraphQL isn’t immune to vulnerabilities, it may suffer from them just like any other API technologies such as REST, SOAP, gRPC, or others, but there are some unique and interesting possibilities that open up to hackers when GraphQL is present on the target they are interested in compromising.

GraphQL isn’t immune to vulnerabilities, it may suffer from them just like any other API technologies such as REST, SOAP, gRPC, or others, but there are some unique and interesting possibilities that open up to hackers when GraphQL is present on the target they are interested in compromising.

Vulnerability classes such as Injection, Denial of Service, Forgery, Lack of Resource & Rate Limiting as well as others, can all apply to GraphQL APIs. However, what’s interesting in GraphQL is the new ways it allows threat actors to optimize certain attacks, specifically those that fall under the category of denial of service and defeating authentication mechanisms.

![Secured GraphQL.png](/uploads/Secured_Graph_QL_f702a31dbb.png)

Aliases in GraphQL allow clients to rename response keys of fields and use the same query operation more than once. Let’s first see what happens when a client asks for simple information such as the ID of users:
```
query {
  users {
    id
  }
}
```
And the response:
```
{
  "data": {
    "users": [
      {
        "id": "1"
      },
      {
        "id": "2"
      }
    ]
  }
}
```
If a client attempts to fetch the same information more than once this way:
```
query {
  users {
    id
  }
  users {
    id
  }
}
```
Then the response returned by the GraphQL server will only return a single users key in the response:
```
{
  "data": {
    "users": [
      {
        "id": "1"
      },
      {
        "id": "2"
      }
    ]
  }
}
```
The JSON structure we get back from the GraphQL server returns a single key, so the response of two operations is consolidated to a single response key.

Aliases in GraphQL allow you to rename the operation name (and hence the JSON key in the response). Aliases can be configured by prefixing the field of interest with some named alias:
```
query {
  nameOne: users {
    id
  }
  nametwo: users {
    id
  }
}
```
Which results in the GraphQL server returning the following response:
```
{
  "data": {
    "nameOne": [
      {
        "id": "1"
      },
      {
        "id": "2"
      }
    ],
    "nametwo": [
      {
        "id": "1"
      },
      {
        "id": "2"
      }
    ]
  }
}
```
This allows you to run multiple queries and rename their response key, which allows you to get separate responses. 

GraphQL APIs just like any other API can perform sensitive actions such as:
1. User login
2. User password resets
3. User signup
4. Token verification
5. Code verification

This list is just the tip of the iceberg, there could be more options, but you get the point. 

Back to aliases - aliases allow you to “stuff” multiple operations in a single HTTP request. Does that ring any of your security bells? It should, because traditional security controls could struggle identifying malicious behavior if they rely on certain characteristics that are more relevant to non-GraphQL based APIs. For example:

- HTTP Method (POST/GET)
- API Route (e,g, /v1/login)
- Number of clients requests made (e.g. 100 per minute)
- The returned HTTP code

Looking at all of these as indicators of potential compromise attempt makes sense in the context of security: If a client makes a POST request to the /v1/login endpoint 100 times in 5 seconds and the response code is 401 Unauthorized, maybe this client is attempting to brute force accounts on your application. These heuristics make sense in non-GraphQL APIs. In GraphQL, the heuristics are a little different.

In GraphQL, the client intention is not expressed by the HTTP verb, route, or the returned code (in many cases) but by the query payload. Determining how the GraphQL server handled the query is expressed in the response versus any HTTP headers.

So, if you have a login GraphQL query that takes in an email and password, it would look like the following:
```
query {
  login(email:"user123@example.com", password:"abc") {
    token
  }
}
```
With aliases, we can now perform multiple login attempts and send those over a single HTTP request:
```
query {
 attemptOne: login(email:"user123@example.com", password:"abc") {
    token
 }
 attemptTwo: login(email:"user123@example.com", password:"def") {
    token
 }
 attemptThree: login(email:"user123@example.com", password:"geh") {
    token
 }
}
```
This query structure could circumvent security controls that perform rate limiting that bases its heuristics on the volume of client requests combined with the HTTP method and API route being used. As GraphQL adopters, it’s important to find a solution that can protect your APIs and identify malicious behavior more tailored to GraphQL APIs.

Aliases can be used to batch any query (or mutation) but not both at the same time. In the next post, we will cover another method of query batching that allows mixing these two types together.


Defeating controls with Alias-based Query Batching

Public_Graph_QL_Vulnerability_Header.webp

large_Public_Graph_QL_Vulnerability_Header.webp

medium_Public_Graph_QL_Vulnerability_Header.webp

small_Public_Graph_QL_Vulnerability_Header.webp

thumbnail_Public_Graph_QL_Vulnerability_Header.webp

We spent a few days examining data from two main sources: The CVE database by MITRE and the HackerOne Hacktivity portal to see what we can learn from analyzing GraphQL vulnerability data.

## Overview
One way to learn about GraphQL security is by analyzing public information related to vulnerabilities impacting GraphQL components such as GraphQL clients (like Relay) or GraphQL servers (like Apollo, Graphene, Ariadne, and even products like GitLab Enterprise, Magento, etc). We spent a few days examining data from two main sources: The CVE database by MITRE and the HackerOne Hacktivity portal to see what we can learn from analyzing vulnerability data.

![Public GraphQL Vulnerability .png](/uploads/Public_Graph_QL_Vulnerability_78fe425985.png)

## GraphQL Vulnerability Data Analysis - MITRE CVE Database
The [MITRE CVE](https://cve.mitre.org/) database is the source of truth for CVEs. Before diving into the dataset, it’s important to highlight a few important things about the database:

1. Not all vulnerabilities are reported.
2. Not all vulnerabilities receive a CVE identifier.
3. Some vulnerabilities are reported but never get a CVE identifier assigned.

The reason this is important to highlight is, while the CVE database is a good data sample, it is not a comprehensive list of vulnerabilities. 

Generally speaking, vulnerabilities get a CVE identifier when either the vendor of the software impacted by the vulnerability or the researcher who found the flaw engages MITRE and files a CVE request. Some software vendors are authorized to issue their own software a CVE identifier, these vendors are acting as a CNA (CVE Numbering Authority) and you can find the list of CNA partners [here](https://www.cve.org/PartnerInformation/ListofPartners), on this list you can find vendors such as GitLab, Adobe, GitHub, and more.

To get an idea of the GraphQL vulnerability dataset, we used the MITRE CVE database search option, where you can perform a free-text search. Here is what the search-term “GraphQL” brings up:

![Public GraphQL Vulnerability CVE list.png](/uploads/Public_Graph_QL_Vulnerability_CVE_list_a4d1d63633.png)

Having access to this dataset, a few questions came up:

1. How many vulnerabilities are there with CVEs?
2. What are the most common vulnerability classes?
3. When was the first vulnerability tracked?
4. Which GraphQL component has the most CVEs?

### How many vulnerabilities are there with CVEs?
The search yielded a [few dozen](https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=graphql) (45) CVEs related to GraphQL components, such as GraphQL servers, GraphQL client libraries, and so on. 

### What are the most common GraphQL vulnerability classes?
Authorization (54%) and DoS-based (16%) vulnerabilities were the most popular vulnerability classes, as shown in the pie chart below.

![Public GraphQL Vulnerability CVE.png](/uploads/Public_Graph_QL_Vulnerability_CVE_4fb711cdb8.png)

### When was the first vulnerability tracked?
Purely based on the CVE identifier strings, the oldest entry is from 2019 (CVE-2019-1000011) this is likely not the first ever vulnerability found in software with GraphQL, but it’s the oldest found in MITRE’s database.

### Which GraphQL software has the most CVEs?
This data is likely skewed by the popularity of the component itself, and is not indicative of how hardened a component is or is not, but nevertheless it is interesting data to analyze:

![Public GraphQL Vulnerability CVE By Component.png](/uploads/Public_Graph_QL_Vulnerability_CVE_By_Component_6820b932c8.png)

## GraphQL Vulnerability Data Analysis -  HackerOne
The [HackerOne](https://hackerone.com/) vulnerability database is a great resource to learn about the types of vulnerabilities researchers report on and get credited for. We performed a search against the public reports on HackerOne to see what types of vulnerabilities have been reported so far.

Since 2018, 74 vulnerabilities have been reported to various companies and bounties ranging anywhere from $250 to north of $20,000 were granted. Most vulnerabilities were in the category of Authorization flaws (87%), followed by DoS (7%) and others (5%)

![Public GraphQL Vulnerability Hacker One.png](/uploads/Public_Graph_QL_Vulnerability_Hacker_One_b985cdcb99.png)

Security researchers participating in bug bounty programs are often motivated by money, and authorization-related vulnerabilities very often result in data leakages and impact to personal identifiable information (PII) - these vulnerabilities are considered to be the most critical to companies and the reward for finding such vulnerabilities is, as such, very incentivizing - so it comes as no surprise that most ethical hackers will test for authorization flaws before anything else.

One important fact about Bug Bounty programs is that testing for Denial of Service-based vulnerabilities is more often than not disallowed (and many times their bounties are also comparatively low where it is allowed), this is reflected in the chart by the limited number of reported DoS vulnerabilities.

GraphQL continues to be interesting both from an offensive as well as a defensive standpoint. Inigo’s GraphQL Security and Management solution helps address Authorization, Denial of Service, as well as other classes of vulnerabilities in GraphQL APIs. 

## Conclusion
GraphQL, with its free-form nature, introduces a new paradigm of attack surfaces. Inigo can help to put the proper guardrails in place, whether you are just starting or already have GraphQL in production. Learn more [here](https://inigo.io/demo).




Analysis of public GraphQL vulnerability reports

Defending_Graph_QL_AP_Is_Challenging_to_Security_Engineers.webp

large_Defending_Graph_QL_AP_Is_Challenging_to_Security_Engineers.webp

medium_Defending_Graph_QL_AP_Is_Challenging_to_Security_Engineers.webp

small_Defending_Graph_QL_AP_Is_Challenging_to_Security_Engineers.webp

thumbnail_Defending_Graph_QL_AP_Is_Challenging_to_Security_Engineers.webp

It’s not enough to know how GraphQL works and how it can be attacked, what also matters a lot is whether security professionals have the necessary tools to identify suspicious queries, exploitation attempts, and solutions to protect against GraphQL-tailored attacks.

While GraphQL has been around for at least seven years since the first reference implementation [graphql-js](https://github.com/graphql/graphql-js) was released to the public in July 2015, many security professionals are not yet caught up with it. It’s not enough to know how GraphQL works and how it can be attacked, what also matters a lot is whether security professionals have the necessary tools to identify suspicious queries, exploitation attempts, and solutions to protect against GraphQL-tailored attacks.

Whether you have a Web Application Firewall (Cloudflare, Modsecurity, or other) monitoring your application for security events, or you’ve built an in-house monitoring solution based on standard access logs to detect suspicious behavior in web applications, you have probably developed some dependency on key indicators such as:

- HTTP methods (verbs)
- HTTP response status codes
- Sensitive API Routes
- API parameters

These indicators are helpful when you want to monitor for specific events, such as:

1. Clients hammering your registration endpoint
2. Clients attempting to login unsuccessfully multiple times
3. Clients attempting to perform account enumeration
4. Clients tampering with parameters of interest

Monitoring for such events in REST APIs is pretty trivial and requires a few things to be in place: it requires the protected application to follow [RFC2616](https://www.rfc-editor.org/rfc/rfc2616.html) when it comes to the returned HTTP status codes so the signals make sense to clients as well as the security engineering team, and it requires the security team to have a pretty good idea (and an inventory) of their APIs.

Traditional monitoring systems use HTTP components for monitoring. Here is an example of a pseudo-monitoring rule that could be beneficial to the security team in particular:

```
alert if (http.method=GET and response.status_code=403 and http.uri=”/v1/user/<id>/profile”) 
```

This example rule relies on the HTTP method (GET), a response code (403 Forbidden) and a specific route (/v1/user/id/profile), which will mostly be available in the case of REST APIs, but what about GraphQL?

![Inigo Observeability.png](/uploads/Inigo_Observeability_4a6f09d1de.png)

GraphQL uses a single GraphQL route (/graphql is pretty common). The reason routes don’t matter in GraphQL APIs is because client intentions are all based on the query payload. While it’s true GET and POST are in use in GraphQL APIs, it does not reflect what the client is ultimately trying to do, this is all derived from the query.

Going back to the case of monitoring APIs for security events, this design of GraphQL renders traditional security monitoring approaches pretty useless. Monitoring rules as shown above will no longer work, and different tools will be required to achieve the objective.

Not only is there an issue with the single route, GraphQL APIs don’t depend on normal HTTP status codes. It’s often the case that a GraphQL API will return a 200 OK to any query, while any errors will be reflected by the response payload coming back from the server using a dedicated **errors** JSON key with the error message relevant to what went wrong.

For instance, take a look at the example query below that allows a user to fetch their own user details by passing a numerical user ID:
```
query {
 user(id: 1000) {
 email
 name
 address
 }
}
```

If the calling client has authorization to view user ID 1000 and that ID exists, then such query would result in a response such as:
```
{
 "data": {
 "user": [
 {
 "email": "test@example.com",
 "name": "test user",
 "address": "123 Hollywood Blvd",
 }
 ]
 }
}
```

If the calling client does not have the right authorization level, a GraphQL response might look like the following:
```
{
 "errors": [
 "message": “You are not authorized to view this user.”
 ]
}
```

If the user ID does not exist on the system, a GraphQL response might look like the following:
```
{
 "errors": [
 "message": “User with ID 1000 does not exist”
 ]
}
```

The HTTP code to all three conditions could be a consistent 200 OK from the GraphQL server, which is why GraphQL is more challenging to monitor than traditional REST APIs. If your monitoring solutions are based on standard HTTP access logs, be prepared to see a lot of log lines that look like the following:

```
1.2.3.4 - - [02/Aug/2022:18:27:46 +0000] "POST /graphql HTTP/1.1" 200 - "-"
"curl/7.43.0" - 539
1.2.3.4 - - [02/Aug/2022:18:27:46 +0000] "POST /graphql HTTP/1.1" 200 - "-"
"curl/7.43.0" - 539
1.2.3.4 - - [02/Aug/2022:18:27:46 +0000] "POST /graphql HTTP/1.1" 200 - "-"
"curl/7.43.0" - 539
```

You can’t do a whole lot with this. For monitoring security events, you will need a view into the query payload, as well as the response payload, and a solution that can contextualize these events for you. To make matters worse, GraphQL allows batching multiple queries into a single HTTP request, therefore allowing threat actors to hide multiple actions in a single HTTP packet:

```
query {
 alias1000: user(id: 1000) {
 email
 name
 address
 }
 alias1001: user(id: 1001) {
 email
 name
 address
 }
 alias1002: user(id: 1002) {
 email
 name
 address
 }
}
```

When such a query is made, you will only see a single incoming HTTP request, despite the fact that 3 queries were made. 

If you thought it stops here, we’ve got some news for you: it is also possible to batch queries using an array against some GraphQL servers that support it, like so:

```
import requests

queries = [
 {
 "query":"query { user(id: 1000) { email name address }}",
 "query":"query { user(id: 1001) { email name address }}",
 "query":"query { user(id: 1002) { email name address }}"
 }
]

r = requests.post('http://test.inigo.local/graphql', json=queries)

print(r.json())
```

Inigo can help provide you with an observability layer tailored to GraphQL that handles these cases too.

What makes defending GraphQL APIs challenging to security engineers

How_Threat_Actors_Fingerprint_your_Graph_QL_AP_Is.webp

large_How_Threat_Actors_Fingerprint_your_Graph_QL_AP_Is.webp

medium_How_Threat_Actors_Fingerprint_your_Graph_QL_AP_Is.webp

small_How_Threat_Actors_Fingerprint_your_Graph_QL_AP_Is.webp

thumbnail_How_Threat_Actors_Fingerprint_your_Graph_QL_AP_Is.webp

You’ve identified a GraphQL server, now what? Well, the next step in the process is to learn all you can about the specific server.

In previous blog posts, we discussed what’s involved in the process of [detecting GraphQL servers](https://inigo.io/blog/how_threat_actors_detect_your_graphql_apis). Threat actors don’t stop there, the identification of a target is only the initial step in the process of achieving the greater goal of compromising a GraphQL API target. 

You’ve identified a GraphQL server, now what? Well, the next step in the process is to learn all you can about the specific server. You may be asking yourself, aren’t all GraphQL servers the same; they just provide an API layer to some application? While this is true, the first thing you should know is that there are **many** GraphQL server implementations, not all of them are mature, and not all of them are well maintained.

Let’s explore some of the GraphQL servers that are out there today. A good source for this is the [https://graphql.org/code](https://graphql.org/code) website, which lists client libraries, servers, tools as well services by the language they were written in. For this post, we’re going to focus only on server implementations. Below chart illustrates the number of GraphQL server implementations available today by language. You can find the detailed table at the bottom of this post.

![GraphQL Servers Breakdown.png](/uploads/Graph_QL_Servers_Breakdown_fd16991ddd.png)

As you can see, there are many different server implementations. Most notable are PHP (22.8%) Golang (12.3%) JavaScript (10.5%) Java (8.8%) and Python (7%).

Why is this important? When threat actors target an application or server, they need to gather a few key data points to increase their chances of successfully breaking in:

1. What platform is running?
2. Is the source code available?
3. What version is it on?
4. Are there any known vulnerabilities for it?
5. Are there any available exploits for the vulnerabilities?
6. What security features are built into it?
7. Are there any insecure settings shipped by default?

To be able to know the answer to these questions, you first need to fingerprint the target. But how do you fingerprint an API? Since GraphQL is just an API layer, you may be asking yourself: how would someone know what GraphQL implementation it is if they should all conform with the specification and return the same predictable response structure? Well, if you craft a careful enough payload that the server does not expect, all it will take is a small and subtle difference in the response to distinguish one server from another. Let’s explore what this looks like.

![GraphQL Server Fingerprint.png](/uploads/Graph_QL_Server_Fingerprint_3a6d01008b.png)

GraphQL supports three operation types: query, mutation and subscription as described in section 2.3 Operations in the [GraphQL specification](https://spec.graphql.org/October2021/#sec-Language.Operations). What would happen if an operation that doesn’t exist is provided, and what would the server respond with? Let’s find out:

```
queryyy { # notice the typo
   __typename
}
```

Using curl, we will send this malformed query to an Apollo-based GraphQL server


```
$ curl -s -X POST http://apollo.example.local -H "Content-Type: application/json" -d '{"query":"queryyy { __typename }"}' | jq

{
  "errors": [
    {
      "message": "Syntax Error: Unexpected Name \"queryyy\".",
      "extensions": {
        "code": "GRAPHQL_PARSE_FAILED"
      }
    }
  ]
}
```

So, we have an errors key with a message of **Syntax Error: Unexpected Name \"queryyy\"**. Now, let’s do the same against a Graphene-based GraphQL server, a Python-based implementation.

```
$ curl -s -X POST http://graphene.example.local -H "Content-Type: application/json" -d '{"query":"queryyy { __typename }"}' | jq

{
  "errors": [
    {
      "message": "Syntax Error GraphQL (1:1) Unexpected Name \"queryyy\"\n\n1: queryyy { __typename }\n   ^\n",
      "locations": [
        {
          "line": 1,
          "column": 1
        }
      ]
    }
  ]
}
```

Now we see that the error message is a little different. For example, instead of **Syntax Error** we now get **Syntax Error GraphQL** in the error message. This is an obvious difference that can help us pinpoint the implementation. 

Tools that perform GraphQL fingerprinting surfaced over the years, such as [Graphw00f](https://github.com/dolevf/graphw00f) that make use of these subtle differences to arm ethical hackers with the necessary knowledge and give them the ability to perform more educated guesses during penetration tests.

We mentioned earlier that some implementations are more mature than others, and offer protections that others don’t. In future posts, we will cover various vulnerabilities of different implementations. Whether you are using a popular GraphQL server implementation, or completely wrote your own custom implementation, Inigo abstracts your GraphQL API layer and provides security protections so you don’t need to worry about securing your GraphQL server, we do that for you.  

## List of GraphQL server implementations available as of this writing


| #  | Implementation                       | Language   | URL                                                           |
| -- | ------------------------------------ | ---------- | ------------------------------------------------------------- |
| 1  | graphql-js                           | JavaScript | https://graphql.org/graphql-js/                               |
| 2  | apollo                               | JavaScript | https://github.com/apollographql/apollo-server                |
| 3  | graphql-yoga                         | JavaScript | https://github.com/dotansimha/graphql-yoga                    |
| 4  | express-graphql                      | JavaScript | https://github.com/graphql/express-graphql                    |
| 5  | mercurius                            | JavaScript | https://github.com/mercurius-js/mercurius                     |
| 6  | graphql-helix                        | JavaScript | https://github.com/contra/graphql-helix                       |
| 7  | graphql-go                           | Golang     | https://github.com/graphql-go/graphql                         |
| 8  | gqlgen                               | Golang     | https://github.com/99designs/gqlgen                           |
| 9  | graphql-go (graph-gophers)           | Golang     | https://github.com/graph-gophers/graphql-go                   |
| 10 | thunder                              | Golang     | https://github.com/samsarahq/thunder                          |
| 11 | graphql-relay-go                     | Golang     | https://github.com/graphql-go/relay                           |
| 12 | jaal                                 | Golang     | https://github.com/appointy/jaal                              |
| 13 | eggql                                | Golang     | https://github.com/andrewwphillips/eggql                      |
| 14 | api-platform                         | PHP        | https://api-platform.com/                                     |
| 15 | graphql-php                          | PHP        | https://github.com/webonyx/graphql-php                        |
| 16 | WPGraphQL                            | PHP        | https://github.com/wp-graphql/wp-graphql                      |
| 17 | Lighthouse                           | PHP        | https://github.com/nuwave/lighthouse                          |
| 18 | Siler                                | PHP        | https://github.com/leocavalcante/siler                        |
| 19 | GraphQLBundle                        | PHP        | https://github.com/overblog/GraphQLBundle                     |
| 20 | GraphQLite                           | PHP        | https://github.com/thecodingmachine/graphqlite                |
| 21 | Ralit                                | PHP        | https://github.com/railt/railt                                |
| 22 | graphql-relay-php                    | PHP        | https://github.com/ivome/graphql-relay-php                    |
| 23 | GraphQL by PoP                       | PHP        | https://github.com/leoloso/PoP                                |
| 24 | GraphQL API for WordPress            | PHP        | https://github.com/leoloso/PoP                                |
| 25 | GraPHPinator                         | PHP        | https://github.com/infinityloop-dev/graphpinator              |
| 26 | serge                                | PHP        | https://github.com/kepawni/serge                              |
| 27 | graphql-java                         | Java       | https://github.com/graphql-java/graphql-java                  |
| 28 | Domain Graph Service (DGS) Framework | Java       | https://github.com/netflix/dgs-framework                      |
| 29 | graphql-kotlin                       | Java       | https://github.com/ExpediaGroup/graphql-kotlin                |
| 30 | GraphQL Spring Boot                  | Java       | https://github.com/graphql-java-kickstart/graphql-spring-boot |
| 31 | KGraphQL                             | Java       | https://github.com/aPureBase/KGraphQL                         |
| 32 | graphql-dotnet                       | C# / .NET  | https://github.com/graphql-dotnet/graphql-dotnet              |
| 33 | Hot Chocolate                        | C# / .NET  | https://github.com/ChilliCream/hotchocolate                   |
| 34 | NGraphQL                             | C# / .NET  | https://github.com/rivantsov/ngraphql                         |
| 35 | Graphene                             | Python     | https://github.com/graphql-python/graphene                    |
| 36 | Strawberry                           | Python     | https://github.com/strawberry-graphql/strawberry              |
| 37 | Ariadne                              | Python     | https://github.com/mirumee/ariadne                            |
| 38 | Tartiflette                          | Python     | https://github.com/tartiflette/tartiflette                    |
| 39 | Graphiti                             | Swift      | https://github.com/GraphQLSwift/Graphiti                      |
| 40 | GraphZahl                            | Swift      | https://github.com/nerdsupremacist/GraphZahl                  |
| 41 | Juniper                              | Rust       | https://github.com/graphql-rust/juniper                       |
| 42 | Async-graphql                        | Rust       | https://github.com/async-graphql/async-graphql                |
| 43 | graphql-ruby                         | Ruby       | https://github.com/rmosolgo/graphql-ruby                      |
| 44 | Agoo                                 | Ruby       | https://github.com/ohler55/agoo                               |
| 45 | Absinthe                             | Elixir     | https://github.com/absinthe-graphql/absinthe                  |
| 46 | graphql-elixir                       | Elixir     | https://github.com/graphql-elixir/graphql                     |
| 47 | Sangria                              | Scala      | https://github.com/sangria-graphql/sangria                    |
| 48 | Caliban                              | Scala      | https://github.com/ghostdogpr/caliban                         |
| 49 | Iacinia                              | Clojure    | https://github.com/walmartlabs/lacinia                        |
| 50 | graphql-cli                          | Clojure    | https://github.com/tendant/graphql-clj                        |
| 51 | alumbra                              | Clojure    | https://github.com/alumbra/alumbra                            |
| 52 | Morpheus GraphQL                     | Haskell    | https://github.com/morpheusgraphql/morpheus-graphql           |
| 53 | Mu-Haskell                           | Haskell    | https://github.com/higherkindness/mu-haskell                  |
| 54 | ocaml-graphql-server                 | OCaml      | https://github.com/andreas/ocaml-graphql-server               |
| 55 | graphql-erlang                       | Erlang     | https://github.com/jlouis/graphql-erlang                      |
| 56 | ghql                                 | R          | https://github.com/ropensci/ghql                              |
| 57 | gorm-graphql                         | Groovy     | https://github.com/grails/gorm-graphql                        |
| 58 | graphql-perl                         | Perl       | https://github.com/graphql-perl/graphql-perl                  |
| 59 | graphqld                             | D          | https://github.com/burner/graphqld                            |




How threat actors fingerprint your GraphQL APIs

How_Threat_Actors_Detect_your_Graph_QL_AP_Is_Header.webp

medium_How_Threat_Actors_Detect_your_Graph_QL_AP_Is_Header.webp

small_How_Threat_Actors_Detect_your_Graph_QL_AP_Is_Header.webp

thumbnail_How_Threat_Actors_Detect_your_Graph_QL_AP_Is_Header.webp

Threat actors are after your APIs. Whether it’s your data that they’re interested in, or abusing your services for their financial gain.

Threat actors are after your APIs. Whether it’s your data that they’re interested in, or abusing your services for their financial gain. The reasons why threat actors target different organizations can vary, but one of the first steps they take in their hacking methodology is often consistent and predictable - **information gathering** or **reconnaissance**.

When hackers gather information on a target application, they do so both passively and actively. Passive information gathering does not involve sending packets to the targeted application - it involves gathering information through other channels that are indirect to the main application or the company operating it as a means to remain stealthy (but not only). For example, passive information gathering can be done by looking up the company’s name on GitHub in hopes of finding public repositories that could give them hints on what technologies are in use, or to find credentials that were hard-coded but forgotten about that they can then reuse.

Active information gathering involves communicating with the application, this requires the threat actors to send some traffic to the application. Imagine you are defending a large-scale application that serves millions of clients. You can appreciate how difficult it becomes to identify anomalous behavior if you don’t know what anomalous traffic could look like. Inigo’s solution not only allows cherry-picking those GraphQL queries that are targeting your application in a riskier way and surface the interesting ones to your security team, but also block and alert on them.

![How Threat Actors Detect your GraphQL APIs.png](/uploads/How_Threat_Actors_Detect_your_Graph_QL_AP_Is_26f3a8ef35.png)

## GraphQL Endpoint Detection
GraphQL introduces a shift in how clients request their data from applications using its innovative declarative query language. In GraphQL, clients express their intent using a query payload. If you ever used REST APIs, you may recall that in REST, a client’s intention is expressed by the combination of the HTTP method (GET, PUT, POST, DELETE) and the resource path (such as /v1/users).  For instance, a GET request to /v1/users would result in fetching the list of all users of a given application.

GraphQL, on the other hand, uses a single endpoint (such as /graphql) and some query to fetch a list of users. Such query could look like the following:
```
users {
   name
   email
}
```

So, how can threat actors discover whether an application is using GraphQL or another API technology? They do so by sending some query (the query does not have to be a valid one) to a list of possible endpoints that GraphQL may exist on, and observing the responses returned by the server.

For example, this is how a cURL request to a GraphQL endpoint could look like:
```
$ curl https://example.inigo.io/graphql -d '{"query":"query { users { name email } }"}' -H "Content-Type: application/json"
```

A typical GraphQL response is in JSON, and includes data or errors (or both) objects, which give away the fact this is a GraphQL API that responded:
```
{"errors":[{"message":"Cannot query field \"users\" on type \"Query\".","extensions":{"code":"GRAPHQL_VALIDATION_FAILED"}}]}
 ```

This method can then be automated so queries run against multiple endpoints in parallel. Possible endpoints could be:
- /graphql
- /query
- /api
- /playground
- /console
- /graphiql

If API versioning is in place, you may find GraphQL located in paths such as:
- /v1/graphql
- /v2/graphql
- /v1/query
- /v2/query
- /v1/console
- /v2/console

As you can see, APIs can be present in different locations. GraphQL servers can also be customized to point to a completely arbitrary location that isn’t on the list above. However, GraphQL API responses are often predictable, as dictated by the official GraphQL specification [Response Format](https://spec.graphql.org/October2021/#sec-Response-Format) section (7.1), allowing actors to identify that GraphQL is the interface which they are interacting with. Here is an excerpt of the response format section:

> A response to a GraphQL request must be a map.
If the request raised any errors, the response map must contain an entry with key errors. The value of this entry is described in the “Errors” section. If the request is completed without raising any errors, this entry must not be present.
If the request included execution, the response map must contain an entry with key data. The value of this entry is described in the “Data” section. If the request failed before execution, due to a syntax error, missing information, or validation error, this entry must not be present.
The response map may also contain an entry with key extensions. This entry, if set, must have a map as its value. This entry is reserved for implementors to extend the protocol however they see fit, and hence there are no additional restrictions on its contents.

This means that keys such as **data**, **errors** and **extensions** are all keys you may find in a GraphQL response. Armed with this knowledge, threat actors can build this logic into scanning tools to find where your GraphQL APIs live. In a future post, we will explore what threat actors might do after a GraphQL server was found.

When threat actors are performing an information gathering activity, they typically try different variations of queries. Some may be valid, some may not. Invalid queries could result in server exceptions. Inigo’s solution provides a layer of protection for your GraphQL APIs, our unique position in your architecture allows us to detect malformed queries against existent and non-existent endpoints and mitigate against such activity. Using our GraphQL Security and Management solution. Reach out to us for more information. 




How threat actors detect your GraphQL APIs

large_inigo_joins_graphql_foundation.webp

medium_inigo_joins_graphql_foundation.webp

small_inigo_joins_graphql_foundation.webp

thumbnail_inigo_joins_graphql_foundation.webp

inigo_joins_graphql_foundation.webp

Inigo is proud to announce it is the newest member of the <a target="_blank" href="https://graphql.org/foundation">GraphQL Foundation</a>, the powerful and supportive community dedicated to promoting the widespread adoption of GraphQL and accelerating the development of its surrounding ecosystem.

As a technology company fully focused on building the best and most secure GraphQL API experiences for developers, DevOps teams, and security architects, we are incredibly excited by Inigo's growing role in the GraphQL ecosystem. The open source data query language has proven—over and over again and at scale—that teams can confidently escape REST API limitations and build faster and more stable applications. Developers have largely driven the rise of GraphQL within their organizations, as they seek ways to more easily unlock the potential of APIs and harness more powerful developer tools.

Today, Inigo is proud to announce it is the newest member of the prestigious [GraphQL Foundation](https://graphql.org/foundation), the powerful and supportive community dedicated to promoting the widespread adoption of GraphQL and accelerating the development of its surrounding ecosystem. We join a select group of companies, including AWS, Meta, Twitter, Goldman Sachs, and PayPal, invested in the long-term success of GraphQL. Purpose-built to be an easy on-ramp that ensures teams can realize GraphQL’s full potential while hardening security around it, Inigo is closely aligned with the GraphQL Foundation’s goals. 

Inigo is a platform-agnostic, plug-and-play GraphQL API management platform that is ready to support any of the open source or commercial GraphQL servers available today. By doing so, Inigo evens the playing field wherever support gaps exist within particular GraphQL server options—ensuring that developers and organizations can be successful with the implementations of their choice. Additionally, Inigo provides visibility and analytics to help early adopters quickly master their GraphQL deployments and usage patterns. 

Developers and DevOps teams also gain the monitoring and observability tools they need to operate and scale GraphQL servers efficiently, and use real-time data to detect and avoid break change incidents. Inigo enhances developer experiences with CI/CD tooling that eliminates challenging custom builds and fixes, empowering developers to focus instead on core tasks. The GraphQL API management platform delivers high-throughput and low-latency that lets developers work faster, along with plug-and-play ease of integration (ready in 20 minutes or less). 

From a security perspective, Inigo automatically defends GraphQL attack surfaces from the full spectrum of cyberattacks, offering a developer-driven approach to enabling protections against GraphQL vulnerabilities. Inigo empowers security architects by providing declarative configuration and schema-based access control for introspection separation (with field and argument granularity).

The team at Inigo is excited to bring first-class capabilities to GraphQL users and offer developer-friendly alternatives to existing tooling—and especially now as a member of the GraphQL Foundation. Inigo is currently in beta, and eager to engage with early users to demonstrate how they can use the platform to supercharge their GraphQL visibility, operations, security, and success.

Inigo is a proud new member of the GraphQL Foundation

All_the_knobs_Graph_QL_Guardrails_Cover.webp

large_All_the_knobs_Graph_QL_Guardrails_Cover.webp

medium_All_the_knobs_Graph_QL_Guardrails_Cover.webp

small_All_the_knobs_Graph_QL_Guardrails_Cover.webp

thumbnail_All_the_knobs_Graph_QL_Guardrails_Cover.webp

GraphQL DoS (Denial of Service) attacks target GraphQL parsers, GraphQL resolvers, and the underlying DBs in a single API call.
It is possible to protect your server from GraphQL's attack surfaces with a set of guardrails and GraphQL usage-based rate-limiting.

So far, we've covered [GraphQL Security Awareness](https://inigo.io/blog/how-secure-is-your-graph-ql-server) and have understood that [No, You Don't Need to Disable Introspection](https://inigo.io/blog/you-dont-need-to-disable-introspection). Now, let's take a look at the different security knobs needed to guardrail a healthy GraphQL request.

## It’s All About DoS
GraphQL DoS (Denial of Service) attacks target GraphQL parsers, GraphQL resolvers, and the underlying DBs in a single API call. They include batching, nested, heavy and complex, N+1, and circular attacks which can bring your server down and affect server availability.

Fortunately, it is possible to protect your server from these attacks with the help of a set of guardrails and GraphQL usage-based rate-limiting.


![All the knobs - GraphQL Attack Surfaces.png](/uploads/All_the_knobs_Graph_QL_Attack_Surfaces_f67bc38145.png)

## How to Protect - Inbound
Below is a list of security knobs that any GraphQL adopter should implement. Ideally, these configurations are set together with per-role access control to limit attacks.

![All The knobs - GraphQL Security - Inbound.png](/uploads/All_The_knobs_Graph_QL_Security_Inbound_8f9a279d13.png)

#### Limit Directives
As one of our favorite security knobs, limit directives help to guard against parser overload attacks.
Overloading the parser with hundreds of directives can result in the server crashing without the request reaching the resolvers. (Credits: [@unixhopper](https://twitter.com/unixhopper))

![GraphQL Limit Directives for Parser Attack.png](/uploads/Graph_QL_Limit_Directives_for_Parser_Attack_e4ced2233a.png)

#### Limit Depth
Helps to guard against nested and N+1 attacks that overload resolvers and DB with complexity and loops.

![GraphQL Limit Depth for Nested Attack.png](/uploads/Graph_QL_Limit_Depth_for_Nested_Attack_797afe467d.png)

#### Limit Height
Helps to guard against alias attacks like overloading DB access for the same field or type.

![GraphQL Limit Height for Alias Attack.png](/uploads/Graph_QL_Limit_Height_for_Alias_Attack_e8e02c300f.png)

#### Limit Root Fields
Helps to guard against batch attacks like password guessing and OTA bypassing.

![GraphQL Limit Root Fields for Batch Attack.png](/uploads/Graph_QL_Limit_Root_Fields_for_Batch_Attack_995f0888e4.png)

#### Limit Request Size
Offers fallback protection for complex requests by limiting the size of the request.

#### Force Operation Name [Bonus]
Make sense of your analytics and telemetry. While the uniqueness of the name can’t be enforced, having a name makes it much easier to gain context of the call and differentiate it from other calls when reviewing API usage.

![Graph_QL Improve visibility and force name@2x.webp](/uploads/raph_QL_Improve_visibility_and_force_name_2x_64fb1739c6.webp)

## How to Protect - Outbound
#### Demand-based Rate Limiting (aka Usage-based)
We found that the most robust way to think about GraphQL Rate Limiting is to look at the server’s consumption and real usage. Counting each query’s returned objects against a timeframe limit (e.g. 1,000 credits per minute).

Credits can be configured in a few ways: 
- Statically Configured - All objects are counted as 1 credit.
- Manually Configured - Since not all fields are equal, some may take more time to retrieve than others  (e.g. computed fields). In this configuration, developers can manually assign different credit weights to different types and fields.
- Dynamically Configured - Credits are calculated based on the GraphQL tracing and server time to respond.

This approach works best with granular access control, where heavy-usage roles have a larger allowance as opposed to other roles or even unauthenticated calls.

#### Cost Analysis-based Rate Limiting (aka Predictive-based)
Alternatively, if you are using GraphQL-JS, there are a few libraries that might help to predict the complexity of a query:
- [GraphQL Validation Complexity](https://github.com/4Catalyzer/graphql-validation-complexity) (GraphQL-js only)
- [GraphQL Query Cost Analysis](https://github.com/pa-bru/graphql-cost-analysis) (GraphQL-js only)

#### Limit Response Size
If all else fails, limit the size of the response.

## What’s Next
Ready to defend against GraphQL server attacks? Inigo can help! [Schedule a demo now.](https://inigo.io/demo)

Inigo offers a platform-agnostic approach to remove barriers and open possibilities for any open-source or commercial GraphQL server.

Be sure to subscribe to our newsletter to get notified of our next posts, where we dive deeper into GraphQL-specific attacks.




All The Knobs - Security guardrails for GraphQL attack surfaces

Granular_Introspection_Access_Control.webp

large_Granular_Introspection_Access_Control.webp

medium_Granular_Introspection_Access_Control.webp

small_Granular_Introspection_Access_Control.webp

thumbnail_Granular_Introspection_Access_Control.webp

A closer look at how granular access control can help protect from weaknesses around Introspection, field suggestions, and field fuzzing.

As discussed in our last post, [How Secure is Your GraphQL Server?](https://inigo.io/blog/how-secure-is-your-graph-ql-server), inconsistencies in GraphQL implementations are common among the different GraphQL offerings.

Let’s take a closer look at how granular access control can help protect from weaknesses around schema fetching.

## Schema Fetching
Introspection, field suggestions, and field fuzzing play a significant role in equipping abusers with information on their target’s functionality by allowing insecure data mapping and sensitive information disclosure.

### Introspection
For many developers, the common practice is to disable Introspection – the first topic you come across when researching methods to secure your GraphQL. As a result, the discoverability nature of the feature will be lost. Those who choose to keep Introspection open are left with an “all-or-nothing” dilemma, exposing sections of the schema to users who don’t have access.

### Field Suggestions
The vast majority of GraphQL implementations don’t offer developers control for field suggestions, which allows abusers to quickly map the schema using field fuzzing even when Introspection is disabled. Supplying incorrect fields will trigger GraphQL to disclose fields with similar names.

![Granular Introspection Access Control Response.png](/uploads/Granular_Introspection_Access_Control_Response_e034ffb94b.png)

## How to Protect
If you are looking for an approach that can both limit the visibility of the schema and allow your users to explore it, consider role-based granular access control.

Inigo allows developers to configure edge-based access control, resulting in a different Introspection experience per role while still maintaining one schema. Based on their role, users will only be exposed to the types and fields they have access to. 

### Benefits
- Limited visibility
- Reduce users confusion
- Keep abusers in the dark

### Starwars GraphQL example:

![Granular Introspection Access Control.png](/uploads/Granular_Introspection_Access_Control_fef37268cd.png)

With Inigo’s granular Introspection access control, field suggestions are disabled while only approved fields are visible via Introspection per role – regardless of the specific GraphQL server implementation. As a result, multiple variations of Schema Fetching are prevented, allowing you to feel more confident in the security of your GraphQL server. 

![Field Suggestions With Granular Introspection Access Control](/uploads/Field_Suggestions_With_Granular_Introspection_Access_Control_2dd0ef5fea.png)

## What’s Next
Ready to defend against GraphQL server attacks? Inigo can help! [Schedule a demo now.](https://inigo.io/demo)

Inigo offers a platform-agnostic approach to remove barriers and open possibilities for any open-source or commercial GraphQL server.

Be sure to subscribe to our newsletter to get notified of our next posts, where we dive deeper into GraphQL-specific attacks.


No, you don’t need to disable Introspection

large_post_1_1.webp

medium_post_1_1.webp

small_post_1_1.webp

thumbnail_post_1_1.webp

post_1_1.webp

Like any new technology, security awareness is often lagging behind adoption. For this reason, GraphQL attack surfaces are bound to unfold for many of its users.

Like any new technology, security awareness is often lagging behind adoption. For this reason, GraphQL attack surfaces are bound to unfold for many of its users. These attacks range from Parser Attacks and Resolver Attacks to Data Manipulation and even Data Leaks. 

GraphQL attack surfaces are quite unique. An attacker can target one or more surfaces with one API call that would easily pass through any standard API gateway. Here we’ll discuss the implications of an unsecured GraphQL server and who could be at risk, so keep reading to learn more. 

## GraphQL Security Awareness

To get a better understanding of GraphQL security awareness amongst users, we decided to conduct a short survey. Our Reddit GraphQL survey titled ”How Do You Think About GraphQL Security?” had an interesting but not surprising spread of replies.

![GraphQL Security Awareness Survey.png](/uploads/Graph_QL_Security_Awareness_Survey_b8876fbf4d.png)

During one-on-one interviews, participants who were already aware of GraphQL’s attack surfaces reported that this knowledge came from a negative experience: their own servers had been compromised. 

## Who is Impacted

Most of us.

While GraphQL builds are [available](https://graphql.org/code/) in any programming language you could ask for, they are not all built the same nor do they have the same supportive community size or security awareness. Just this week, a circular-fragment attack was demonstrated to crash [Aago](https://github.com/ohler55/agoo)’s Ruby-Server implementation on GitHub and was reported as [CVE](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-30288). 

[Nick Aleks](https://twitter.com/Nick_Aleks) and [Dolev Farhi](https://twitter.com/dftrace) did a fantastic job detecting and documenting vulnerabilities across multiple GraphQL:

![GraphQL servers implementation.png](/uploads/Graph_QL_servers_implementation_859d62f5d0.png)

(Source: [GitHub](https://github.com/nicholasaleks/graphql-threat-matrix))

Large resource-heavy engineering teams usually end up developing in-house tooling and building blocks to customize and tighten their GraphQL deployments. This approach is not always easy to maintain and is often prone to errors. [HackerOne](https://hackerone.com/hacktivity?querystring=graphql) is another excellent source that further explains how GraphQL attacks impacted different companies. 

So, how secure is your GraphQL server? Unfortunately, it’s not so much a question of if a GraphQL attack will happen to you, but when.

## What’s Next

Ready to defend against GraphQL server attacks? Inigo can help! [Schedule a demo now.](https://inigo.io/demo)

Inigo offers a platform-agnostic approach to remove barriers and open possibilities for any open-source or commercial GraphQL server.

Be sure to subscribe to our newsletter to get notified of our next posts, where we dive deeper into GraphQL-specific attacks.

Inigo Blog