Responsible Disclosure Policy

Recognise Bank Limited which is authorised and regulated by the Financial Conduct Authority (Financial Services Registration No: 849404). In this Vulnerability Disclosure Policy (the “Policy”), references to “the Bank” are to Recognise Bank Limited. The security and privacy of our customers’ confidential information are important to the Bank (“we”, “us” or “our”). We take protecting this information seriously and use technical, administrative, and physical controls to safeguard data. How can you help us to enhance the security of our digital experience? We want to hear from security researchers (“you”, “yours” or “your”) who have information related to suspected security vulnerabilities of any Recognise Bank services exposed to the internet (the “Vulnerability” or “Vulnerabilities”). We value your work and are committed to working with you to support the safety of UK banking and the wider banking infrastructure. Please report Vulnerabilities to us in accordance with this Policy. Thank you in advance for your contribution.

Please email your Vulnerability to [email protected]. Please use our PGP key for secure reporting. The report should include sufficient information to allow us to validate and reproduce the issue, including:

• The service affected, such as the URL, IP address, or product version
• A detailed description of the Vulnerability
• A description of how the Vulnerability was discovered (including tools that were used) or what steps you were taking when you encountered the Vulnerability
• A description of the impact of the Vulnerability and the likely attack scenario
• Proof of concept (“PoC”) code, if applicable. Alternatively, please supply reproduction instruction demonstrating how the Vulnerability might be exploited
• OPTIONAL: Ideally, a suggested patch or remediation action if you are aware of how to fix the Vulnerability, if available

• You agree not to publicly disclose the Vulnerability until the Bank agrees to a public disclosure
• You agree to keep all communication with the Bank strictly confidential and will not make any disclosures without our prior written consent
• You represent the report is original to you and that you did not copy the report or any part of it from another third party
• You allow the Bank and its group companies the unconditional ability to use, distribute, and/or disclose information provided in your report.

If you are considering submitting a Vulnerability report, your values clearly align with ours here at the Bank. You know how critical security is and you want to protect customer information. Understanding this shared perspective, we do not want you to take on or create unnecessary risk in order to discover a Vulnerability. While we support acts taken in good faith to discover and report vulnerabilities, we expressly prohibit any of the following conduct:

• Spamming forms or scanning applications through automated vulnerability scanners
• Publicly disclosing a Vulnerability without giving us a reasonable amount of time to respond to the issue
• Accessing or modifying our data or our users’ data, without explicit permission of the relevant owner. Only interact with your own accounts or test accounts for security research purposes
• Denial of Service (DoS) and Distributed Denial of Service (DDoS) attacks
• Attacks on third party services

We ask that you do the following in conducting your research:

• Contact us immediately if you do inadvertently encounter user data. Do not view, alter, save, store, transfer, or otherwise access the data, and immediately purge any local information upon reporting the vulnerability to the Bank
• Act in good faith to avoid privacy violations, destruction of data, and interruption or degradation of our services (including denial of service)
• Comply with all applicable laws and regualtions

Please be aware that we do not currently offer bounties for disclosures and do not negotiate in response to duress or threats (for example, we will not negotiate a payout amount under threat of withholding the Vulnerability or threat of releasing the Vulnerability or any exposed data to the public). If you find something, please report it immediately to us without conditions.

Recognise Bank values and welcomes external security research, and, as part of an open and transparent relationship with the security community, have taken steps to protect researchers. In doing so we acknowledge the following:

• We will not pursue legal action or initiate a complaint to law enforcement agencies for activities carried out in accordance with this Policy and/or for what we consider to be accidental, good faith violations of this Policy. We consider activities conducted consistently with this Policy and in good faith to constitute “authorised” conduct under the Computer Misuse Act 1990
• You should contact us at [email protected] to request specific approval, setting out your reasons for your request, if you believe your proposed activities are likely to be inconsistent with the terms of this Policy. You should not start your proposed activities until you have our approval
• If legal action is initiated by a third party against you and you have complied with this Policy, we will take reasonable steps to make it known that your actions were conducted in compliance with this Policy to the extent we are able or were aware of your activities
• We believe in giving credit where credit is due, and will not attempt to silence researchers who report vulnerabilities to us. We acknowledge that is some circumstances full public disclosure may be appropriate, but ask that we are provided with advance notification and a reasonable amount of time to address any identified issues prior to public disclosure and to be able to appropriately notify our regualtors (if applicable)
• We will act in good faith to fix issues reported in a timely manner

The following issues are outside the scope of this Policy:

• Our policies relating to the presence or absence of SPF/DMARC records
• Our policies relating to passwords, emails and user accounts, such as email identification verification, reset link expiration and password complexity
• Lack of CSRF tokens (unless there is evidence of actual, sensitive user action that is not protected by a token)
• Login/logout CSRF
• Attacks requiring physical access to a user’s device
• Missing security headers which do not lead directly to a Vulnerability
• Missing best practices (we require evidence of a Vulnerability)
• Self-XSS (we require evidence on how the XSS can be used to attack another Recognise Bank user)
• Host header injections (unless you can show how they can lead to stealing user data)
• Use of a known-vulnerable library (without evidence of exploitability)
• Reports from automated tools or scans
• Reports of spam (including any report involving ability to send emails without rate limits)
• Attacks that require an attacker application to have the permission to overlay on top of our application (for example, tapjacking, clickjacking)
• Vulnerabilities affecting users of outdated browsers or platforms
• Social engineering by Recognise Bank employees or contractors
• Any physical attempts against Recognise Bank property or data centres
• Presence of autocomplete attribute on web forms
• Missing cookie flags on non-sensitive cookies
• Reports of insecure SSL/TLS ciphers (unless you have a working proof of concept, and not just a report from a scanner)
• Any report that discusses how you can learn whether a given username, email address has a Recognise Bank account
• Any access to data where the targeted user needs to be operating a rooted mobile device
• Content spoofing vulnerabilities (where you can only inject text or an image into a page) spoofing vulnerability where attackers can inject image or rich text (HTML), including pure text injection
• Ability to share links without verifying email
• Absence of rate limiting, unless related to authentication
• IP/Port Scanning via Recognise Bank services, unless you are able to hit private IPs or Recognise Bank servers
• Devices (ios, android, desktop apps) not unlinking on password change
• Hyperlink injection or any link injection in emails which we send
• Creating multiple accounts using the same email
• Phishing risk via unicode/punycode or RTLO issues
• Editable Github wikis
• Denial of service

• recognisebank.co.uk
• recognisesavings.co.uk