Why GraphQL Subscriptions Are a Bug Bounty Gold Mine

GraphQL subscriptions let clients receive real-time updates over a persistent connection. When a user places an order, when a message arrives, when a price changes — subscriptions push that data to the client instantly. The problem: most developers treat subscriptions as a convenience feature and skip the authorization checks they'd never forget on a query or mutation.

This guide covers the practical techniques for finding and exploiting GraphQL subscription vulnerabilities in bug bounty targets. Every technique here has been validated against real-world applications.

How GraphQL Subscriptions Work (Attack-Relevant Details)

Before you test, you need to understand the subscription lifecycle — each phase is an attack surface:

1. Connection initialization — The client opens a WebSocket and sends a connection_init message, optionally with auth credentials. The server responds with connection_ack. If the server doesn't validate credentials here, every subsequent subscription runs unauthenticated.
2. Subscription registration — The client sends a subscribe message with a GraphQL subscription query. The server registers the subscription and starts pushing matching events. If the server doesn't check authorization per-subscription, any authenticated user can subscribe to any event stream.
3. Event delivery — The server pushes next messages as events occur. If field-level authorization isn't enforced on subscription payloads, sensitive fields leak to unauthorized subscribers.
4. Connection termination — The client sends complete or closes the WebSocket. If the server doesn't clean up subscriptions on disconnect, orphaned subscriptions consume resources indefinitely.

Two Protocols, Two Attack Surfaces

There are two competing WebSocket sub-protocols for GraphQL:

• subscriptions-transport-ws (legacy) — Uses connection_init, start, stop, connection_terminate. Auth token goes in connectionParams during init. Many implementations never re-validate the token after connection.
• graphql-ws (modern) — Uses connection_init, subscribe, complete. Stricter protocol but still relies on the server to enforce auth. The Sec-WebSocket-Protocol header tells you which one the target uses.

Reconnaissance: Finding Subscription Endpoints

Step 1: Schema Introspection

Run a standard introspection query against the GraphQL endpoint. Look for the subscriptionType field in the schema:

{
  __schema {
    subscriptionType {
      name
      fields {
        name
        args { name type { name } }
        type { name kind ofType { name } }
      }
    }
  }
}

If introspection is disabled, try these bypasses:

• Send the introspection query as a GET request with the query in the URL parameter
• Use field suggestion errors — send a subscription with a misspelled field and the error message often leaks valid field names
• Check for GraphQL Playground or GraphiQL endpoints at /graphql/playground, /graphiql, /altair — these often have introspection enabled even when the main endpoint doesn't

Step 2: Identify the WebSocket Endpoint

Common subscription endpoint patterns:

• wss://api.target.com/graphql (same as query endpoint, upgraded)
• wss://api.target.com/subscriptions
• wss://ws.target.com/graphql
• wss://realtime.target.com/

Check the browser's Network tab → WS filter while using the application's real-time features. The WebSocket URL and the Sec-WebSocket-Protocol header tell you everything you need.

Attack 1: Unauthorized Subscription Access (IDOR via Subscriptions)

The most common and highest-impact finding. The server checks authorization on queries and mutations but not on subscriptions.

Testing Methodology

1. Authenticate as User A. Open a WebSocket and subscribe to User A's events (e.g., subscription { orderUpdated(userId: "A") { id status amount } }).
2. Confirm you receive events for User A.
3. Now subscribe to User B's events: subscription { orderUpdated(userId: "B") { id status amount } }.
4. If you receive User B's events, you have an authorization bypass — report it.

Practical Example with websocat

# Connect with User A's token
websocat -H "Sec-WebSocket-Protocol: graphql-ws" \
  wss://api.target.com/graphql

# Send connection_init with auth
{"type":"connection_init","payload":{"Authorization":"Bearer USER_A_TOKEN"}}

# Subscribe to User B's events
{"id":"1","type":"subscribe","payload":{"query":"subscription { orderUpdated(userId: \"USER_B_ID\") { id status amount shippingAddress } }"}}

Variations to test:

• Subscribe with no userId filter — does the server send ALL users' events?
• Subscribe with a wildcard or empty string as the filter argument
• Omit the auth token entirely in connection_init — does the subscription still work?

Attack 2: Connection-Level Authentication Bypass

Many GraphQL subscription implementations only check the auth token during connection_init and never re-validate it. This creates two exploitable scenarios:

Scenario A: Token Expiry Bypass

1. Connect with a valid token.
2. Wait for the token to expire (or use a token that expires in 1 minute).
3. Register new subscriptions after expiry.
4. If the server accepts them, the connection outlives the token — report it.

Scenario B: Revoked Token Persistence

1. Connect with a valid token.
2. In another session, revoke the token (logout, password change, admin revocation).
3. Check if the existing WebSocket connection still delivers subscription events.
4. If it does, revocation doesn't propagate to active connections — report it.

