Skip to content

Latest commit

 

History

History
58 lines (47 loc) · 6.08 KB

attack-surface.md

File metadata and controls

58 lines (47 loc) · 6.08 KB

Attack Surface Analysis for 99designs/gqlgen

Attack Surface: Deeply Nested Queries (Denial of Service)

  • Description: Attackers can craft queries with excessive nesting, consuming server resources (CPU, memory, database connections).
    • gqlgen Contribution: gqlgen doesn't inherently limit query depth, allowing arbitrarily deep queries. This is a direct contribution.
    • Example: query { users { posts { comments { author { friends { ... } } } } } } (repeated many times).
    • Impact: Server crash or unresponsiveness, denial of service for legitimate users.
    • Risk Severity: High
    • Mitigation Strategies:
      • Implement Maximum Query Depth: Use gqlgen's RequestMiddleware to analyze the query AST and reject queries exceeding a predefined depth limit (e.g., 10 levels). This is the primary mitigation.
      • Monitor Resource Usage: Track CPU, memory, and database connection usage. Set alerts for anomalies.

Attack Surface: List Multiplier Attacks (Denial of Service)

  • Description: Exploiting fields that return lists within other lists to cause exponential resource consumption.
    • gqlgen Contribution: gqlgen allows fields to return lists without inherent limits on the number of items returned per request. This lack of built-in limits is a direct contribution.
    • Example: query { users { posts { comments } } } where each user has many posts, and each post has many comments.
    • Impact: Server overload, denial of service.
    • Risk Severity: High
    • Mitigation Strategies:
      • Pagination: Implement pagination (e.g., Relay-style connections) on all list fields to limit the number of items returned per request. This is crucial and directly addresses gqlgen's lack of built-in list limits.
      • Cost Analysis (see below): Use cost analysis to account for the potential size of lists.

Attack Surface: Excessive Query Cost (Denial of Service)

  • Description: Queries that, while not deeply nested, are computationally expensive due to the combination of fields selected.
    • gqlgen Contribution: gqlgen doesn't inherently limit the overall "cost" of a query, relying entirely on the developer to implement cost controls. This is a direct contribution.
    • Example: query { allProducts { name, description, price, reviews(limit: 1000) { content, author { ... } } } } (where allProducts and reviews are expensive to resolve).
    • Impact: Server slowdown or unresponsiveness, denial of service.
    • Risk Severity: High
    • Mitigation Strategies:
      • Implement Query Cost Analysis: Use gqlgen's extension points (specifically RequestMiddleware) to calculate a cost for each field and reject queries exceeding a total cost limit. Consider both static and dynamic cost analysis. This is the primary mitigation and directly addresses gqlgen's lack of built-in cost limiting.
      • Rate Limiting: Implement rate limiting per user or IP address to prevent abuse (this is a general mitigation, but helpful here).

Attack Surface: Resolver Authorization Bypass (Data Breach/Unauthorized Actions)

  • Description: Failure to properly check user permissions within resolvers, leading to unauthorized data access or modification.
    • gqlgen Contribution: While authorization itself isn't gqlgen's responsibility, the structure of GraphQL and gqlgen's resolver-based architecture makes this a critical area to focus on. The decentralized nature of resolvers (compared to, say, a traditional REST API with centralized controllers) increases the risk of overlooking authorization checks. This is an indirect but significant contribution.
    • Example: A resolver for user(id: ID!): User doesn't check if the requesting user has permission to view the requested user's data.
    • Impact: Data breaches, unauthorized data modification, privilege escalation.
    • Risk Severity: Critical
    • Mitigation Strategies:
      • Consistent Authorization: Implement a robust and consistent authorization framework within every resolver that accesses sensitive data or performs actions. Do not rely solely on client-side checks. This is absolutely critical in a GraphQL context.
      • Principle of Least Privilege: Ensure resolvers only have access to the data and resources they absolutely need.

Attack Surface: Input Validation Failures (Various - leading to Critical issues)

  • Description: Insufficient validation of input arguments to resolvers. While basic type checking is done, complex validation is left to the developer.
    • gqlgen Contribution: gqlgen performs basic type checking based on the schema (e.g., Int, String) but doesn't handle complex validation or sanitization, leaving a significant gap. This is a direct contribution.
    • Example: A resolver accepts a String argument for a database ID without validating it's a UUID, potentially leading to unexpected behavior or vulnerabilities if the ID format is crucial for security.
    • Impact: Varies; can lead to data corruption, injection vulnerabilities, or other security issues, potentially escalating to critical severity.
    • Risk Severity: High (Potentially Critical)
    • Mitigation Strategies:
      • Robust Input Validation: Validate all input arguments to resolvers. Sanitize data before use.
      • Custom Scalars: Define custom scalar types (e.g., UUID, Email) for stricter validation. This leverages gqlgen's features to improve input safety.
      • Parameterized Queries: Use parameterized queries or ORM features to prevent injection.