Your testing should be kid-safe, ethical, legal and fun!

Thank you in advance for your help in keeping Jooki fun, safe and reliable for kids.
--Team Muuselabs

• my.jooki.rocks - the web app and backend server
• *.jooki.rocks - any other service hosted by Muuselabs excluding our web stores (see Out Scope)
• *.muuselabs.com - company website and associated services

We're a small Belgian startup scrambling to scale, so we want to limit the impact of testing on staff time. The following are out of scope for now:

• DoS attacks
• Social engineering
• www.jooki.rocks - our web store
• ca|en|eu|fr|nl|uk|us.jooki.rocks - our international web stores
• Our listings & reviews on 3rd party web stores (Amazon, Bol, etc)
• Muuselabs accounts on 3rd party sites: social media, github, G Suite etc.

We plan to expand the scope of this project later as these could be fun ;-)

Application

• API key disclosure without proven business impact
• Wordpress usernames disclosure
• Pre-Auth Account takeover/OAuth squatting
• Self-XSS that cannot be used to exploit other users
• Verbose messages/files/directory listings without disclosing any sensitive information
• CORS misconfiguration on non-sensitive endpoints
• Missing cookie flags
• Missing security headers
• Cross-site Request Forgery with no or low impact
• Presence of autocomplete attribute on web forms
• Reverse tabnabbing
• Bypassing rate-limits or the non-existence of rate-limits.
• Best practices violations (password complexity, expiration, re-use, etc.)
• Clickjacking without proven impact/unrealistic user interaction
• CSV Injection
• Sessions not being invalidated (logout, enabling 2FA, etc.)
• Tokens leaked to third parties
• Anything related to email spoofing, SPF, DMARC or DKIM
• Content injection without being able to modify the HTML
• Username/email enumeration
• Email bombing
• HTTP Request smuggling without any proven impact
• Homograph attacks
• XMLRPC enabled
• Banner grabbing/Version disclosure
• Not stripping metadata of files
• Same-site scripting
• Subdomain takeover without taking over the subdomain
• Arbitrary file upload without proof of the existence of the uploaded file
• Blind SSRF without proven business impact (pingbacks are not sufficient)
• Disclosed/misconfigured Google Maps API keys
• Host header injection without proven business impact

General

• In case that a reported vulnerability was already known to the company from their own tests, it will be flagged as a duplicate
• Theoretical security issues with no realistic exploit scenario(s) or attack surfaces, or issues that would require complex end user interactions to be exploited
• Spam, social engineering and physical intrusion
• DoS/DDoS attacks or brute force attacks
• Vulnerabilities that only work on software that no longer receive security updates
• Attacks requiring physical access to a victim's computer/device, man in the middle or compromised user accounts
• Recently discovered zero-day vulnerabilities found in in-scope assets within 14 days after the public release of a patch or mitigation may be reported, but are usually not eligible for a bounty
• Reports that state that software is out of date/vulnerable without a proof-of-concept

Mobile

• Shared links leaked through the system clipboard
• Any URIs leaked because a malicious app has permission to view URIs opened
• The absence of certificate pinning
• Sensitive data in URLs/request bodies when protected by TLS
• Lack of obfuscation
• Path disclosure in the binary
• Lack of jailbreak & root detection
• Crashes due to malformed URL Schemes
• Lack of binary protection (anti-debugging) controls, mobile SSL pinning
• Snapshot/Pasteboard leakage
• Runtime hacking exploits (exploits only possible in a jailbroken environment)
• API key leakage used for insensitive activities/actions

At the moment there are no cash bounties for this project. However, high, critical and exceptional exploits will be rewarded with a Jooki 2 (when they start shipping).

All our rewards are impact based, therefore we kindly ask you to carefully evaluate a vulnerability's impact when picking a severity rating. To give you an idea of what kind of bugs belong in a certain severity rating we've put some examples below. Note that depending on the impact a bug can sometimes be given a higher/lower severity rating.

Examples of these levels include:

Critical:

• Remote Code Execution on a Muuselabs server with the potential to take control of all Jooki

High:

• Exploits with potential to access private customer data
• Exploits with potential to expose business-critical Muuselabs Intellectual Property

Medium:

• Exploits with a potential to harm the integrity of the Muuselabs assets and its customers, such as stored XSS on a public page.