Penjester beta

Features

What it does

Penjester is a Burp Suite extension for access-control testing. You browse an application signed in as each of your accounts. It replays what you did as the other accounts and checks whether anyone got back data that was not theirs. Everything runs inside Burp and stays on your machine.

How it works

Four steps

1 · Watch

Record who did what

Browse the application as each account. Penjester records every request and tags it with the account that sent it, including when two accounts use cookies with different names.

2 · Replay

Send it as the others

Each recorded request is sent again as your other accounts, with the full credential set swapped: cookies, auth headers and body tokens. The anti-forgery token is swapped in all three places it can sit, the cookie, the header and the body, because changing only one returns a 403 that looks like a working control. Identifiers come from the other account's own traffic, never guessed.

3 · Prove

Check before calling it a finding

A matching status code is not enough on its own. Penjester repeats the request, sends it with no credentials, and tries an identifier that belongs to nobody. Then it counts how many of the owner's identifying values actually came back. A size difference is weighed against the endpoint's own repeat reads, so a page that naturally varies is not read as a leak, and a write is confirmed by reading the object back as its owner.

4 · Account

Say what was skipped

Every request it refused and every check it did not run is recorded with the reason and shown in the report. An empty report means tested, not ignored.

What it finds

The jobs it is built for

  • → Tenant isolation Whether an account in one organisation can reach another organisation's data.
  • → IDOR between peers Two members of one workspace share most of a page, so similarity proves nothing. Penjester decides on the records: how many of the owner's values came back, and whether they were absent from the actor's own reply.
  • → Privilege escalation The actions an admin's interface offers that a member's does not, replayed on the member's session to see whether the server enforces the difference.
  • → Endpoints open to anyone If the same data comes back after every credential is stripped, the endpoint is open to anyone. That is reported on its own, not as a cross-account issue.
  • → Showing an endpoint is safe For a hard-to-guess identifier, Penjester searches the traffic your account genuinely received. If the identifier never appears, the issue is not reachable, and the report says how many responses were searched.
The Knowledge tab detail pane for one endpoint
assets/img/knowledge-detail.png
Burp → Penjester → Knowledge
One endpoint: what it is, the identifiers it carries, what it is a candidate for, and whether a reply has ever returned personal data.

The rest

What else is in it

Passive checks

Reading, not probing

Rules that read the traffic you already have, each tagged with its OWASP category, plus a DOM source-to-sink pass and a scan for secrets. None of them send anything.

Manual tools

The parts you drive

Hold a request, swap an identifier for another account's real value, or send it as another account. Anything crafted goes to Burp's Repeater for you to send. Nothing fires on its own.

Coverage

Counted per class

Coverage is counted per endpoint and per vulnerability class. A class nothing has tested yet reads as not measured, not as zero.

A model, if you want

Judgement only

A local model or Claude can read the results and help write them up. It never composes a request, never sends, and never sees a credential value.

Guardrails

Safe on a live system

Scope fails closed, so nothing outside it is touched. Destructive paths are refused to the automated sweep and left to your own deliberate click.

Stays local

Nothing leaves

Everything lives in your Burp project. The only outbound traffic is to the target you scoped, and to a model endpoint if you set one, which can be a local one.

The right-click menu: create an IDOR rule, swap an id for another account's value, send as another account, or send with no credentials
assets/img/send-as-menu.png
Burp → Penjester → History, right-click a request
Right-click a request to make an IDOR rule, swap an id for another account's real value, or send it as another account, as the same account for a control, or with no credentials.

What it does not do

On purpose

  • — No payload scanning It does not test for SQL injection or XSS. Burp's own scanner does that well, and Penjester can point it at a request when you ask.
  • — Nothing runs on its own A run starts when you start it. There is no schedule and no daemon.
  • — No severity score Impact depends on what the data is, which only you can judge. It suggests a starting point and nothing more.
  • — No model in the sending path One function sends every crafted request, and no model can reach it.

Next

Try it on an application you can test.