Post cover image

October 28, 2026

Day 4: VAPT Foundations | Authentication, Sessions & Access Control

VAPT Foundations, Part 4 of 7. Logins, cookies, password resets and the bug that pays the bills: broken access control.

By Ishant

8 min read

Disclaimer_ This article is for educational purposes only. Test authentication and access control only on systems you own, in legal labs, or on targets with clear written authorization. Brute forcing logins, taking over accounts or viewing other users' data without permission is illegal under cyber laws (in India, the IT Act, and similar laws elsewhere), and it harms real people. I, my team and this series are not responsible for anything bad, harmful or illegal you do with this knowledge. Your safety and your actions are in your own hands. Stay in scope, use your own test accounts, and remember: nothing illegal is ever fair play._

Welcome back. Quick recap:

  • Day 1 was passive recon
  • Day 2 was active recon and enumeration
  • Day 3 taught us how web apps and HTTP actually work, with a nice attack surface table in our notes.

Today we use that table to ask two questions that decide whether an application is safe or a disaster:

  1. Can I prove I am who I say I am? (authentication)
  2. Am I only allowed to do and see what I should? (authorization)

Not so fun-fact: when a pentester finds a serious bug in a real app, there is a very good chance it comes from today's topic. Broken access control has been sitting at the top of the OWASP Top 10 for years, and it is not going anywhere. Developers write login pages with great care and then forget to check "should this user see this record?" on the 47th API endpoint. Wahi toh hota hai.

Authentication vs Authorization (The thin line difference)

Authentication (AuthN)Authorization (AuthZ)QuestionWho are you?What are you allowed to do?ExampleLogin with password and OTPNormal user cannot open the admin panelFailure looks likeWeak login, bypassed MFAIDOR, access to other users' dataReal lifeShowing your ID at the gateYour ID doesn't let you into the VIP lounge

Simple memory trick: authentication is the bouncer checking your ID. Authorization is the list of rooms you may enter. You can pass the bouncer and still get stopped at the VIP door, if the app is built properly. Many aren't.

Part A: Login and logout testing

> Login

Open Burp, capture the login request, send it to Repeater, and check the following:

  • User enumeration: Does the app say "user not found" vs "wrong password"? Different messages, different response lengths or different response times all leak which usernames exist. The message should be identical in every case.
  • Brute force protection: Is there rate limiting, lockout, or CAPTCHA? (On labs, test with ffuf or Hydra. On real targets, only if the rules of engagement allow it, because lockouts hurt real users.)
  • Default credentials: admin:admin, admin:password, vendor defaults on routers, CMS panels and dev tools.
  • Credentials in transit: Is login over HTTPS? Is the password ever sent in a URL?
  • Weak password policy: Does it accept 123456?
  • Registration quirks: Can you register Admin or admin (with a space) as a duplicate? Case and whitespace handling causes odd bugs.
  • MFA flaws: Can you skip the OTP step by directly visiting the post-login page? Does the app accept unlimited OTP guesses? Does changing a response from "success":false to true fool the client? Is the same OTP valid twice?

> Logout

Logout looks boring and hides surprising bugs. Test this:

  1. Log in and copy your session cookie
  2. Log out
  3. Replay a request with the old cookie in Repeater

If it still works, logout only deleted the cookie in the browser while the server kept the session alive. That is a finding. Do the same after a password change: old sessions should die.

Also check session timeout, and whether you can stay logged in on many devices forever.

From Day 3 you know sessions are stored in a cookie or token. Now we judge its quality:

  • Flags: HttpOnly, Secure, SameSite. Missing flags are usually low severity but good hygiene findings.
  • Randomness: Does the session ID look predictable, like user1001, a timestamp, or an incrementing number? Collect 20 or so session IDs and compare them.
  • Session fixation: Note your session ID before login. If it stays the same after login, an attacker could plant a known ID and wait. A new ID should be issued on login.
  • Session in the URL: ?sessionid=... leaks through logs and the Referer header.
  • Cookie scope: Is it set for the whole parent domain, so a sketchy subdomain can use it?
  • Token type: If you see a JWT (three Base64 chunks separated by dots), decode it in Burp Decoder or CyberChef. Check:
  • Is sensitive data stored in the payload?
  • Does the server accept "alg":"none"?
  • Is the signing secret weak? (In labs you can crack it with hashcat -m 16500 or john.)
  • Can you change "role":"user" to "admin" and still get accepted?

Safety note: don't paste real tokens from real targets into random online decoders. Use Burp or CyberChef locally.

We go deeper into token and crypto weaknesses in Day 5.

Part C: Password reset and account recovery flaws

Password reset is one of the most abused features because it is literally "log in without the password." Check:

  • Weak tokens: Short, numeric, sequential or time-based reset tokens can be guessed
  • Token reuse and expiry: Can the same link be used twice? Is it valid for days?
  • No rate limit on OTP or code entry: A 4 or 6-digit code can be brute forced
  • Account takeover by parameter tampering: Change email=me@x.com to the victim's email in the reset request. Try sending two emails in one parameter
  • Host header poisoning: Does the reset link in the email use the Host header you sent? If so, the victim might get a link pointing to your server
  • Token leakage: Does the reset token appear in the response body, in the URL or in the Referer header to third-party sites?
  • User enumeration again: "Email not found" vs "Reset link sent"
  • Weak secret questions: "Mother's maiden name" and "first school" are public information
  • Reset without verification: Does the password change need the old password, or at least a valid token?

Test these only on your own accounts. Never trigger reset emails to real people.

Part D: Broken access control

This is the main event. Access control means the server decides, for every request, whether this user is allowed to do this action on this object. Broken access control means the server forgets or gets it wrong.

> Vertical vs horizontal privilege escalation

