Imagine an exploit where a click on a link quietly changed the victim’s account settings, reset their password or sent a hidden request that they never authorised.

These are some of the egregious impacts that 

 vulnerabilities can achieve – especially if Bug Bounty hunters can chain them with other security flaws.

CSRF exploits the trust between your browser and the site you’re logged into, enabling an attacker to trigger actions on your behalf without a single visible alert. This guide explains the main CSRF vulnerability types and shows how to exploit them with real-world techniques in a structured, step-by-step way.

So what is cross-site request forgery (CSRF)?

CSRF bypass via method override middleware

CSRF prevention and mitigation best practices

In simple terms, CSRF occurs when a website allows an attacker to trick a user’s web browser into performing unwanted actions on a trusted site where the victim is authenticated.

Consider this example: you’re logged into your bank account and browsing another website in a different tab. Now, imagine that second website contains some hidden code that sends a request to your bank to transfer money to the attacker’s account.

Because you're already logged into your bank, your browser automatically includes your session cookie with the request, making it appear legitimate. The bank website, which lacks best-practice CSRF protections, duly processes the transfer.

That's the essence of a CSRF attack: an attacker is essentially forging a request on your behalf by exploiting the trust a website has in a user’s authenticated session.

This trust is embodied by the cookie set by the website in your browser to remember your session once you log in. This session cookie is automatically included with every subsequent request you make to that website. This is why you can close the browser, return later and you’ll still be logged in.

If a site lacks robust CSRF protections, an attacker can abuse trust in these cookies to force a user to perform actions like changing their email address or password, or even making purchases without their knowledge or consent.

A successful CSRF attack entails the following steps:

The attacker identifies and recons a web application that is vulnerable to CSRF

The attacker crafts a malicious request tailored to the vulnerable functionality

The malicious request is delivered to the victim via a webpage, email or injected content

The victim is tricked into executing the request, usually by visiting a malicious site

The victim’s browser automatically includes their valid session cookie with the forged request

The vulnerable website processes the request as if it were legitimate – triggering an unwanted action on the victim’s account

The impact of a CSRF attack can vary significantly. Since it enables attacks to perform state-changing actions as authenticated users, it can lead to serious consequences – including data theft, unauthorised funds transfers or even full account takeover – without the victim noticing. If the attacker compromises a high-privilege administrator or dev account, the outcome can escalate to full system compromise.

A POST-based CSRF vulnerability occurs when an attacker tricks a logged-in user’s browser into sending a cross-site POST request that triggers a state-changing action without proper anti-CSRF protections, or by bypassing those protections.

The attacker sets up a server hosting an HTML form that automatically submits a POST request to the vulnerable web application

Client-side JavaScript is typically used to trigger this submission without user interaction

The attacker then sends the victim a link to a malicious server. When clicked, the crafted POST request is sent with the victim’s session cookie, executing the unwanted action

POST-based CSRF is often a little harder to exploit than GET-based CSRF (which we’ll cover in the next section) since the attacker usually needs a hidden form for auto-submission. However, the impact is usually greater, since state changes are commonly implemented by POST.

Imagine a vulnerable content management system (CMS). You discover a POST-based CSRF in the feature for changing user roles. It transpires that this feature accepts an empty CSRF token and still performs the action.

Now you set up a malicious server hosting an HTML POST form that triggers a role change for your guest user account:

Email the administrator a link to the server containing this code and, if the administrator clicks the link, your user account gains administrator privileges on the CMS.

GET-based CSRF attacks are typically easier to exploit than POST-based attacks, because an attacker only needs to trick the victim into making a request – often just by visiting a URL – rather than submitting a form.

Let’s say an attacker sets an HTML image tag’s 

 attribute to point to a vulnerable endpoint. When the victim's browser tries to load the image, it inadvertently triggers the CSRF vulnerability by issuing a GET request to the image’s URL.

Suppose an application allows users to change their email address in account settings via a GET request such as: http://example.com/account/settings?newEmail=attacker@example.com

Crucially, there's no CSRF token in place.

Since no CSRF token is enforced, this payload will force the victim to perform a GET request to the vulnerable endpoint:

