GraphQL Security in Code Review: Authorization and Query Complexity

GraphQL's flexibility comes with unique security challenges that traditional REST API security doesn't cover. Authorization bypasses through query manipulation, resource exhaustion via deep nesting, and N+1 query performance attacks are just the beginning. This comprehensive guide covers the security patterns every code reviewer needs to understand when reviewing GraphQL implementations.

GraphQL Security Model Fundamentals

Unlike REST APIs where you secure endpoints, GraphQL requires a more nuanced approach. Every field in your schema is a potential data access point, and the query language allows clients to craft complex requests that can bypass traditional security measures.

The Authorization Challenge

Authorization Patterns and Anti-Patterns

Authorization in GraphQL requires careful consideration of how data relationships work. A user might have access to a resource directly but not through certain graph traversal paths.

Field-Level Authorization

// VULNERABLE - No field-level authorization
const resolvers = {
  Query: {
    user: async (parent, { id }, { user }) => {
      if (!user) throw new Error('Unauthorized');
      return getUserById(id); // Any authenticated user can access any user
    }
  },
  User: {
    email: (parent) => parent.email, // Exposed to all authenticated users
    socialSecurityNumber: (parent) => parent.ssn // CRITICAL: No authorization check
  }
};

// SECURE - Proper field-level authorization
const resolvers = {
  Query: {
    user: async (parent, { id }, { user }) => {
      if (!user) throw new Error('Unauthorized');
      if (user.id !== id && !user.isAdmin) {
        throw new Error('Forbidden');
      }
      return getUserById(id);
    }
  },
  User: {
    email: (parent, args, { user }) => {
      if (user.id !== parent.id && !user.isAdmin) {
        return null; // Hide field instead of throwing error
      }
      return parent.email;
    },
    socialSecurityNumber: (parent, args, { user }) => {
      if (!user.isAdmin) {
        return null; // Only admins can access PII
      }
      return parent.ssn;
    }
  }
};

Authorization Directive Pattern

Using GraphQL directives for authorization provides a cleaner, more maintainable approach to securing your schema.

# Schema with authorization directives
type User {
  id: ID!
  username: String!
  email: String! @auth(requires: USER) @owner
  role: String! @auth(requires: ADMIN)
  socialSecurityNumber: String @auth(requires: ADMIN)
  posts: [Post!]! @auth(requires: USER)
}

type Post {
  id: ID!
  title: String!
  content: String! @auth(requires: USER) @owner
  author: User!
}

directive @auth(
  requires: Role = USER
) on OBJECT | FIELD_DEFINITION

directive @owner on FIELD_DEFINITION

enum Role {
  USER
  ADMIN
}

Query Complexity and Resource Protection

GraphQL's nested query capability can be exploited to create resource exhaustion attacks. Implementing proper query analysis prevents these attacks while maintaining API flexibility.

Depth Limiting

query DeepQuery {
  user(id: "1") {
    posts {
      author {
        posts {
          author {
            posts {
              author {
                # This could go 50+ levels deep
                # causing exponential resource usage
                posts {
                  title
                }
              }
            }
          }
        }
      }
    }
  }
}

import { depthLimit } from 'graphql-depth-limit';
import { createComplexityLimitRule } from 'graphql-query-complexity';

const server = new ApolloServer({
  typeDefs,
  resolvers,
  validationRules: [
    depthLimit(7), // Maximum query depth
    createComplexityLimitRule(1000, {
      maximumComplexity: 1000,
      variables: {},
      introspection: false,
      scalarCost: 1,
      objectCost: 1,
      listFactor: 10,
      createError: (max, actual) => {
        return new Error(
          `Query complexity ${actual} exceeds maximum allowed complexity ${max}`
        );
      }
    })
  ]
});

Query Cost Analysis

N+1 Query Problem Detection

The N+1 query problem is particularly dangerous in GraphQL because nested queries can trigger exponential database calls. Code reviewers must understand dataloader patterns and resolver efficiency.

Identifying N+1 Patterns in Code Review

// PROBLEMATIC - Causes N+1 queries
const resolvers = {
  Query: {
    posts: () => getAllPosts() // Returns 100 posts
  },
  Post: {
    author: (post) => getUserById(post.authorId), // Called 100 times!
    comments: (post) => getCommentsByPostId(post.id), // Called 100 times!
    tags: (post) => getTagsByPostId(post.id) // Called 100 times!
  }
};

// This query would trigger 1 + 100 + 100 + 100 = 301 database queries
// query {
//   posts {
//     title
//     author { name }
//     comments { content }
//     tags { name }
//   }
// }

import DataLoader from 'dataloader';

// EFFICIENT - Uses batching and caching
const createLoaders = () => ({
  userLoader: new DataLoader(async (userIds) => {
    const users = await getUsersByIds(userIds);
    return userIds.map(id => users.find(user => user.id === id));
  }),
  
  commentLoader: new DataLoader(async (postIds) => {
    const comments = await getCommentsByPostIds(postIds);
    return postIds.map(id => comments.filter(comment => comment.postId === id));
  }),
  
  tagLoader: new DataLoader(async (postIds) => {
    const tags = await getTagsByPostIds(postIds);
    return postIds.map(id => tags.filter(tag => tag.postId === id));
  })
});

const resolvers = {
  Query: {
    posts: () => getAllPosts()
  },
  Post: {
    author: (post, args, { loaders }) => loaders.userLoader.load(post.authorId),
    comments: (post, args, { loaders }) => loaders.commentLoader.load(post.id),
    tags: (post, args, { loaders }) => loaders.tagLoader.load(post.id)
  }
};

// Now the same query triggers only 4 database queries total!

Performance Monitoring Patterns

Information Disclosure Prevention

GraphQL's introspection feature and verbose error messages can leak sensitive information about your system architecture and data structure.

Introspection Security

query IntrospectionQuery {
  __schema {
    types {
      name
      fields {
        name
        type {
          name
        }
      }
    }
  }
}

const server = new ApolloServer({
  typeDefs,
  resolvers,
  introspection: false,
  playground: false,
  formatError: (error) => {
    console.error(error);
    return new Error('Internal server error');
  }
});

Error Handling Security

// Secure error handling with different environments
const formatError = (error) => {
  // Log full error details for debugging
  console.error('GraphQL Error:', {
    message: error.message,
    locations: error.locations,
    path: error.path,
    stack: error.stack
  });

  // Return sanitized error based on environment
  if (process.env.NODE_ENV === 'production') {
    // Generic error message in production
    if (error.message.includes('unauthorized')) {
      return new Error('Authentication required');
    }
    if (error.message.includes('forbidden')) {
      return new Error('Access denied');
    }
    return new Error('Something went wrong');
  }
  
  // Detailed errors in development
  return error;
};

Automated GraphQL Security Testing

Manual code review catches many issues, but automated testing is essential for comprehensive GraphQL security coverage.

Security Testing Tools

GraphQL Security Review Checklist

Advanced Security Patterns

Beyond basic security measures, advanced GraphQL applications require sophisticated patterns to handle complex authorization scenarios and performance optimizations.

Query Whitelisting

const server = new ApolloServer({
  typeDefs,
  resolvers,
  validationRules: [
    require('graphql-query-whitelist')({
      whitelist: allowedQueries,
      throwError: true
    })
  ]
});

Resource-Based Authorization

🔐 GraphQL security requires a schema-first, defense-in-depth approach.