Who better to help you sharpen your skills in a particular vulnerability type than the hunters who excel at finding it?
Having previously shared tips from leading hunters specialising in SSTI, cache poisoning and business logic vulnerabilities, we're back with expert advice on insecure direct object reference (IDOR), stored XSS and information disclosure from the top-ranked hunter in each category in 2025.
Huge thanks to Xel, Chackal and Drak3hft7 for sharing the mindset and methodologies behind their success, along with practical tips to help fellow hunters level up their skills.
These insights were originally published in the YesWeHack Report 2026.
Xel’s methodology tips for insecure direct object reference (IDOR)
Insights from our #1 hunter for CWE-639 in 2025
Xel was also #1 for use of hard-coded cryptographic key (CWE-321), cryptographic issues, generic (CWE-310), broken or risky cryptographic algorithm (CWE-327)
Program policies don't usually provide detailed specifications for apps, so I always adopt a business-oriented perspective: taking the time to understand the applications, their business purpose and how they were engineered.
Thus, I can figure out whether it makes sense that users are supposed to be able to do ‘X’, or if they should not have access to ‘Y’. This helps me avoid reporting vulnerabilities that are deemed merely informative, instead focusing on the key areas of interest in my threat model.
While this is not necessarily the most enjoyable vulnerability class to test, I feel like IDORs and other access control issues will remain ubiquitous for many years to come: it’s extremely hard for developers to maintain coherent access control when they add new features to their apps so often.
Even the most accomplished developers can inadvertently create access control bugs, so scrutiny from offsec experts is particularly invaluable as a last line of defence.
Chackal’s methodology tips for stored XSS
Insights from our #1 hunter for stored XSS (CWE-79) in 2025
There are several effective strategies for discovering and exploiting stored cross-site scripting (XSS) vulnerabilities. The one I prefer uses harmless (albeit malicious-looking) payloads or even payloads devoid of JavaScript (instead inserting classic HTML payloads containing, for instance, <img> tags or form elements), rather than injecting fully malicious payloads everywhere right away.
This avoids polluting the application. It also reduces the risk of a WAF ban or the payload being rejected or filtered before it reaches the vulnerable sink and confirms the vulnerability’s presence.
Once the payload is inserted, the second phase involves exploring the lifecycle of the target object and all possible interactions with other objects within the application.
For example: does the username appear in other sections besides the profile? Is it displayed during account deletion? Is it displayed during interactions with other users (for instance, within an inter-user chat function)?
The more thoroughly you understand an application, the greater your visibility of the attack surface – which significantly increases your chances of uncovering various vulnerabilities, XSS included.
Drak3hft7’s methodology tips for information disclosure
Insights from our #1 hunter for CWE-200 in 2025
I focus on understanding how data flows through the application rather than relying on a single technique or tool. I usually start by mapping the attack surface from the client side, analysing frontend JavaScript and API interactions to identify endpoints that could expose more data than intended or return sensitive information.
A key part of my approach is testing authorisation boundaries by comparing API responses across different user roles, accounts and application states. This helps uncover inconsistencies, excessive data exposure and missing access controls.
I also pay close attention to edge cases, legacy endpoints, debug features and API objects not directly used by the UI but still containing sensitive data. Another important aspect is contextual impact analysis. Not all exposed data is equally valuable, so I always evaluate how the disclosed information could realistically be abused or chained with other issues.
My main advice is simple: be curious and patient. Always review responses carefully and keep asking: “Why is this data here?” and “who should really be able to see it?” This mindset often leads to the most impactful findings.