In this scenario, an attacker could trick the victim into loading the malicious URL – whether by embedding it in an image tag, sending a crafted link or including it in an email. If the victim is logged in when their browser makes the request, the application will process it as if the victim themselves submitted the change.

As a result, the victim’s account email would be silently updated to the attacker’s address, without any explicit action or awareness on the victim’s part.

When a web application allows user-generated HTML content (such as through a rich-text editor) or contains HTML injection vulnerabilities, stored CSRF attacks can be possible against endpoints vulnerable to GET-based requests.

For example, if blog comments support embedded images, an attacker could craft an 

 attribute points to a CSRF-vulnerable endpoint. When the victim views content containing this tag, their browser automatically attempts to load the image – triggering a malicious GET request that executes the CSRF.

If the attacker can create blog posts, leave comments or send private messages within the vulnerable application, they can persistently store this malicious image. Any user who views the infected content will unknowingly trigger the CSRF.

Let’s say you’re pentesting a web application and discover that users can add images to blog-post comments. Then you discover you can delete your account with a GET request – even though the request appear to use a CSRF token. The issue? The token isn’t tied to the user session – which means the same CSRF token works for all users!

CSRF issues in login forms must usually be chained with other vulnerabilities to be truly impactful. A common scenario is chaining login CSRF with authenticated XSS.

Imagine you discover a stored XSS vulnerability within an authenticated area of your account, such as the settings page. To weaponize it, you can chain it with a CSRF vulnerability in the login form.

The CSRF payload forces the victim to log into the compromised account. Once they are authenticated, the stored XSS executes malicious code in the victim’s browser.

CSRF defences come in many forms, as do the techniques used to circumvent them. Common defence measures include validating the 

 headers, implementing anti-CSRF tokens, or restricting sensitive actions to ‘non-form’ HTTP methods like PUT or DELETE, under the assumption that HTML forms cannot issue such requests.

However, these protections can often be bypassed through various advanced techniques.

 header is not from the same origin or trusted domain, the request fails validation and is denied. However, many implementations only check the 

 header when it is present. So to bypass this defence, an attacker can use an HTML 

Cross-site request forgery: The ultimate Bug Bounty guide to exploiting CSRF vulnerabilities

 (BBP) for Entrust (formerly Onfido) Identity Verification solution would be worthwhile had it only ever produced a single valid vulnerability, according to Luca Sangalli, a security engineer at the company.

This is partly because Bug Bounty Programs surface flaws missed by other testing mechanisms, said Luca in a YesWeHack webinar about Entrust’s experience with crowdsourced security testing so far.

A single-bug outcome for their private BBP would also have been cost-effective, he indicated, since YesWeHack’s pay-by-results model keeps investment proportionate with the number and severity of validated vulnerabilities.

Onfido switched to YesWeHack after managing a one-year program with a rival platform, and the YesWeHack program continued after Entrust acquired Onfido in 2024. With YesWeHack’s help, Entrust’s security team also launched a Vulnerability Disclosure Policy (VDP). Given the workload involved in evaluating findings from several hundred hunters, “it’s really worth having YesWeHack’s triage,” said Luca.

“Bug bounty is not a ‘set and forget’ program,” said Luca. “You need to keep hunters engaged.”

Initiatives such as live hacking events or VIP programs granting early access to new features can help in this regard, he suggested.

But the most obvious tool for sustaining engagement is gradually increasing rewards to reflect the fact that bug discovery becomes harder over time. Accordingly, Onfido rewards range from €50 to a maximum of €12k based on the severity.

“The more hunters you have testing, the more issues they will find, and your product or service will mature security-wise,” explained Luca. “So increasing rewards is also a sign that your service is becoming more secure.”

Of course, you can’t be too aggressive when scaling up rewards. With the help of their YesWeHack customer success manager (CSM), organisations can ensure that bounties reflect asset criticality and decrease significantly as you move down through severity tiers, from critical down to low, recommended Luca.

Nothing can sour relations with hunters more than disagreements over which of these tiers a vulnerability should fall into, given the impact on their earnings. “We tend to discuss the CVSS score with the hunter and try to be fair and honest,” said Luca.

