Vulnerability Disclosure Programme

11 August 2021


At TrueLayer we welcome reports from security researchers wishing to responsibly disclose security issues to us. Please note that issues reported to us via the vulnerability disclosure program are not eligible for a financial reward. The bug bounty program should be the first port of call for reporting security issues to us.

If you still wish to report a security issue to us and do not wish to go through the bug bounty program, then please read on and ensure you abide by the terms of our disclosure program before performing any security tests on our services. 

Disclosure Policy

Please do not discuss any vulnerabilities (even resolved ones) without express consent from TrueLayer.


All our external production assets are considered in scope as part of the vulnerability disclosure program. This includes all applications, network services and systems exposed in any domain owned by TrueLayer as detailed below:

  • *

  • *

Subdomains of which upon access redirect to 3rd party services should be considered out-of-scope. All vulnerabilities reported should have a clear and demonstrable impact translating to a concrete and meaningful security risk.

All our open source repos on GitHub are considered in scope, but the severity will be addressed on a risk basis.

Out of scope issues

The following classes of vulnerabilities should NOT be considered eligible for the TrueLayer vulnerability disclosure program.

  • Vulnerabilities relying on phishing via social engineering of TrueLayer employees

  • Denial of service

  • Lack of rate limiting issues

  • User enumeration

  • Missing best practices in SSL/TLS configuration

  • Missing best practices in HTTP headers configuration

  • Missing best practices in DNS records

  • Missing best practices in Email such as DMARC

  • CSRF against logging out functionality or other non state-changing functions

  • Access to information which is intentionally "public"

  • Directory listing

  • Software version disclosure

  • Issues affecting third party applications or dependencies used by TrueLayer, unless a significant security impact is proved (i.e. we expect a full exploit). More generic issues without an actual impact should be reported to the relevant vendor (if the issue is not already publicly known).

  • Issues only available in self-exploitation scenarios (e.g. self XSS or pasting JavaScript into the browser console)

  • Clickjacking on pages with no sensitive actions (e.g. on

Testing Guidelines

The guidelines below are provided for external security testers in order to guarantee minimal disruption to our services and assure the confidentiality of our customer data.


Dynamic fuzzing should be rate limited to no more than 5 requests per second. The following header should be included along with each HTTP request:



Security issues discovered in any TrueLayer applications and systems should be explored to the minimum extent possible to demonstrate the presence of the vulnerability.

For instance, in the context of a SQL injection vulnerability a simple time-based payload or a boolean based one is sufficient to demonstrate the vulnerability, without retrieving the whole database content.

Cross-Account Access

Researchers should create and use their own test accounts for any TrueLayer service requiring authentication. This is particularly relevant for vulnerabilities that can result in unauthorised cross-account access such as insecure direct object reference, lack of access controls, account hijacking and so on. Under no circumstance should exploitation of vulnerabilities like those mentioned above be conducted against other customer accounts.

Filing a report

A vulnerability disclosure report should include the following mandatory details:

  • Reporter name

  • Vulnerability description

  • Affected component

  • Estimated severity and potential impact of the issue

  • Any other supporting data

Vulnerability reports should be sent to the [email protected] email address. Security researchers are encouraged to encrypt sensitive vulnerability details using our public PGP key available in the security.txt well-known file.