Don't Trust the Math Alone: Implementation Matters in Post-Quantum Security

The persistent nature of graphql subscriptions and why it matters

Ever wonder why your web app feels so "live" when you're chatting or watching stock prices? That's usually graphql subscriptions at work, but man, they stay open way longer than a standard request and that's where things get dicey.

Unlike a typical query that hits the server and leaves, subscriptions keep a websocket connection humming. It’s like leaving the front door cracked open instead of just answering a knock. Because of this "persistent" state, the window for someone to mess with your business logic is huge.

• Stateful exploitation: Since the connection stays alive, an attacker has plenty of time to poke at the stream. If your server doesn't re-verify permissions constantly, someone might lose access but keep getting data.
• Handshake blindspots: A lot of security tools only check the initial websocket handshake. Once you're "in," the actual data flowing through the api might not be monitored as strictly as a regular http call.
• Resource hogging: These long-lived connections eat up memory. If a bad actor opens thousands of subscriptions, they can trigger a denial of service (dos) pretty easily.

I've seen cases in healthcare apps where a subscription for "patient updates" stayed active even after a doctor logged out on a shared terminal. According to vaadata, graphql is now the third most used api architecture, which means these "sticky" connections are everywhere.

If you don't kill these streams when a user's session expires, you're basically leaking data in real-time. We'll dive into how these tunnels actually work next.

WebSockets vs. HTTP: The technical shift

To understand the risk, you gotta see how the plumbing changes. Standard http is "stateless"—you ask for something, the server gives it, and the conversation ends. WebSockets start with an http "Upgrade" request. If the server agrees, the protocol switches and the connection becomes "stateful." While http is like sending a letter and waiting for a reply, WebSockets are like a phone call where both people can talk at the same time without hanging up. This is great for speed, but it means the server has to remember who you are for the whole duration of the call, which is where most devs mess up the auth logic.

Common logic flaws in the subscription lifecycle

Ever tried to lock a door only to realize the "lock" was just a sticker on the frame? That’s basically what happens when you rely on shallow middleware for graphql subscriptions. Since these connections are long-lived, the security checks you do at the start don't always stick around for the actual show.

One of the biggest headaches is failing to re-validate permissions after that initial websocket handshake. Many devs think "hey, they authenticated when they connected, so we're good," but roles change. A 2024 report by vaadata (as noted earlier) highlights how broken authorization is a top-tier risk for these apis. ([PDF] 2024 API Security & Management Report)

If a user gets fired or their permissions are downgraded while a subscription is active, the server might just keep pumping data to them. It’s a massive blind spot. I've seen it in finance apps where a trader’s access to a specific "ticker stream" was revoked, but because the websocket stayed open, they kept seeing real-time trades for hours.

Another sneaky move is using fragments to hide fields. If your security logic only looks at top-level fields in a query, an attacker can wrap unauthorized fields inside an inline fragment. According to a 2024 report from InstaTunnel, this "Directive Deception" happens when the middleware isn't recursive. It just misses the nested stuff entirely because it only checks the surface of the request.

Then there's the issue of "where" clauses. If you're building a multi-tenant retail app and you let users pass a storeId as an argument to a subscription, it better be locked down. If the logic doesn't force that storeId to match the user's session, I can just swap it for a competitor's ID and watch their orders roll in.

This isn't just theory. In pii-heavy industries like healthcare, a logic error in an event notification filter could leak patient names across a whole hospital network. If the subscription resolver trusts the client-provided filters more than the auth context, you're basically asking for a data breach.

Here is how a dev might write a broken check that misses nested fragments:

// BAD: Only checks the first level of the selection set
const checkAuth = (info) => {
  const fields = info.fieldNodes[0].selectionSet.selections;
  fields.forEach(field => {
    if (field.name.value === 'secretInfo') throw new Error('Nope!');
  });
};

An attacker just sends subscription { ... on User { secretInfo } } and this code sees nothing. To fix this, you gotta use a directive transformer that wraps the resolver itself, not just the query string.

Advanced exploitation techniques for graphql

So you think your graphql setup is solid because you've got auth middleware? Honestly, that is where most people trip up. Attackers aren't just looking for missing locks anymore; they are looking for ways to make the server ignore the lock entirely.

