Flutter UK & Ireland looks forward to working with the security community to find security vulnerabilities in order to keep our businesses and customers safe.

SLA

Flutter UK & Ireland will make a best effort to meet the following SLAs for hackers participating in our program:

• Time to first response (from report submit) - 2 business days

• Time to triage (from report submit) - 4 business days

• Time to bounty (from triage) - 6 business days

We’ll keep you informed about your reports’ state throughout the process.

Responsible Disclosure & Credit

• Follow HackerOne's disclosure guidelines.

• Any information you receive or collect about us, our affiliates, users, employees or agents must be kept confidential. It’s strictly prohibited to use, disclose or distribute any such information.

• Written permission from Flutter UK&I is required for the disclosure of any vulnerability found. Disclosure requests must be submitted through the HackerOne platform.

Program Rules

• You must be 18 years of age or older and meet the other eligibility and verification criteria to use our services, as outlined in our General Terms & Conditions available at https://support.skybet.com/s/article/Sky-Betting-and-Gaming-General-Terms-Conditions , https://www.betfair.com/aboutUs/Terms.and.Conditions/ and https://www.paddypower.com/aboutUs/Terms.and.Conditions/.

• In connection with your participation in this program you agree to comply with all applicable local and national laws.

• You must use your own account (or a dedicated test account) for testing or research purposes. Do not attempt to gain access to another user's account or confidential information. To prove cross-user account access both accounts must be registered to yourself.

• Make a good faith effort to avoid privacy violations and destruction of data. Only interact with accounts you own. Also, any operation that leads to the interruption or degradation of our services is explicitly forbidden.

• Don't use common vulnerability scanners. The search for vulnerabilities should be manual, although custom tools with automated requests are allowed if limited to 5 requests per second.

• Minimize the mayhem. For instance, when testing for a command injection vulnerability, it is sufficient to show the output of the id or hostname commands, and you should stop the exploitation at this point.

• Social engineering (e.g. phishing, vishing, smishing) is prohibited.

• Provide detailed reports with reproducible steps. If the report is not detailed enough to reproduce the issue it won’t be eligible for a reward.

• Submit one vulnerability per report, unless you can chain vulnerabilities to increase impact.

• When duplicates occur, we only award the first report that was received (provided that it can be fully reproduced).

• Multiple vulnerabilities caused by one underlying issue will be awarded with only one bounty (e.g. multiple domains that point to the same component, general caching vulnerabilities, etc.). Only the first report will be valid, the other reports will be closed as duplicates.

ATTENTION, when analysing applications that are hosted by Cloud Service Providers (CSPs), carefully read and always oblige to the CSP Rules Of Engagement (ROE). Examples:

• ROE for AWS: https://aws.amazon.com/security/penetration-testing/

• ROE for Azure: https://www.microsoft.com/en-us/msrc/pentest-rules-of-engagement

• ROE for Google Cloud: https://cloud.google.com/security/overview/

(these are just examples, always identify the CSP and follow its Rules of Engagement)

Out of scope vulnerabilities

The following issues are considered out of scope and won’t be eligible for a bounty:

• Security issues/best practices that can’t be exploited with real impact (e.g. outdated service, missing cookie flags, clickjacking/CSRF on endpoints with no sensitive actions/data, lack of DKIM/DMARC/SPF, etc.). All reports require a working PoC exploit to be considered valid. For example, a lack of bruteforce protection report requires a PoC with your own account where the password is successfully guessed after 100 failed attempts (using a wordlist with 100 random words before your own testing password).

• WordPress issues without real impact such as user enumeration and the presence of Xmlrpc.php (https://make.wordpress.org/core/handbook/testing/reporting-security-vulnerabilities/#why-are-disclosures-of-usernames-or-user-ids-not-a-security-issue).

• Attacks requiring MitM or physical access to a user's device (e.g. lack of TLS protection on non-sensitive HTTP communication, etc.).

• Flash based client-side vulnerabilities such as Flash XSS, Flash Open Redirect or Flash Content Injection.

• Any activity that could lead to the disruption of our service (DoS, DDoS).

Thank you for helping keep Flutter UK&I and our users safe!