The InfoSec engineer said they always make themselves available if hunters want to discuss an evaluation they disagree with. In fact, in rare cases, hunters have successfully convinced them to increase severity after a CVSS downgrade by Onfido’s security team. It’s counterproductive to be inflexible on this issue, irrespective of the evidence presented, suggested Luca.

‘Valuable for fast-growing, frequently updated platforms’: Gong OffSec lead on the merits of continuous, crowdsourced security testing

While hunters are incentivised to argue for the highest feasible severity, “we have also had at least two occasions where, after investigating internally, we found additional impact” – giving grateful hunters an unexpected earnings boost, said Luca.

Another potential source of friction is duplicate reports. “The same ‘low hanging fruit’ might be reported over and over again by different hunters,” said Entrust security engineer Joachim Vanthienen. “You’re only going to reward one hunter, so the others might get discouraged – so you have to keep them engaged.”

In choosing YesWeHack, “the most important thing for us was the exposure because we wanted a lot of researchers testing our scope, and the features the platform was offering,” said Luca, citing pricing, automations and integrations as attractions.

He also praised the YesWeHack CSM for Entrust, Tristan Lewitte, as “super knowledgeable. He proactively tries to help us improve the program.”

Joachim, meanwhile, welcomed the provision of “a certificate that shows our customers we’re doing Bug Bounty and continuously improving our products.”

Any organisation can launch a program, with one proviso

Joachim advised other organisations launching BBPs to prioritise their most critical assets, both to mitigate the greatest risks first and because they should already be the most heavily tested. “It’s best to do an external pentest first, then have more of a mature target,” he recommended.

Onfido had a high level of security maturity when it launched its BBP. Should businesses with very different profiles consider launching a program?

“I think any organisation can be ready to launch because you can customise the program” to suit your goals, said Luca. “You can put a single endpoint in scope and pay €500 for a critical – it’s up to you.”

Even lacking a dedicated security team might not be an insurmountable challenge, he said – so long as there’s a pentester or vulnerability analyst in place to oversee bug reports and, where necessary, modify CVSS scores to reflect true impact within the context of the environment. “It helps us that we have former Bug Bounty hunters on our security team. I think it’s really important to have someone available who can understand the vulnerability,” said Joachim.

Is your security team managing a Bug Bounty Program yet? 

 to find out more about the benefits of crowdsourced security testing and how this model can be adapted to the specific needs of your organisation.

Browse interviews with YesWeHack customers operating in a variety of regions and industries

‘We wanted a lot of researchers testing our scope’: Entrust’s experience scaling a Bug Bounty Program

A US court ruling earlier in the year could have a 

chilling effect on responsible vulnerability disclosure

, according to Jerry Archer, co-founder of the Cloud Security Alliance.

Archer was referring to how the conviction of former Uber CISO Joe Sullivan was upheld by an appeals court in March, on charges relating to an attempted data-breach cover-up. Sullivan and his team had made the hackers responsible for the breach sign a non-disclosure agreement and paid them what they characterised as Bug Bounty payments. “The ruling takes power away from private organizations to manage their own computer systems by interpreting the federal 

 to prohibit them from retroactively authorizing access to their systems,” 

. He therefore envisaged that good-faith reporting of vulnerabilities might be delayed (as time-to-exploitation 

) by efforts to obtain pre-authorisation – or deterred altogether by the threat of prosecution.

Many red teamers “rarely use AI beyond basic tasks” because of “a lack of trust in the products”, reveals a 

 that focuses on the red team sub-sector. However, AI was broadly seen as a game-changer for streamlining processes and cutting costs. Many of the 18 red teams interviewed as part of the study wanted to automate repetitive security tasks such as 

 in order to “free up expensive human resource to focus on analysis”. There was also “some scepticism” about increasingly numerous certifications and courses around OffSec “due to a perceived lack of quality”.

(OffSec) gives organisations a strategic edge,” according to a PwC report entitled ‘