Attack 3: Subscription Flooding (Denial of Service)

Each active subscription consumes server memory and CPU. Most implementations don't limit the number of subscriptions per connection or per user.

Testing Methodology

# Python script to test subscription limits
import asyncio, websockets, json

async def flood():
    uri = "wss://api.target.com/graphql"
    async with websockets.connect(uri, subprotocols=["graphql-ws"]) as ws:
        await ws.send(json.dumps({
            "type": "connection_init",
            "payload": {"Authorization": "Bearer TOKEN"}
        }))
        await ws.recv()  # connection_ack

        for i in range(1000):
            await ws.send(json.dumps({
                "id": str(i),
                "type": "subscribe",
                "payload": {"query": "subscription { priceUpdated { symbol price } }"}
            }))

        # Monitor server response time degradation
        while True:
            msg = await ws.recv()
            print(msg)

asyncio.run(flood())

Important: Start with small numbers (10, 50, 100) and monitor impact. Do NOT launch thousands of subscriptions against a production target without confirming the program allows DoS testing. Many programs explicitly exclude DoS — check the policy first.

What to Report

• No per-user subscription limit → resource exhaustion risk
• No per-connection subscription limit → single connection can consume unbounded memory
• No rate limiting on subscribe messages → rapid subscription creation

Attack 4: Subscription Payload Data Leakage

Even when subscription access is authorized, the payload may include fields the subscriber shouldn't see.

Testing Methodology

1. Subscribe to an event you're authorized to receive.
2. Request fields that should be restricted — admin fields, internal IDs, PII of other users, pricing data, etc.
3. Compare the subscription payload to what the equivalent query returns. If the subscription returns more fields, the authorization layer is inconsistent.

# Subscribe requesting sensitive fields
{"id":"1","type":"subscribe","payload":{"query":"subscription { orderUpdated { id status amount internalNotes adminComments customerEmail customerPhone }"}}

This works because many implementations use a different resolver chain for subscriptions than for queries. The query resolver checks field-level permissions; the subscription resolver just serializes the entire event object.

Attack 5: Subscription Injection

If subscription arguments are interpolated into backend event filters without sanitization, you can inject filter logic:

• NoSQL injection in subscription filters — If the backend uses MongoDB to match events: subscription { events(filter: "{\"$gt\": \"\"}") { data } }
• Regex injection — If the filter uses regex matching: subscription { logs(pattern: ".*") { message } } to match all events
• Subscription query manipulation — Some implementations let you pass fragments or directives that alter the subscription behavior: subscription { events @include(if: true) { sensitiveField } }

Tools for GraphQL Subscription Testing

Reporting GraphQL Subscription Vulnerabilities

Severity Guidelines

• Critical: Cross-tenant data access via subscriptions (IDOR), unauthenticated subscription access to sensitive data
• High: Authorization bypass on subscription registration, token expiry/revocation bypass on persistent connections
• Medium: Subscription flooding without rate limits (if DoS is in scope), field-level data leakage in subscription payloads
• Low: Missing subscription cleanup on disconnect, subscription count information disclosure

Report Template

## Title
Unauthorized Cross-Tenant Data Access via GraphQL Subscriptions

## Severity
Critical

## Description
The GraphQL subscription endpoint at wss://api.target.com/graphql
does not enforce per-user authorization on subscription registration.
An authenticated user can subscribe to events belonging to any other
user by specifying their userId in the subscription query.

## Steps to Reproduce
1. Authenticate as User A (attacker)
2. Open WebSocket to wss://api.target.com/graphql
3. Send connection_init with User A's bearer token
4. Send subscribe message with User B's userId
5. Trigger an event for User B (e.g., place an order)
6. Observe User B's event data delivered to User A's subscription

## Impact
Any authenticated user can monitor real-time events for any other
user, including order details, messages, and account changes.

Defensive Patterns (Know What You're Bypassing)

Understanding the defenses helps you find where they're missing:

• Per-subscription authorization — The server checks if the authenticated user is allowed to subscribe to the requested resource. Test by subscribing to resources owned by other users.
• Connection-level token refresh — The server periodically re-validates the auth token on active connections. Test by revoking your token and checking if the connection persists.
• Subscription rate limiting — The server limits subscriptions per user/connection. Test by rapidly creating subscriptions and checking for 429-equivalent responses.
• Payload filtering — The server applies field-level authorization to subscription payloads. Test by requesting restricted fields in your subscription query.

Related Guides

• WebSocket Security Testing for Bug Bounty in 2026 — Covers the transport layer that GraphQL subscriptions run on
• API Authentication Testing for Bug Bounty in 2026 — Token handling and session management patterns
• Prototype Pollution for Bug Bounty in 2026 — JavaScript-specific attacks relevant to Node.js GraphQL servers