u/Current_Dinner_5162

Hi everyone,

I submitted a report to a public Bugcrowd program (Lightspeed Retail / Ecwid scope) regarding an active historical API token exposure that allowed authenticated administrative API access.

How it was discovered:
While performing normal recon using waybackurls against in-scope assets, I discovered a historical endpoint response containing an API token.

What happened next:

• The token was still valid against the target’s live in-scope API.
• It allowed authenticated administrative API requests.
• I provided proof of successful live access.

The report was marked Not Applicable with the explanation that third-party indexed exposures (e.g. VirusTotal, Wayback Machine, Telegram, etc.) are considered external causes and not security risks originating from the program.

My confusion is that my intended impact was not the historical indexing itself, but rather:

• The credential remained active after historical exposure
• It granted live privileged administrative access
• It appears no revocation / rotation occurred

So my question for triagers / experienced hunters:

Would this still normally be considered out-of-scope simply because discovery originated from historical indexing?

Or could this reasonably be argued as a credential lifecycle / secret revocation failure instead of just “third-party exposure”?

If disputing this decision, what technical evidence would best support reconsideration?

Would you:

• Politely request reconsideration with stronger framing?
• Re-submit under a different vulnerability class?
• Accept closure and move on?

Any triager-side perspective would be appreciated.

I’ve been doing bug bounty for around 5 months now. So far, I’ve found and reported one valid bug (information disclosure).

Recently I’ve been studying API attacks, GraphQL attacks, and broken access control, and I’m trying to improve my methodology.

Right now, I feel like I understand the technical side of these vulnerabilities, but I still struggle with actually finding logic bugs and access control issues during real hunting.

I’d really appreciate advice from more experienced hunters:

• How do you approach finding business logic vulnerabilities?
• What’s your process for discovering broken access control / IDOR issues in real targets?
• How do you think about application workflows when testing?
• Is there anything important I might be missing or should focus on learning next?

I’m trying to move beyond just learning vulnerability categories and start thinking more like an actual hunter during testing.

Any advice, learning resources, or mindset tips would be really appreciated

I’ve been doing bug bounty for around 5 months now. So far, I’ve found and reported one valid bug (information disclosure).

Recently I’ve been studying API attacks, GraphQL attacks, and broken access control, and I’m trying to improve my methodology.

Right now, I feel like I understand the technical side of these vulnerabilities, but I still struggle with actually finding logic bugs and access control issues during real hunting.

I’d really appreciate advice from more experienced hunters:

• How do you approach finding business logic vulnerabilities?
• What’s your process for discovering broken access control / IDOR issues in real targets?
• How do you think about application workflows when testing?
• Is there anything important I might be missing or should focus on learning next?

I’m trying to move beyond just learning vulnerability categories and start thinking more like an actual hunter during testing.

Any advice, learning resources, or mindset tips would be really appreciated

I’ve been doing bug bounty for around 5 months now. So far, I’ve found and reported one valid bug (information disclosure).

Recently I’ve been studying API attacks, GraphQL attacks, and broken access control, and I’m trying to improve my methodology.

Right now, I feel like I understand the technical side of these vulnerabilities, but I still struggle with actually finding logic bugs and access control issues during real hunting.

I’d really appreciate advice from more experienced hunters:

• How do you approach finding business logic vulnerabilities?
• What’s your process for discovering broken access control / IDOR issues in real targets?
• How do you think about application workflows when testing?
• Is there anything important I might be missing or should focus on learning next?

I’m trying to move beyond just learning vulnerability categories and start thinking more like an actual hunter during testing.

Any advice, learning resources, or mindset tips would be really appreciated.

I’ve been doing bug bounty for around 5 months now. So far, I’ve found and reported one valid bug (information disclosure).

Recently I’ve been studying API attacks, GraphQL attacks, and broken access control, and I’m trying to improve my methodology.

Right now, I feel like I understand the technical side of these vulnerabilities, but I still struggle with actually finding logic bugs and access control issues during real hunting.

I’d really appreciate advice from more experienced hunters:

• How do you approach finding business logic vulnerabilities?
• What’s your process for discovering broken access control / IDOR issues in real targets?
• How do you think about application workflows when testing?
• Is there anything important I might be missing or should focus on learning next?

I’m trying to move beyond just learning vulnerability categories and start thinking more like an actual hunter during testing.

Any advice, learning resources, or mindset tips would be really appreciated.

I’m currently learning bug bounty / web security, and I want to start moving into cloud bug bounty / cloud pentesting (AWS, Azure, GCP).

Before jumping into cloud-specific labs and exploitation, I want to build the right foundations first.

What are the core fundamentals / prerequisites I should study and understand well before taking cloud bug bounty seriously?

If anyone here has followed a similar path, I’d really appreciate it if you could share a roadmap or recommend good learning resources to get started.