TypeMeaningExampleHorizontalAccess another user's data at the same levelUser A reads User B's invoiceVerticalGain higher privilegesNormal user performs an admin action

> IDOR (Insecure Direct Object Reference)

IDOR is the most common flavor. The app uses an identifier from your request and returns the object without checking that it belongs to you.

GET /api/orders/1042 HTTP/1.1
Cookie: session=userA_session

Change 1042 to 1043. If you get someone else's order, congratulations, you found an IDOR. In API terms this is also called BOLA (Broken Object Level Authorization).

Where to look for IDs (not just the URL!):

  • Path: /invoice/881
  • Query: ?user_id=23
  • Body: {"account": 4412}
  • Cookies and headers
  • File names: /download?file=report_2891.pdf

"But my IDs are UUIDs, so it's safe." Not really. UUIDs are hard to guess, but if they leak somewhere else (another API, an email, a shared link), the missing authorization check still exists. Hard to guess is not the same as protected.

> Other access control problems to test

  • Forced browsing: Visit /admin, /dashboard/export, /api/users directly as a low-privileged user or even unauthenticated. Hiding a link in the UI is not security.
  • Function-level access control (BFLA): A normal user calls an admin-only API like POST /api/users/delete. The button was hidden, but the endpoint still worked.
  • Parameter tampering: Add or change role=admin, isAdmin=true, price=1 in a request.
  • Mass assignment: The API accepts extra JSON fields it should not, like {"name":"Ishant","role":"admin"}.
  • HTTP method tampering: GET is blocked but POST, PUT or DELETE is not.
  • Path and header tricks: /admin blocked but /admin/, /Admin or /admin%2f work. Headers like X-Original-URL or X-Forwarded-For sometimes change the decision.
  • Multi-step process bypass: Step 3 of a checkout or approval flow can be called directly without finishing steps 1 and 2.
  • Referer-based or client-side checks: Access decided by a header or JavaScript value you control.
  • CSRF (session-related): If a sensitive action can be triggered by a request from another site because there is no anti-CSRF token and no SameSite protection, the app trusts the browser too much. We touch it again in Day 6.

Part E: The authorization testing method (use this every time)

Don't test randomly. Use a simple repeatable method:

Step 1: Make at least two accounts per role. For example, User A, User B, and Admin if available. Use only accounts you created or were given.

Step 2: Build an authorization matrix from your Day 3 attack surface table:

EndpointGuestUser AUser BAdminExpectedGET /api/orders/{id}?own onlyown onlyallUsers see only their ownPOST /api/users/delete???allowedAdmin onlyGET /admin/panel???allowedAdmin only

Step 3: Capture a request as User A, replay it as User B (swap the cookie or token in Repeater). Then replay with no cookie at all.

Step 4: Compare responses carefully. Check the response body, not just the status code. A 200 with an error message in the body is not a bypass. A 403 page that still leaks data in the body is.

Step 5: Try every method and every ID location.

Step 6: Automate the boring part. The Burp extension Autorize (free, from the BApp Store) replays your browsing session with a lower-privileged cookie and flags differences. Still verify manually before reporting.

Common authorization testing mistakes

  1. Testing with only one account, which makes IDOR impossible to prove
  2. Looking at the UI only, and never calling the API directly
  3. Trusting a status code and ignoring the response body
  4. Believing a 403 or a hidden button means secure
  5. Not testing unauthenticated access
  6. Only changing GET requests, never POST, PUT or DELETE
  7. Assuming UUIDs or hashed IDs are protection
  8. Performing destructive actions (delete, edit, transfer) on someone else's real data. Use your own test objects only
  9. Skipping notes, then failing to reproduce the bug for the report
  10. Forgetting to explain impact. "I can read other users' invoices" is a finding. "I can read every customer's invoice, including names and addresses" is a finding people act on

Tools for Day 4

Request replay and comparison: Burp Repeater, Comparer

Automated access checks : Autorize (Burp extension)

Brute force in labs: ffuf, Hydra

Token inspection: Burp Decoder, CyberChef, jwt_tool

JWT secret cracking : hashcat, john

Note keeping: Obsidian, CherryTree

  • PortSwigger Web Security Academy: the Authentication, Access control and IDOR, JWT and OAuth topics. This is the single best source for today
  • TryHackMe: Authentication Bypass, IDOR, Enumeration & Brute Force, JWT Security, Broken Access Control and Session Management rooms
  • Hack The Box Academy: Broken Authentication and Web Attacks modules
  • OWASP Juice Shop
  • DVWA
  • OWASP WebGoat
  • crAPI (completely ridiculous API) and VAmPI: practice APIs built to teach BOLA and BFLA
  • PentesterLab (free tier)

Day 4 checklist

  • Can you explain authentication vs authorization with an example?
  • Did you test login for enumeration, rate limiting and default credentials (in a lab)?
  • Did you test that logout and password change invalidate old sessions?
  • Can you check cookie flags, session ID quality and fixation?
  • Can you decode a JWT and name three things to check in it?
  • Do you know five password reset flaws?
  • Can you tell horizontal from vertical privilege escalation?
  • Did you find at least one IDOR in a lab using two accounts?
  • Do you have an authorization matrix for one lab app?

What's next

In Day 5, we start the OWASP Top 10: broken access control in the Top 10 context, cryptographic failures, injection including SQL injection, security misconfiguration and software supply chain failures. For each one: what it means, why it happens, how to recognize it, and how to fix it.

Let's connect

Got a doubt, a cool IDOR story from your lab, or feedback on the series? Reach out:

Drop a comment telling me: what was the funniest default password you have ever seen in a lab? I will start: admin:password. Yes, The Classic Set.

Stay curious, stay legal, stay in scope. See you in Day 5., <>

  • @r0t-ig

Until the next session, ……….

Embedded content