Hello everyone, I am jirosec.I'm currently a university student, and in my free time I enjoy bug bounty hunting, breaking things, and responsibly reporting vulnerabilities. Using these techniques, I've found several valid issues and earned some good rewards.

I'm writing this because I couldn't find beginner-friendly content specifically about reverse engineering web apps and APIs from a bug bounty perspective. Even though these are basic concepts, they are very important for understanding application behavior while hunting.

This writeup may help you identify:

  • Access control issues
  • Information disclosure
  • Hidden API flows
  • Chained vulnerabilities
  • Server-side bugs
  • Application logic issues

What is Reverse Engineering?

Reverse engineering is the process of understanding how a web application works internally by observing:

  • Requests and responses
  • API endpoints
  • Authentication flow
  • JavaScript files
  • Tokens and session handling
  • Trusted parameters

The main goal is to understand how the application communicates with the backend and what the server trusts.

How to Perform Reverse Engineering?

While testing a web app:

  • Perform actions inside the application
  • Capture requests using a proxy
  • Observe endpoints and methods
  • Read JavaScript files
  • Understand authentication & authorization flow
  • Identify trusted parameters and trust boundaries

Most applications use:

  • Cookies
  • Access tokens
  • Session tokens
  • Or sometimes all of them together

In most modern apps, the backend mainly validates the access token.

What are Trust Boundaries?

Trust boundaries are parameters or identifiers trusted by the server to authorize actions.

Case Study

Scenario

A web application provides a collaborative whiteboard canvas where users can design products or presentations.

My Observation

  • I started using the application normally and monitored requests in a proxy.
  • I observed that the server authorizes users using an access token.
  • The application used:workspace_id ,canvas_id as trust boundaries.
  • When modifying workspace settings, the application used the normal access token.
  • But while making changes inside the whiteboard canvas, the application used a different large token.
  • If I tried using the normal access token directly on the canvas endpoints, the server returned:
401 Unauthorized

After analyzing the logs, I identified that before interacting with the canvas, the application first sent a request to:

POST /session

This endpoint generated a temporary canvas session token.

  • That token was required to perform actions inside the whiteboard canvas.

Conclusion

While reverse engineering applications, don't just test endpoints blindly. Try to understand:

  • How the application works
  • What parameters the server trusts
  • How tokens are generated
  • How authorization is validated
  • How different features communicate internally

The better you understand application logic, the easier it becomes to discover impactful vulnerabilities.

Though I'm only a part-time hunter/researcher, I wanted to share some of the knowledge I've learned through practice. I hope this writeup was useful.

If you enjoyed the content, don't forget to DM me and share your feedback on LinkedIn or X.

I'm also looking for collaborations with other hunters and researchers. If you have some experience and would like to work together, feel free to reach out.

Happy hacking and happy hunting 🚀