Platform

Platform overview How it works Authorization testing Evidence & reports Private scanning Integrations

Solutions

Security agencies Product teams Regulated industries Partner programme

Learn

Blog Knowledge hub Compare

Resources

Pricing Documentation Help centre FAQ Security & data What we haven’t proved

Company

About Contact Careers Sign in to the platform Start a $199 pilot →

Home / Knowledge hub / Confused deputy

Knowledge hub

Confused deputy

A trusted service tricked into using its own power for someone who lacks it.

Illustration explaining Confused deputy

What it means

A confused deputy is a program with legitimate authority that is tricked into using it on behalf of someone who has none. The deputy is not broken in the usual sense. It does exactly what it was built to do, for the wrong person.

The idea dates from the 1980s, but it describes everyday web bugs. A server that fetches any address you give it uses the server's network position, not yours. A back-end that trusts a caller's claim about who it is acting for lends its own power.

Why it matters

Deputies tend to be powerful: they sit inside your network, hold database credentials or cloud roles, and talk to other services. When one is confused, a person with no access gets the benefit of its access, and the request in your logs shows the trusted service, not the person.

This is how an outsider reaches an internal system, or a customer reaches another customer's data via a shared back-end. MITRE tracks it as a weakness, CWE-441, because the pattern recurs in server-side requests, cloud permissions and API gateways, wherever one component holds more authority than the caller.

How it shows up

Common forms include server-side request forgery, where your server fetches a URL chosen by the user; internal services that accept a user ID from the caller without checking; cloud roles that a third party can use because nothing ties the request to the right customer; and CSRF, where the browser is the deputy.

What to check: does each service verify who the request is really for, rather than only who sent it? Are cross-account cloud roles tied to an identifier the caller cannot choose? Does the back-end re-check authorisation instead of trusting the front-end? Limit what the deputy can do at all.

Questions people ask

Confused deputy, answered

Is a confused deputy the same as privilege escalation?

It is one route to it. In ordinary privilege escalation the attacker raises their own rights. Here they borrow someone else's, and nothing about their own account changes.

The fix is therefore different: check the request, not the account.

Is SSRF a confused deputy problem?

Yes, a clear example. The attacker cannot reach the internal system, but your server can, and it makes the request on their behalf.

Allowlists for outbound destinations and network rules reduce what the deputy can reach.

Is CSRF a confused deputy?

It is commonly described that way. The browser holds the user's cookies and sends them with a request the attacker triggered, so the site acts on the user's authority.

CSRF tokens and SameSite cookies stop the browser being used like that.

How do we reduce the risk?

Give every service the least power it needs, pass the identity of the original caller along, and check it at each step. Never accept a caller's claim about who they act for without verification.

Where a cross-account role is unavoidable, tie it to a value only the real customer knows.

Can scanners find a confused deputy?

Some forms, like SSRF, yes. Others depend on your design, such as which service trusts which, and need someone to follow the trust through.

A tester who understands the architecture finds more of them.

Cyberlop mark

Who is the deputy really acting for?

We follow requests through your app and its APIs to see whether a service uses its own power for the wrong caller. Findings carry the exact request, and the line of code in white-box mode. Ask us to run it on one of your applications.

Or start with a $199 pilot on one application: thirty days, success criteria agreed before day one, credited against the annual if you convert.