’. “By simulating real-world attacks, it helps identify and mitigate vulnerabilities before adversaries can exploit them,” it continued. These techniques, which include penetration testing, red teaming and attack simulations, transform “risk into actionable insight”. As such, “this shift from reactive to proactive security is not just a tactical upgrade, it’s a necessity.”

Do you find it difficult to keep abreast of your APIs? It seems you are not alone. Only one in five CISOs (19%) have full visibility of the often numerous APIs in use across their organisation, according to an 

 from Salt Security. Similarly concerning is the fact that 90% of respondents to the survey (300 CISOs) couldn’t be sure that they were free of 

continuously monitoring these digital assets,

 most companies audit APIs every 4-12 weeks.

You might be unsurprised to learn that the longstanding 

 is showing no signs of shrinking. According to Accenture’s 

 report, 83% of IT executives said the skills shortage was a serious impediment to achieving a strong security posture. (Pro tip: Much of your OffSec capacity can be 

existing workforce’s security skills upgraded

 via Bug Bounty). Inevitably, the report also had a few insights into AI, such as 90% of companies professing to lack the maturity to counter today’s AI-enabled threats.

That just leaves a quintet of interesting articles we’ve spotted that, in the interests of brevity, we’ll list as bullet (or rather ‘padlock’) points:

Proof-of-Concept in 15 minutes? AI turbocharges exploitation

80% of CISOs call for regulation of DeepSeek in the UK

Personal liability concerns persist for CISOs

The Wild West of agentic AI – an attack surface CISOs can’t afford to ignore

Why testing AI models in isolation misses the real security risk

 – Mindgard CEO and CTO Peter Garraghan in 

Big news for us and our customers now: YesWeHack is proud to announce our 

. 🚀 Founded in 2021, Sekost empowers SMEs to regain control of their digital exposure through innovative remote cybersecurity audit solutions. Together, we’re uniting around a common vision: bringing innovation and technical excellence to protect organisations of all sizes in an ever-changing digital landscape. We’re thrilled to support the growth of a high-potential French company and to kick off this new chapter together! 

Putting the ‘success’ into Bug Bounty customer success management

Bug Bounty Programs offer the continuous and adaptive qualities that the aforementioned PwC report cites as desirable in security testing mechanisms. With that nimble segue to YesWeHack’s latest content, we’d like to flag a new article about 

, which is as pivotal to the performance of #BugBounty Programs as the triage service. 🧠 In an interview we initially published in our 

, our head of CSM, Selim Jaafar, explains how his team helps customers 

continually optimise their programs to meet their evolving security goals

Another key variable in the output quality of Bug Bounty Programs is the degree to which organisations – supported by the CSM team – can keep hunters engaged. This has been central to 

’s Bug Bounty success, according to members of the sweet-packaged food multinational’s security team.🍬 In a video interview we’ve now 

, Vittorio Addeo and Giulio Maria Gravante flag the variables you should pay attention to when it comes to leveraging this human resource for maximum effect. 💡

How can SecOps teams best mobilise their resources to efficiently remediate and learn from vulnerabilities? 🤔 

 in our series on continuous threat exposure management offers insights into the 

: mobilisation, which follows the scoping, discovery, prioritisation and validation steps.💡

 is looking busy. If you happen to be in the countries or regions in question, then we hope you’ll consider coming to see us (or participating, in the case of the hackathon) at the following events. We’ll happily answer questions about, or show you a demo of, our Bug Bounty and vulnerability management platform:

 – Singapore, four-week qualifying round: 15 September-15 October (online) | Live finals: 22-23 October (Singapore) | registration open for anyone who wants to participate

 – Jakarta, Indonesia | 16-17 September | booth E8

Public Sector Cyber Security Conference and Exhibition 2025

 – Philippines | 24-26 September | booth G1

 – Kuala Lumpur, Malaysia | 30 September-2 October | booth 6141

 – Nuremberg, Germany | 7 - 9 October | booth 7-446

Read this monthly roundup even sooner by subscribing to 

 – our LinkedIn newsletter curating news, insights and inspiration around offensive security topics like Bug Bounty, vulnerability disclosure and management, pentest management and attack surface protection.

