 was about finding a valid XSS payload. The first five challenge solves and the five best write-up reports were rewarded with a nifty goodies pack.

 We had a great variety of working payloads, demonstrating the vibrant creativity of our community. Thank you all for playing with us!

 geared towards learning bug exploitation the fun and visual way.

The DOJO is three things in one: a learning tool, training platform and a playground.

The DOJO is the arena where the third challenge took place (see the 

We are glad to announce the #3 DOJO Challenge winners list. Everyone will receive a goodies pack.

Other contestants will be able to re-enter the race on the next challenge! Subscribe to our 

 feeds for the forthcoming challenge announcements.

Read on to find the best write-up as well as the challenge author’s recommendations.

 by exploiting two heavily filtered parameters. The execution context was also inside a conditional block that had to be bypassed somehow.

We also asked you to produce a qualified write-up report explaining the logic allowing such exploitation. This write-up serves two purposes:

Determine the contestant ability to properly describe a vulnerability and its vectors inside a professionally redacted report. This capacity gives us invaluable hints on your own, unique, talent as a bug hunter.

We publish here the best write-up report for this session with the permission of its author, 

The used vector also was not the simplest, but nonetheless unique across all the reports.

/—– SENSEI SAPIC’s REPORT ———————————————————–/

Cross-site scripting (XSS) is a vulnerability that allows an attacker to run javascript in a victim browser context. The attacker can thus leverage it to take action on behalf of the victim. Most of the time, an XSS allows to steal a session and to take over an account.

As per the description of the challenge, the goal is to trigger an XSS in the DOJO Playground using two parameters: 

Here is the source code of the challenge:

Let’s have a look at the code… We have two inputs with the following constraints:

The code also has other interesting elements:

Thus, we will not be able to escape the code logic from the 

 is working and make the rest of the code interpreted as template literals.

We will use the template literals placeholder to trigger our XSS. As per the documentation:

 : is the placeholder to be interpreted as javascript

 : is the requested payload to validate the challenge

 : to comment the ” coming present in the code

Thanks for the challenge!! It’s the first challenge I am doing with YesWeHack and it’s a good experience. The DOJO Playground interface makes it fun to play with and it is very good for learning. Thanks, 

/—– END of SAPIC’s REPORT ———————————————————–/

 is the Technical Ambassador at Yes We Hack. He also created the DOJO and this challenge.

Using backticks was not the only possible solution. You could use comments as well with $age = /* and $name starting with */.

Another solution would be to make $age = ", as this would escape the endline character and make a multiline string ending just where our $name start.

DOJO CHALLENGE #3 Winners!

A Vulnerability Disclosure Policy (VDP) helps organisations be more secure. Yet, still too few still understand what a VDP is and why every organisation needs one. Let’s see the value of VDP through the eyes of an ethical hacker. We chat with SaxX, who shares his thoughts and experiences about vulnerability disclosure.

Hello SaxX! Please introduce yourself in a few words. 

. I am a cybersecurity engineer, bug hunter and I am part of the 

I started doing Bug Bounty four years ago now – I was completely unfamiliar with the concept until I met 

”. After quite some discussion, one thing led to another, and they eventually told me, “Hey, why don’t you try Bug Bounty?”.

I quickly got into it and became very active for three years. Since last year, I’ve been taking it easy and getting involved in other projects. However, I plan to gradually get back into it, as I don’t like seeing myself ranked 4th on the platform! 

Today’s topic is Vulnerability Disclosure Policy (VDP) rather than Bug Bounty. Can you tell us in your own words what a VDP is?

First of all, VDP has nothing to do with Bug Bounty. When we talk about responsible disclosure, we actually have to ban the term Bug Bounty

A VDP, to put it very simply, is a communication channel, that an organisation can set up on its website (whether a simple text file or a more detailed web page), through which vulnerability reports would be submitted.

You’ve probably already seen numerous articles in the media explaining the same story over and over again: “Company X has been hacked. However, we’ve learned that 6 months ago, a cybersecurity researcher had tried to contact this company to point out the critical vulnerability exploited today by malicious hackers. Unfortunately, he never managed to get in touch with the right person at the company.”

is a communication channel allowing researchers to submit vulnerabilities they wish to report.

Thank you, that’s very clear. Still, many people confuse Bug Bounty and VDP. Can you explain, in your words, the difference between these two approaches?

The first thing is the monetary aspect. When we talk about Bug Bounty, we automatically draw the parallel with cash. Bug Bounty is all about money, about the bounty.

On the contrary, with VDP, there is no financial reward. When you report a vulnerability as part of a Vulnerability Disclosure Policy, it is your moral and civic consciousness that drives you to do so. Therefore, you don’t expect any rewards, you are only doing this so the company can be aware of the vulnerability, qualify it and correct it as quickly as possible. 

So the major difference between VDP and Bug Bounty is about money!

Another difference is time investment when doing Bug Bounty. You’re invited to a program by a platform and you’re going to spend time on it to find a vulnerability.

VDP is more a matter of coincidence, a “one-shot deal”. You are using a product on the Internet, in your everyday life, and you see something suspicious. Being a cybersecurity researcher, you’re going to want to go further, understand this vulnerability to see what you can do with it. And then, if this vulnerability is valid, and is critical for the company but also for you since you use this product, you will try to get in touch to report it to them.

We made a short video to clearly explain the differences between Bounty Bug and VDP.

So a Vulnerability Disclosure Policy, as you said, is a channel that organisations set up to hear from well-intentioned people. May we then assume that all companies have a VDP in place?

This is quite far from reality, I’m afraid. In an ideal world, yes, every company (from small businesses to multinationals) should have a VDP. But today, in fact, in France and throughout the world, we realise that many, many companies have absolutely no VDP.

Fun fact, I had a look at the top 30 Alexa sites in France before our chat: only three of them have a Vulnerability Disclosure Policy… And out of the 30, there are about eight or nine that have a Bug Bounty program. 

Therefore, if we extend this to a sector of activity, to a city or a country, we realise that much remains to be done.

Why do you think the majority of companies don’t have a VDP? Perhaps they simply don’t know what it is?

The first point, as you mentioned, is that very few companies know exactly what a VDP is. And more surprisingly, only a few researchers know exactly what it is. There is a lot of confusion on the subject.

This confusion is often caused by the publication of Bug Bounty programs next to a VDP by some Bug Bounty platforms. From time to time, we can see on Twitter some “conflicts” between researchers and companies: researchers complain about having received only a t-shirt as a reward for a vulnerability when they were expecting to receive a bounty. There is a huge amalgam.

Not so long ago, for instance, an energy drink company launched a wild card program 

a Bug Bounty platform. It was a huge scope and a big company, so naturally, you’d think there would be some big rewards at stake. And yet, no, it was a “disguised” VDP, without rewards. Quite a few researchers were fooled and were a bit upset then. Understandably, as they invested time in finding vulnerabilities to receive nothing in return…

There is a real lack of communication, visibility and transparency on the subject. We still need to raise awareness over the topic and help all parties, companies and hunters, understand what VDP is all about.

You said earlier that reporting a vulnerability you identified while using a service is a civic duty. Please elaborate on what you do in such a situation.

The first thing is going directly to the website, try to see if there’s a 

 or a page saying, “contact us here”. If there is no information, I go on Twitter and send them a DM (direct message). In half the cases, I get an answer. When I don’t, the third step is to ask fellow ethical hackers to get contacts in the company. And if I still don’t have any result, I post a message on Twitter.

Let me explain through a few stories that have happened over the last few months.

The first one happened at the beginning of the first lockdown (mid-March 2020). I was developing an OSINT tool and I tried to run it on a West African government. Pretty soon, I came across something quite big. After 30 minutes, with a small Python script, I had access to all the information of this service which provided: name, first name, email address, postal address, national identity card number of citizens – to sum up, sensitive data.

I found a generic email address on their official website, so I sent an email. No answer came through. Then, I activated my network, messaging a few groups I belong to. I got a lot of feedback, but I was given contacts of engineers who themselves didn’t know whom to contact internally. There was a real lack of visibility about who were the right people within the organisation.

The last step was posting a message on Twitter. I got a lot of replies, but mostly from people who just wanted to know what it was about. In these cases, I don’t give any information to avoid compromising the affected organisation.

Today, more than 6 months after my first contact attempt, I have had no “serious” contact. The vulnerability is still there. This is a rather crazy and negative experience which shows that even government institutions are far from the mark. Here, it was Africa, that’s another subject, but this example is worth mentioning.

The second experience I want to share is a bit funnier and I was pleasantly surprised. I was invited by a friend to online fundraising to buy a gift for another friend. Before giving my bank account details, I took a look at the application. Soon enough, I realised that with a little vulnerability, I could have access to the contacts of all the people who had participated in this fundraiser.

So, the first thing I did: I went on Twitter and sent a DM to the company. The guys got in touch with me fairly quickly and, above all, put me in contact with the head of the cyber team. I spoke to him on the phone to explain my findings and the next day, they sent me a voucher to thank me, as the vulnerability I had found was quite critical. The company didn’t have a Bug Bounty program or VDP. Yet, their Twitter account was quite effective as they were able to redirect the information to the right person quite quickly.

We have a dedicated White Paper to guide you thanks to best practices and a thorough examination of available tools. 

And the last anecdote is about a city, Rennes. Again, I was testing the new tool I am developing. I was quickly drawn to a subdomain on a high school website. I realised that I could reinstall the website, and by doing so I could put a webshell that gave me a foot in their server. From their server, I would bounce back to the main site, with all that it entails.

I looked for contact details on the high school website but found no mention on how to report a vulnerability. I found a phone number and tried to call, especially as the vulnerability was critical, I got the voicemail and left two messages but didn’t hear back. Then, I sent a message to the generic email address. No answer.

As this is a religious institution and I have acquaintances in this community, I quickly received contact details, including the headmaster’s. Despite our best efforts, we couldn’t get a hold of each other.

The next day, since I had posted a message on Twitter in the meantime, people sent me the number of the school administrator. The guy had already been alerted by others (I must have been the fifth person to call him). I was shocked: the guy didn’t care. I especially think that he didn’t know what we were talking about and, above all, he wasn’t in charge of this website. It was another provider who had to handle it.

End of this unlikely story: a journalist I know wrote a paper about it and was ultimately able to get the information back to the right people. And finally, after this article, the vulnerability was taken into account and corrected…

Absolutely. I have the feeling that, sometimes, organisations deliberately do not have a point of contact for researchers, because they still have that old fear of having to deal with people who might be a threat.

However, nowadays, there are a lot of good-faith researchers who just want to help these organisations protect themselves.

Patience has limits. As a researcher, you spend a couple of hours or even days to find the right contact, who will then have to agree to listen to you and take your remarks into consideration… All this is very frustrating and, at the end of the day, it doesn’t really make you want to help them.

Yes, clearly, this has happened more than once. When I engage in these steps, it’s only when I find something really critical. I’m not going to disturb people for something minor. But yes, I’ve sometimes given up over the years because I’ve never had a response.

What is your approach when searching for vulnerabilities? Are you really looking for them, or do you “stumble” upon them?

For the two examples above concerning the government and the city, it was not necessarily by pure coincidence as I was testing a tool. But in my daily life, as soon as I use a payment platform, for example, I take a quick look at what’s behind it. I launch a proxy and see the requests, see if I can add a request, for example.

Let’s imagine: I have an amount of 300 euros to pay on a website. If I understand how the code is built and try to put 5 euros instead of 300, will it work? I’m doing this out of curiosity. In 60 to 80 per cent of cases, it works. And in these situations, either you act honestly like I do and try to alert the company, or you take advantage of the vulnerability.

Actually, I’m a bit like a bull who sees red. If I see a bit of red, something that catches my attention, I’ll jump in… As a researcher, I want to see how far I can go, it’s a bit like a game.

Have you ever encountered problems after contacting a company?

No, never. I have my own theory on the subject: I think there are different ways of reporting a vulnerability.

Imagine that you find a vulnerability on any website. You can be very arrogant and say, “I found a vulnerability, your site is not that secure, it’s really c***”. Or, you can have a professional and helpful stance by making the other person understand that a vulnerability can happen to anyone, even the best. You can explain that you have found a vulnerability and you are willing to help them understand the problem and make them feel secure.

There are many researchers who are afraid of referring vulnerabilities to companies because they are fearful of having problems afterwards. I think that, once the image of hackers has been demystified, and once companies understand that there are not only “malicious” people in the hacker community, things will get much better.

Today, there are still a lot of people who find vulnerabilities but don’t dare to make the jump, so they keep them to themselves… And, unfortunately, it can be very damaging for companies if an ill-intentioned person finds them instead.

If you would like more information on how YesWeHack can help you set up your VDP, please drop us a message at 

Vulnerability Disclosure Policy through the eyes of a bug hunter

 DOJO, we have initiated a challenge series. The second 

 had been the arena of fierce competition. The first five challenge solves and the five best write-up reports were rewarded with a nifty goodies pack.

The DOJO is the arena where the second challenge took place (see the 

We are glad to announce the #2 DOJO Challenge winners list. Everyone will receive a goodies pack.

 to the other contestants–you will soon be able to give another challenge a try again! Subscribe to our 

 feeds for future challenge announcements.

Read on to find the best write-up as well as the challenge’s author recommendations.

The Challenge here was exploiting a web form and fetching back sensitive information from the SQLite database through an effective one-shot SQL injection on a contact form field. The returned string must contain the system administrator email and password concatenated in a mandatory sequence:
admin:<email>:<password>

We also asked the contestants to produce a qualified write-up report explaining the logic allowing such exploitation. This write-up serves two purposes:

/—– SENSEI SEHNO’s REPORT ———————————————————–/

An SQL injection attack consists of the insertion or “injection” of a SQL query via the input data from the client to the application. A successful SQL injection exploit can read sensitive data from the database, modify database data (Insert/Update/Delete), execute administration operations on the database (such as shutdown the DBMS), recover the content of a given file present on the DBMS file system and in some cases issue commands to the operating system.

SQL injection attacks are a type of injection attack, in which SQL commands are injected into data-plane input in order to affect the execution of predefined SQL commands.

1-/ At first, I see that we are constrained by differents filters.

So the first thing to do is to bypass the filters with this payload :

Now we can show the tables of the database with this command:

The result is interesting but in the code we see that we have LIMIT 5 and we know that we don’t see all tables.

We search for another table with ‘user’ inside:

We found a table ‘users’ with interesting details: email, password, role.

We see different emails but we are also restricted by the LIMIT 5. The table ‘users’ contain the attribute ‘role’. We list the role with this command:

Nice! All that’s missing now is the password :

Remember that the goal is to show the email and password like this:

/—– END of SEHNO’s REPORT ———————————————————–/

Instead of chaining requests with UNION, the intended solution was to bypass the comment filter the same way sehno did for the SELECT filter. This allows you to do the exfiltration in a single INSERT.

Around half the players used the /SELECT* version and the other half used the UNION technique. Both are valid in solutions.

I hope you had fun in this first challenge. Stay tuned for the next ones!

DOJO CHALLENGE #2 Winners!

The security of digital innovations is a primary concern for organisations and individuals alike. New ways of testing the safety and quality of digital services emerge and establish themselves, bringing with them new possibilities to shape security. Still, the majority of digital products and services harbour vulnerabilities. It is thus crucial to identify and correct vulnerabilities as fast as possible.

What can we do to protect ourselves? Who should look for vulnerabilities? Should suppliers or users be informed? If so, when and how? These questions have been around ever since we began creating digital products and services. These questions also define a process known as vulnerability disclosure.

The appropriate management of vulnerabilities is vital to reducing digital security risks. The technical community has developed clear guidelines for reporting potentially unknown or harmful security bugs to the proper person or team responsible. Those guidelines are what we call a Vulnerability Disclosure Policy (VDP).

What is a Vulnerability Disclosure Policy (VDP) and why you need one

What is a Vulnerability Disclosure Policy (VDP)? Why do you need a VDP? All the answers in two minutes 👇

The most robust approach to establishing a secure and accessible communication channel with well-intentioned third parties is a stand-alone comprehensive VDP. It is a commitment that your organisation will receive, test, and if need be, fix vulnerabilities notified by security folks external to the business. By publishing a VDP, the organisation establishes rules that these people must respect. If they do, the organisation pledges not to take any legal action against them. This aspect is known as ‘safe harbour’. A VDP is thus a declaration with legal value.

Difference between a VDP and a Bug Bounty program

Often, when discussing what a VDP is, the question about how it differs from a 

 program comes around. These two approaches are complementary yet are not synonyms.

. With a VDP, the organisation provides anyone wishing to report a bug in good faith with a communication channel. Most often, the rewards to ethical hackers are a ‘thank you’, a Hall of Fame mention or a swag.

Bug Bounty program is a proactive approach

. The organisation mobilises the community to search for and identify bugs on strictly defined technical scopes. Under a private program—the majority of cases,—only a fraction of the community participates. Researchers who identify vulnerabilities within a Bug Bounty program receive monetary rewards according to a specific bounty grid.

Why do we insist on this distinction? Well, because it matters. Many Bug Bounty providers publish the VDP and a parallel Bug Bounty program on the same website. The difference between the two approaches is then not clear enough.

Such a set-up may create confusion for both good-faith hackers and the organisation. The mix-up leads to unpleasant situations for everyone involved: Bug Bounty hunters invest time looking for weak points and therefore expect compensation where there is none to expect. This lack of delimitation, in turn, leads to companies ordinarily receiving too many vulnerability reports, causing a lot of work and resource bottlenecks internally.

YesWeHack – the #1 European Bug Bounty & VDP Platform

, we are careful to set clear boundaries. Our approach is to provide the right guidance and tools so that VDP programs prevent mix-ups. Thus, the VDP is published on the company’s own website: it cannot be mixed up with a Bug Bounty program. Hackers can see at a glance that this is a free way to report vulnerabilities.

From an operational point of view, a VDP complements pre-existing security efforts across business lines. It provides tangible input to security operations, incident response, crowdsourced or in-house security auditing and red teams.

It is also right to highlight what VDP does for the vulnerability finders. By promoting and providing a structured and accessible way to report security bugs, such a process enables smooth communication and legal clarity.

So, a properly implemented VDP reduces digital security risks for all parties involved and adds value to your organisation. Industry-standard best practices and solutions are within reach. 

Practical vulnerability disclosure: VDP made easy

 is among the happy few joining the second edition of the 

 program. Tech4Trust is the first Swiss startup acceleration program for digital trust and cybersecurity. Initiated by Switzerland’s prominent public-private partnership 

, the program aims to boost bold and innovative startups that tackle the major challenge of trust in the digital era. An acceleration powerhouse, Tech4Trust connects the participants with relevant potential partners, customers and research institutions.

YesWeHack has been operating in Switzerland since 2018 and has offices in Lausanne (in the canton of Vaud). Many public and private organisations in Switzerland already rely on YesWeHack to secure their assets the agile way through Bug Bounty.

By taking part in the Tech4Trust program, YesWehack will further strengthen its presence in the Swiss ecosystem and the budding Swiss security community.

YesWeHack joins Tech4Trust, Switzerland’s cybersecurity accelerator

 into development and operations processes and tooling. The methodology is relevant to organisations creating their own applications as well as to those acquiring software. Security and risk management professionals need to adapt practices to leverage DevSecOps full benefits. The opportunity to do so matches the challenge—today’s fast-paced digital transformation needs strategies and tools that practitioners can integrate and automate within DevOps.

For frictionless integration of security to happen, tooling is paramount. The ability to integrate and automate various development, security, and operations processes is at the core of a successful DevSecOps implementation. As maturity differs between organisations, appropriate technology is of the essence. Below, we focus on tools our bug bounty platform natively includes thus making it the “sec” part of the DevSecOps toolchain.

DevSecOps: Integrating security from idea to continuous delivery

DevSecOps is integrating security in development and operations. Protecting applications the DevSecOps way best works with a bug bounty.

Security testing for quick and easy remediation

 The traditional security practice of generating and emailing vulnerability reports in document form will not scale in a DevSecOps pipeline.

 Our experience shows that bug bounty provides effortless integration of security reports in the pre-existing DevOps toolkit.

Security testing is a necessary practice as part of an overall security program. The best practice is to implement security testing during development and in both the preproduction and production environments. The security testing in each of these phases varies in complexity and goals, directly involving several roles and teams.

Such a complex interaction and iteration model requires security testing tooling, which produces results that are usable for quick and easy remediation. Also, the report format is homogeneous—a tremendous advantage as it prevents ambiguity, thus streamlining communication across roles. The 

✅ The quality of the findings and that of the suggested remediation is key to adoption by non-security teams.

As a bug bounty program manager, you receive real-time notifications of new submissions. You can then evaluate the report. Our forms enable hunters to provide a fine-tuned description of the vulnerability they are reporting.

✅ Once the vulnerability is accepted as “valid” by the bug bounty program manager, a ticket is created. From there on, each step of the vulnerability management lifecycle is thus logged. For internal and compliance purposes, you have actual proof of identification and remediation for each vulnerability.

✅ Proofs of concept (POCs) are critical in demonstrating the exploitability of vulnerability, thus specifying its anticipated impact on your environment. Often, hunters include a POC in their report. Requesting one is also possible during the vulnerability evaluation phase.

✅ Ease of configuration and effective integration with the existing SDLC toolchain:

When updating a report, select the status “Ask for integration” to transform the report in a backlog ticket in your internal system (JIRA, GitLab, GitHub).

The bug bounty virtuous cycle of security testing avoids providing inaccurate results to development teams. Thus, developers 

 instead of wasting time to determine whether it is real or not.

smooth inclusion of accurate vulnerability reports to the organisation’s toolchain

 creates no friction between application and security teams. Likewise, delays are significantly reduced, thus favouring security adoption by different business lines.

Each vulnerability report comes with a carefully evaluated CVSS score and a priority estimate. These criteria enable smooth 

. Thus, no security skills or capacity gap looms at the horizon.

Whenever a vulnerability is reported, our hunters include technical specifics that a SOC benefits from in further log inspection. Indeed, when encountering a hunter’s reconnaissance and exploration activity, did the SOC team got an alert? Such a virtuous 

 enrich and fine-tune their tools and use cases continuously.

Operational remediation practice aligns with business logic

 web applications) require continuous protection. More often than not, however, business logic does not permit for DevSecOps to patch production in due time.

Our experience shows that bug-bounty-powered vulnerability identification in runtime scenarios best works with virtual patching.

Vulnerability-free design and development-phase security testing are critical yet insufficient. Thankfully, runtime mitigation using WAF, WAAP or RASP exists: enter the so-called virtual patching. This remediation approach temporarily or permanently mitigates specific loopholes.

In a nutshell, a virtual patch is a rule or a set of rules, deployed in the WAF, WAAP or RASP mentioned above, that diminishes a specific vulnerability in software without changing the underlying codebase. Typically, virtual patching comes in handy when in need of an urgent fix. At the same time, a long-term remediation solution is developed. Thus, this type of fix implements a security policy enforcement layer and allows Ops to keep a system running until a complete fix passes tests and approval.

Vulnerability reduction is our bread and butter. So, the 

 bug bounty platform comes with native features to ensure that weaknesses get a fix and that it does not break the system:

✅ After a vulnerability report is evaluated, you can get a virtual patch with the click of a button. Our partner 

✅ Whenever the fix is available, the bug bounty program manager can integrate it and provide it for security testing to the hunter having initially identified the vulnerability. Naturally, those changes are reflected in the backlog.

✅ Whatever the type of patch you deploy, all actions are logged. That sort of ‘changelog’ may be incredibly precious in environments with strong compliance pressure. Kiss goodbye them tedious Excel sheets!

👍 Should the test pass, you can push next in the DevSecOps pipeline.

By leveraging virtual patching solutions, 

implementing an effective temporary solution

 that prevents attacks on a known vulnerability is possible and easily accessible.

 haunt every member of the DevSecOps team. When legacy uses a web interface, a popular database back end or a component whose source code is unavailable or difficult to modify, we all know a disaster is in the making. Virtual patching is especially useful here as it is an optimal and cost-effective way of addressing vulnerabilities.

Deployments of outsourced or off-the-shelf software

 (especially where original source code is unavailable or the supplier is too long to patch) are similar to legacy. Virtual patching comes in handy here too, addressing any security gaps with little effort.

Through the YesWeHack bug bounty platform, a patch that you have requested—virtual as well as originating from the development team—also gets 

to ensure it prevents the exploitability of the vulnerability.

Since patch requests, tests and acceptance are 

, you need no extra effort to maintain visibility over the security level of the application portfolio.

Powering DevSecOps with bug bounty: more treats in store

DevSecOps implies a profound change in the software industry’s culture. Achieving a harmonious interaction between seemingly contrarian positions is no simple feat. Even though design- and development-stage vulnerability inspection grow in adoption, these approaches exclude runtime security needs, where technical mechanisms external to code are at work. Currently, the bulk of the software security industry relies on occasional inspections such as the yearly penetration testing or compliance assessments. Thus, annual occurrences and end-of-cycle inspection are of little help: they create waste, delay learning, slow down overall delivery and fail to reflect realistic threats.

At YesWeHack, our bread and butter are reducing the number of existing vulnerabilities as a way to mitigate risk sustainably. It so comes as no surprise that our work and the tools we develop aim to smoothen the often-challenging interface between Security and Development. Today, a significant part of organisations is at the planning stage of putting “waterfall” behind in favour of an agile approach that integrates security throughout the entire product lifecycle.

Don’t miss a feature: follow our changelog!

As showcased above, bug bounty goes beyond vulnerability identification alone and natively embarks the whole vulnerability management lifecycle toolchain. A growing number of our clients are embedding those tools in their CI/CD; so, we have decided to dedicate an article to how we help them embed security therein. 

Bug Bounty: the business enabler of any DevSecOps toolchain

: triggering an XSS payload restricted to a very short array of usable characters, notably forbidding the use of parenthesis, numbers and dots.

Wait, what? You don’t know the DOJO yet?

 geared towards learning bug exploitation the fun and visual way. You can even create your own challenges there!

The DOJO is the arena where the 4th challenge took place (see the 

We are glad to announce the #5 DOJO Challenge winners list.

Eboda ( in just 2 hours including lunch 😉

 feeds to be notified of the upcoming challenges.

You had two possible input to inject malicious code: $age is limited to 2 characters, while $name is heavily filtered with a regex limiting usage payload to Alpha + $ + ` + { or } + / characters only. No parenthesis or dot allowed, somewhat disorienting for Js ;/

The YesWeHack Blog

DOJO CHALLENGE #3 Winners!

Vulnerability Disclosure Policy through the eyes of a bug hunter

DOJO CHALLENGE #2 Winners!

DOJO CHALLENGE #3 Winners!

Practical vulnerability disclosure: VDP made easy

YesWeHack joins Tech4Trust, Switzerland’s cybersecurity accelerator

Bug Bounty: the business enabler of any DevSecOps toolchain

Practical vulnerability disclosure: VDP made easy

DOJO CHALLENGE #5 Winners!

Cybersecurity spending: fulfil priorities with leaner resources

How we help our clients step-by-step in their Bug Bounty journey

DOJO CHALLENGE #5 Winners!

Don't wait for threats to strike

Products

Researchers

Resources

Company

Follow us