Post

BAC - B2B app Approach

Posted Updated
By ikajakam
3 min read
BAC - B2B app Approach

B2B apps

Target :

  • SaaS platforms for companies, like:

    • Project management (e.g., Asana, Jira)

    • CRMs (e.g., Salesforce, Zoho)

    • Admin dashboards

    • Invoicing/billing apps

Why?

  • B2B apps often have multiple roles and sensitive data — ripe for BAC misconfigurations.

Get to Know Them

Before attacking, immerse yourself in the app. Treat it like you’re onboarding as a real user — and then turn adversarial.

Understand the Roles & Structure

  • Identify built-in roles (ask docs, register, or inspect UI behavior):

    • admin, user, team_member, finance, support, viewer, guest

  • Use two or more accounts with different roles.

    • Login from separate browsers or incognito windows.

  • Observe:

    • What actions are available?

    • What buttons/forms are enabled or hidden?

    • Any changes in the API calls, headers, or JSON data?

Compare API Behavior

  • Record and diff API calls between roles.

  • Example:

    • admin performs GET /api/export_contacts

    • Try the same with user — if it succeeds → Vertical BAC!

1
2

GET /api/export_contacts
Authorization: Bearer <user_token>
  • Expected: 403 Forbidden
  • If you get: 200 OK → Privilege escalation

Explore Every Page Like a Hacker

  • Surf around each page.
  • Click every button, open every dropdown, try to access all tabs.
  • Fill out every form with edge-case data.
  • Trigger every feature/function and observe :
What to ObserveWhat to Look For
Error messagesLeaks about internal roles/functions
HTTP status codes403, 401, 500, 302, etc.
Hidden elementsGrayed-out buttons, disabled fields

Think Like an Attacker

  • “What if I can change the user_id?”

  • “What if I can edit a role from the client side?”

  • “What if I submit a form with extra parameters?”

  • “What if I access the same endpoint with another token?”

– Apps often reveal more flaws over time as you gain deeper understanding.

– You’re not just using the app — you’re manipulating it.

3 Types per Parameter : Vertical, Horizontal & Contextual for Each Input

A. Vertical BAC

  • Low-privileged user accessing high-privileged function

Example :

1

GET /admin/users

  • Should return 403 Forbidden to normal users.

  • But if it returns user data — it’s Vertical BAC.

B. Horizontal BAC

  • Same-level user accessing others’ data

Example :

1

GET /api/invoices/11783

Change ID to :

1

GET /api/invoices/11784
  • If user A sees user B’s invoice → Horizontal BAC

C. Contextual BAC

  • Role allowed in one context misusing permission in another

Example :
A support role is allowed to view tickets, but shouldn’t delete them.

Try :

1

DELETE /api/tickets/453
  • If allowed → Contextual BAC.

Automate Two with Autorize

Use Burp’s Autorize extension to test Horizontal and Vertical BAC.

Setup :

  • Login as low-privileged user

  • Load high-privileged token (e.g., admin) in Autorize

  • Browse the app — it will test the same requests with another token

Autorize Example Output :

1
2

### Response matches - Access control bypass detected
GET /api/users/3
  • Automates detection of missing role checks and ID-based flaws.

Check Property-Level Access Manually

When updating objects, check if unauthorized users can modify restricted fields.

Example :

1
2
3
4
5

PATCH /api/users/3
{
  "email": "attacker@evil.com",
  "role": "admin"
}

  • A regular user shouldn’t be able to modify roles or organization IDs.

  • If the role is updated → serious Property-Level BAC.

Another :

1
2
3
4
5
6

POST /api/invoices
{
  "amount": 1000,
  "client_id": 37,
  "created_by": 1  <-- suspicious field ###################
}

Curiosities

Look beyond the normal flow. Look for oddities like :

A. Hidden Fields

Inspect forms – check if there are disabled inputs like :

1

<input type="text" name="is_admin" value="false" disabled>
  • Try enabling it via DevTools → Submit → Check if accepted.

B. Unexpected JSON Fields

Use Burp/Repeater to add custom fields :

1
2
3
4
5

PATCH /api/profile
{
  "bio": "hacker",
  "is_verified": true
}
  • If accepted, the app lacks field-level validation

C. Different Behavior per Role

  • API might expose more data for admins.

  • Try calling :
    1

    GET /api/users/3
  • as user and admin — compare responses with Diff tools

D. Hidden Endpoints

  • Try classic admin routes:

    • /admin/settings

    • /internal/config

    • /api/v1/users/roles

    • /api/audit-logs

  • Sometimes not linked in UI but accessible directly

kudos to XSSRAT

Vulnerability, BAC
Pentesting Bug Bounty BAC Vulnerability
This post is licensed under CC BY 4.0 by the author.