Auth, scope & BOLA

Auth profiles, login macros, environments, match & replace, and role-diff.

Most real findings show up once you're testing as a specific user — this group of tools is about establishing identity, then comparing what different identities can reach.

Auth profiles

An auth profile is a saved way of authenticating: a header (Authorization: Bearer ...), a cookie, or basic auth. Create one per role or account you want to test with — for example admin, regular-user, unauthenticated. Once saved, a profile can be applied to Repeater requests, active rules, and role-diff runs without re-entering credentials each time.

For flows where auth isn't a static header — a login form that returns a session cookie, for instance — use a login macro instead (see below), and reference its output from the profile.

Login macros

A login macro is a small recorded sequence: send a login request, extract a token or cookie from the response, and chain that value into the next step (and into whatever auth profile uses the macro). This covers auth flows that need a live request to obtain a credential, rather than a long-lived static token you can paste in once.

Role-diff (BOLA/IDOR)

This is the guided workflow for Broken Object Level Authorization — the "IDOR" family of bugs where one user can read or modify another user's data by changing an ID in the URL or body.

  1. Set up two auth profiles for accounts at different privilege levels (or the same level, different owners — e.g. two regular users who each own separate resources).
  2. Pick the endpoint(s) to test.
  3. Run role-diff. Studio replays the same requests under each profile and compares the results.
  4. A response that succeeds under a profile that shouldn't have access is a strong signal of an authorization gap — it's captured as a finding with both exchanges attached as evidence, so you can see exactly what differed.

Environments

An environment is a named set of variables (base URL, API keys, other per-target values) so one project can point at more than one target — staging vs. production, or multiple services in the same system — without duplicating your endpoints, auth profiles, and findings into separate projects.

Match & replace

Rules that rewrite requests or responses as they pass through the proxy — for example, stripping a header, swapping a hostname, or forcing a query parameter. Useful for keeping a client pointed at the right environment, or for stripping something (like an auth token) out of what gets logged, without editing the client itself.

Next: Checklist & reporting turns everything you've found into something you can hand off.