Are you a bug hunter or do you have an interest in ethical hacking? Check out our ethical hacking-focused sister newsletter, 

 – offering hunting advice, interviews with hunters and CTF-style challenges, among other things.

US court ruling on Uber breach slammed, red teamers cautious on AI, OffSec offers ‘strategic edge’ – OffSec roundup for CISOs

, the global Bug Bounty and vulnerability management platform, has announced the acquisition of 

, an innovative player in the cybersecurity auditing space. This marks YesWeHack’s first-ever purchase of another organisation. 

This acquisition also represents a major strategic step for Sekost, which can now leverage YesWeHack’s international reputation and commercial strength to enhance its offerings for SMEs and accelerate its expansion. Both Sekost and YesWeHack have enjoyed rapid growth in recent years. Sekost’s revenue has doubled in each of the past two years, while YesWeHack has been rapidly expanding for more than a decade.

A natural alliance built on shared values

YesWeHack and Sekost share a common history: 

Christophe Hauquiert, CTO and co-founder of Sekost

, was a longstanding ethical hacker on the YesWeHack Bug Bounty platform. YesWeHack then became one of Sekost’s first clients, and the two companies established a technological partnership through which they integrated Sekost’s services into the YesWeHack platform.

YesWeHack and Sekost can now unite under a shared vision: combining innovation and technical excellence to deliver straightforward solutions with actionable, tangible results. They are also guided by common values and a culture built on hacking and offensive security, transparency and a human-centred DNA.

As part of YesWeHack, Sekost will maintain its autonomy while gaining access to new resources that can accelerate the development of its offerings for SMEs.

Through this acquisition, Sekost will benefit from:

YesWeHack’s commercial strength and international reputation

Operational reinforcement through the cross-functional expertise of Europe’s leading Bug Bounty platform

Preferential access to new strategic markets and YesWeHack’s global enterprise clients

Product convergence combining continuous diagnostics and ASM (Attack Surface Management) for even more comprehensive attack surface coverage

An accelerated product roadmap, with a new continuous monitoring solution planned by the end of 2025 and integrated support for NIS2 compliance starting in 2026

Enhanced support, greater scalability and an improved customer experience at all levels

New distribution channels via a shared platform and an expanded YesWeHack solutions offering

An enriched offering for YesWeHack clients through Sekost solutions and tangible synergies within the YesWeHack platform

Guillaume Vassault-Houlière, CEO and co-founder of YesWeHack

“This merger brings together two cultures aligned around a common ambition: to provide the most advanced solutions to protect organisations of all sizes in a constantly evolving digital environment. It is also YesWeHack’s first acquisition, and we are delighted to contribute to the growth of a high-potential French company, which will remain based in France.”

Léo Richer, CEO and co-founder of Sekost

YesWeHack was first a client, then a partner, and today we take a historic step together. With YesWeHack, we go further and faster without losing our identity. Joining forces with one of the finest French cybersecurity companies is an extraordinary opportunity for our clients and our growth, and it marks the beginning of an exciting new chapter for our entire team.

Image above: Leo and Christophe, co-founders of Sekost, which has just been acquired by YesWeHack

YesWeHack is a leading Bug Bounty and Vulnerability Management Platform. Founded by ethical hackers in 2015, YesWeHack connects organisations worldwide with more than 100,000 ethical hackers who uncover vulnerabilities in websites, mobile apps, connected devices and digital infrastructure.

The YesWeHack platform offers a range of integrated, API-based solutions: Bug Bounty (crowdsourcing vulnerability discovery); Vulnerability Disclosure Policy (creating and managing a secure channel for external vulnerability reporting); Pentest Management (managing pentest reports from all sources); Attack Surface Management (continuously mapping online exposure and detecting attack vectors); and ‘Dojo’ (ethical hacking training).

YesWeHack complies with strict security, financial traceability and privacy requirements. YesWeHack’s services are ISO 27001- and ISO 27017-certified and accredited by CREST. YesWeHack’s infrastructure uses EU-based, GDPR-compliant private hosting that meets the most stringent standards: ISO 27001, ISO 27017, ISO 27018, ISO 27701 and SOC II Type 2. The YesWeHack platform is also permanently subject to a public Bug Bounty Program.