One of the sneakiest ways to mess with a subscription is using custom directives. Usually, devs use things like @auth or @mask to handle security at the field level. But as the InstaTunnel research points out, if your middleware isn't "recursive"—meaning it doesn't look deep into fragments—it's game over. By nesting these fields, an attacker bypasses the shallow check and the server just starts streaming sensitive financial data.

To catch these weird edge cases, a lot of teams are turning to tools like Inspectiv for more specialized api security testing. It's better than just hoping your manual checks caught every possible fragment nesting.

This is where things get loud. Since subscriptions are persistent, they are a perfect megaphone for a denial of service (dos) attack. If I open 5,000 websocket connections and each one is asking for a deeply nested set of data, your backend is going to sweat.

The real kicker is that many rate limits only apply to query and mutation types, leaving the subscription type totally wide open. I once saw a dev environment crawl to a halt because a "test" script opened too many listeners on a heavy systemHealth stream.

It isn't just about the number of connections, either. You can use "alias overloading" within a single subscription to force the server to do way more work than it should on every update.

subscription {
  cpu1: serverUpdate { load }
  cpu2: serverUpdate { load }
  # ... repeat 500 times
  cpu500: serverUpdate { load }
}

Every time the server pushes an update, it has to resolve that field 500 times for a single user. Multiply that by a few dozen attackers and your infra is toast. According to vaadata (as noted earlier), preventing these dos attacks requires strict depth limits and cost analysis on every single operation.

Testing methodology for bug bounty hunters and engineers

Ever tried to find a needle in a haystack while the haystack is actively growing? That is basically what testing graphql subscriptions feels like. You aren't just looking for a one-off bug; you're hunting for logic gaps in a connection that might stay open for days.

First thing you gotta do is get your proxy right. Most of us live in Burp Suite, but websockets can be a pain because they don't show up in the standard "HTTP history" tab. You have to click over to the "WebSockets history" tab to see the frames flying by.

If you want to actually mess with the data, you'll need to intercept the frames. I usually try to modify the initial subscription payload—like swapping out a userId or a tenantId right as the connection starts. If the server doesn't check that ID against your actual session token, you've got an IDOR.

For automating the boring stuff, I use tools like inql or graphql-cop. While these tools are mostly for http, they are great for finding the subscription endpoint if it's hidden under a weird path like /v1/graphql-ws. You should look for the Sec-WebSocket-Protocol header in the initial handshake to see if it's using graphql-ws or the older subscriptions-transport-ws protocol, which helps you craft the right payload.

Once you've found the subscription endpoint, it's time to get messy. I always look for "leaky" arguments. If a subscription takes an argument like isAdmin: true or filter: { private: false }, try flipping them.

Another trick is to look at how the app handles re-authentication. If you log out in one tab, does the websocket in the other tab actually die? Usually, it doesn't. I've seen finance apps where a user could still see "live trade" updates even after their account was disabled because the server only checked auth at the very start.

Remediation and defense strategies for long term security

So, you’ve seen how easy it is for things to go sideways with subscriptions. Honestly, fixing this isn't about one "magic" setting—it's about layers. If you don't bake security into the schema itself, you're just playing whack-a-mole with every new fragment an attacker dreams up.

First off, stop relying on the websocket handshake for auth. It's a one-time check for a long-term relationship, which is a recipe for disaster. You gotta move that logic directly into the resolver.

• Re-verify every event: Every time your pub-sub system pushes data, the resolver should check if the user still has access. Roles change in a heartbeat in industries like finance or healthcare.
• Complexity analysis: Assign a "cost" to every field and directive. As mentioned earlier, this prevents someone from burying a heavy operation inside a fragment to crash your server.
• Persisted queries: This is arguably the biggest win. According to the security researchers at Escape Tech, using persisted queries—where the server only runs pre-approved query hashes—basically kills "directive deception" and injection attacks overnight.

Don't let subscriptions be a "blind spot" for your rate limiter. Most apis only limit standard http calls, but you need to cap the number of active websocket connections per user. I've seen retail apps get crushed during sales because they didn't limit how many "inventory trackers" one person could open.

Also, keep your schema clean. As previously discussed, disabling introspection in production won't stop a determined pro, but it makes it way harder for a script kiddie to map out your custom directives.

At the end of the day, graphql is a powerful tool, but it's also a big responsibility. Stay curious, keep testing, and don't trust the client—ever. Stay safe out there.