Input is missing '@cost' directive or equivalent

Issue ID: graphql-cost-input-directive-needed

Average severity: Medium

Description

The schema used in an input position (arguments or input object fields) does not define a @cost directive or an equivalent cost annotation used by your framework.

The purpose of the cost directive is to assign a numeric weight for GraphQL types, fields, and arguments. This enables calculating the overall cost of executing a particular GraphQL transaction before it runs, and it allows tools and middleware to enforce threat protection and rate limiting consistently.

Some GraphQL frameworks implement cost analysis through schema directives other than @cost (for example, @complexity, @rateLimit). Despite the different directive names, the principle applies equally: any input construct that materially affects execution cost should carry the appropriate cost annotation for your framework.

For more details, see the IBM cost directive specification, or documentation for the equivalent implementation for your framework.

Possible exploit scenario

Without cost metadata on schema elements, expensive resolvers — such as aggregations, remote service calls, or database joins — appear identical in cost to trivial field lookups, making cost-based controls ineffective.

In practice, different input values can materially change the workload on your system:

  • Filters can trigger more expensive database query plans
  • "Include details" flags can add joins or data expansions
  • Sort parameters can increase CPU usage
  • Nested input objects can cause additional resolver work

If inputs are not annotated with cost metadata, your cost analysis will systematically underestimate worst-case execution cost. Attackers could craft requests that appear cheap under static analysis but use costly input combinations, such as complex filters, broad selection modes, or expensive sort orders. Without a cost directive on those inputs, cost-based middleware or rate limiting will allow requests that are disproportionately expensive to execute, enabling resource exhaustion or Denial of Service (DOS, DDOS) patterns.

Remediation

Add @cost(weight: "...") or an equivalent constraint in your framework to all input-related constructs that materially affect execution cost, particularly argument definitions and input field definitions.

Security Audit accepts the cost directive on operation root types (Query, Mutation, Subscription). If the cost directive is present at the operation type level, API Scan considers the cost requirement satisfied for all fields, arguments, and input fields within that operation, meaning that you do not need to annotate each one individually. This makes cost annotation significantly more practical for SDL authors who want to assign a baseline cost to a whole operation without annotating every argument or input field.