YesWeHack completes first-ever acquisition with purchase of Sekost, French cybersecurity audit specialist

Along with triage and a strong talent pool of security researchers to draw on, customer success management (CSM) is an indispensable pillar underpinning successful Bug Bounty Programs (BBPs).

We quizzed the head of YesWeHack’s CSM team, Selim Jaafar, about the CSM role, the keys to a flourishing BBP, and how his team ensures programs continually evolve to meet their security goals. 

Selim joined YesWeHack in 2019 as our first customer success manager after roles in security consultancy, project management, communications and customer support.

How does the CSM team typically ensure a successful BBP launch?

It’s about finding an optimal balance in terms of scopes, rewards and rules. You want consistent results that build a use case for Bug Bounty as well as giving customers practical knowledge about running a program effectively, while being conservative enough to avoid a ‘big bang’ effect that overloads the customer with vulnerability reports or rapidly exhausts the budget. 

It’s also important to help the customer adopt some basic good practices, notably with regards to collaboration with hunters. Pre-launch, we familiarise customers with:

How Bug Bounty works and the pitfalls to avoid

Program types and their requirements and pros/cons – such as public or private; grey-box or black-box; focused or wildcard (all assets in scope)

Processing vulnerability reports and communicating with bug hunters to avoid miscommunications, mishandled reports or disputes

Using the platform to build strong processes and reduce time-to-fix and time-to-payout

We also help the customer identify potential scopes; calibrate rules and rewards; finetune the program description for maximum clarity and fidelity to the customer’s goals; set up roles and workflows; shortlist prospective hunters; and brief the triage team. 

To summarise: we ensure that the program reflects customer objectives, and is sufficiently detailed and attractive to hunters so as to promote their engagement and adherence to the rules.

How does the CSM support the customer post-launch?

The CSM guides the security team in handling the first tranche of reports, and setting high standards in terms of communication, qualifying reports, managing delays and so on. 

These early reports often generate many practical and theoretical questions about how best to handle communications with both triage and hunters, as well as considerations on platform functionality. So the training process, which identifies and tackles real-world problems and builds internal knowhow, continues beyond launch.

Initial reports can vary a lot in terms of quantity, quality and diversity. As CSMs, it’s important to evaluate our first impressions. Are the results consistent with expectations? And how were the results processed behind the scenes? This sets the tone for the security team’s capacities and constraints.

We can then give better directions to the customer, whether it’s to refine, slow down, extend or boost the program. We leverage our expertise to help the customer optimise their metrics in tune with their ambitions. 

We often propose tailored program development plans that enable the organisation to harness the community’s talents in an achievable and productive way. We are then proactive in regularly reviewing and optimising the plan in collaboration with the customer to ensure it continues to align with their goals.

How can friction in customer-hunter relationships arise and how can you or the customer avoid or mitigate these problems?

Disputes typically arise due to miscommunications, response times, and divergent CVSS assessments or interpretations of scopes and program rules. There are also challenging edge cases that are invariably addressed by frank and friendly communication, and an empathic and constructive mindset (on both sides). 

We intervene at different junctures to varying degrees, depending on the situation, either to pre-empt a problem, resolve a dispute or draw lessons to prevent recurrences of the problem.

We continuously strive to prevent problems with effective training, by instilling best practices and by encouraging clear program specifications. Nevertheless, there are always unanticipated challenges – and it’s our duty to help both parties find common ground and sensible solutions. 

The success of Bug Bounty Programs ultimately hinges on mutual trust. As a man-in-the-middle, it’s up to us to set standards for improving the framework, rules and processes that can be leveraged to prevent and settle disputes.

What are the most common mistakes made by customers?

 Most misconceptions or mistakes come from transplanting traditional offensive security approaches to the Bug Bounty framework. Yes, Bug Bounty has similarities to pentests, but Bug Bounty success particularly hinges on engendering mutual trust and carefully incentivising and encouraging the engagement of hunters. 

While we strive to acculturate the customer to the crowdsourced testing model during the launch phase, we sometimes have to help them remedy issues such as:

Scopes being unaligned with testing goals.

 For example, testing a mobile app without considering webservices/APIs; a complex scope fragmented into small pieces so the hunter cannot develop a consistent attack scenario; or insufficient detail about the scopes that allows for misinterpretation – all of which can lead to inconsistent results and problems with out-of-scope interpretations.

For instance, applying low to average rewards to mature, complex and hardened scopes, or vice versa. Offering low or zero rewards to medium severity issues is also detrimental, especially when such vulnerabilities can be chained for higher impact and can help hunters familiarise themselves with the program and its scopes.

 These typically arise from a mismatch between expectations and means. If your objective is to find complex vulnerabilities, for instance, then black-box testing a web application is usually unproductive.

It’s legitimate to worry that the goals of hunters and customers might conflict. However, hunters are in reality incentivised to pursue the same primary objective as customers: unearthing vulnerabilities with real business impact. By understanding hunters’ motivations and pain points, customers will see clearly how an open, honest and collaborative relationship – within, of course, the framework of clearly defined rules of conduct – is necessary to produce the best results and avoid problems.

To prevent such issues surfacing, the CSM team must be detail-oriented in managing customer expectations and helping the customer continuously optimise rules, scopes and testing conditions in line with their goals.

How has the CSM operation improved during your more than six years at the helm?

We’ve come a long way not just as a company but as a team too. We have gained a lot of useful experience, as have many of our customers, some of which we’ve been working with for several years.

We’ve developed all kinds of programs, with various setups, strategies and learning curves. Over time our team has grown, we’ve refined our processes, and we’ve built a set of best practices. However complex the customer’s testing needs, and whatever their sector, development model or security maturity, we feel we can handle it.

Finally, our job is fundamentally about providing human, expert support. However, we continually seek ways to automate and streamline processes – which frees us up to focus on delivering best-in-class support.

Putting the ‘success’ into Bug Bounty customer success management: Meet our head of CSM

Stuck on a mobile target that won’t proxy, crashes in emulators and shouts "device compromised"?

This guide takes you from installation to your 

 fast - then shows how to keep control when apps enforce 

SSL pinning, root checks and emulator detection

. You’ll choose the right setup (Android Emulator or Magisk-rooted device) and follow a tested path to interception, hooking and persistence.

 for pinning, root and emulator checks (with Zygisk/LSPosed hiding knowhow)

Why set up an Android lab for Bug Bounty?

Building an Android Bug Bounty lab: the ultimate guide to configuring emulators, real devices, proxies and other mobile hacking tools (featuring Magisk, Burp, Frida)

The YesWeHack Blog

Cross-site request forgery: The ultimate Bug Bounty guide to exploiting CSRF vulnerabilities

Cross-site request forgery: The ultimate Bug Bounty guide to exploiting CSRF vulnerabilities

‘We wanted a lot of researchers testing our scope’: Entrust’s experience scaling a Bug Bounty Program

US court ruling on Uber breach slammed, red teamers cautious on AI, OffSec offers ‘strategic edge’ – OffSec roundup for CISOs

Cross-site request forgery: The ultimate Bug Bounty guide to exploiting CSRF vulnerabilities

YesWeHack completes first-ever acquisition with purchase of Sekost, French cybersecurity audit specialist

Putting the ‘success’ into Bug Bounty customer success management: Meet our head of CSM

Building an Android Bug Bounty lab: the ultimate guide to configuring emulators, real devices, proxies and other mobile hacking tools (featuring Magisk, Burp, Frida)

YesWeHack completes first-ever acquisition with purchase of Sekost, French cybersecurity audit specialist

Nonce CSP bypass using disk cache, ‘quiet side channel’ for request smuggling, Amazon Q and the malicious pull request – ethical hacker news roundup

Dojo challenge #43 CCTV Manager winners & writeup

SQL injection for Bug Bounty hunters

Nonce CSP bypass using disk cache, ‘quiet side channel’ for request smuggling, Amazon Q and the malicious pull request – ethical hacker news roundup

Don't wait for threats to strike

Products

Researchers

Resources

Company

Follow us