We are committed to ensuring a safe and secure service for our customers and we value the work done by security researchers in improving the security of our products. We are committed to working with this community to verify, reproduce, and respond to reported vulnerabilities. We encourage the community to participate in our responsible reporting process.
When participating in our responsible reporting process, you can expect us to:
- Work with you to understand and validate your report, including a timely triage of your submission by our partner, Bugcrowd
- Work to remediate discovered vulnerabilities in line with our internal vulnerability management policy (from 1 to 180 days depending on severity)
- Keep you informed when the issue is fixed; and
- If eligible, reward you accordingly
If issues reported to our bug bounty program affect a third-party library, external project, or another vendor, we reserve the right to forward details of the issue along to that party without further discussion with you (the researcher). We will do our best to coordinate and communicate with you throughout the process. However, these bugs will not be rewarded.
To benefit from the knowledge of security researchers, we encourage responsible disclosure of vulnerabilities in our platform. To avoid confusion between legitimate security research through the Bugcrowd program and a malicious attack, we ask that you attempt, in good faith, to:
- Play by the rules. This includes following our disclosure policy, including Bugcrowd’s standard disclosure terms and any other relevant agreements;
- Handle the confidentiality of details of any discovered vulnerabilities according to our Disclosure Policy;
- Report any vulnerability you’ve discovered promptly, provide details of the vulnerability, including information needed to reproduce and validate the vulnerability and if applicable, a Proof of Concept;
- Perform testing only on in-scope systems, and respect systems and activities which are out-of-scope;
- Avoid violating the privacy of others, disrupting our systems, destroying or modifying data not belonging to your test account, and/or harming user experience;
- If a vulnerability provides unintended access to data: limit the amount of data you access to the minimum required for effectively demonstrating a Proof of Concept (PoC); and cease testing. Submit a report immediately if you encounter any user data during testing, such as Personally Identifiable Information (PII), sensitive data, or proprietary information;
- Although usage of automated vulnerability discovery tools is allowed, you should exercise common sense and avoid overly broad
scans that initiate a huge amount of needless requests. This might result in us rate-limiting or blocking
you, or closing your testing account. Do not simply send us a scanner's default output - focus on specific finding and clearly demonstrate impact (PoC). When scanning, use your Bugcrowd testing account (authenticated scans) or make it clear with the
User-Agentheader that you are a researcher. As we're seeing legitimate attacks, this information is useful for us for triage;
- You should only interact with test accounts you own;
- Do not engage in extortion;
- Use the official Bugcrowd channel to discuss vulnerability information with us;
We consider activities conducted consistent with this policy to constitute “authorized” access under anti-hacking laws. To the extent your activities are inconsistent with certain restrictions in our Acceptable Use Policy, we waive those restrictions for the limited purpose of permitting security research under this policy. We will not bring a claim against you for circumventing the technological measures we have used to protect the applications in scope. If legal action is initiated by a third party against you and you have complied with this policy, we will take steps to make it known that your actions were conducted in compliance with this policy. We will not pursue civil action or initiate a complaint to law enforcement for accidental, good faith violations of this policy.
You are expected, as always, to comply with all applicable laws. If at any time you have concerns or are uncertain whether your security research is consistent with this policy, please reach out to us directly before going any further.
PGP Fingerprint: C8A1 9A40 C078 006A 4FD2 5F88 EC52 91DC 8DC2 8D45 PGP key published at: pgp.mit.edu mailto: soc [@] transferwise.com
This program does not allow disclosure. Although we have chosen to adopt a non-disclosure policy, this is only temporary. In the meantime, you MUST not release information to any third party (and the public) about vulnerabilities found and/or remediation measures implemented.
This program adheres to the Bugcrowd Vulnerability Rating Taxonomy for the severity rating and prioritization of issues.
Responsible Disclosure Guidelines
We will investigate legitimate reports and make every effort to quickly correct any vulnerability. To encourage responsible reporting, we will not take legal action against you nor ask law enforcement to investigate you providing you comply with the following Responsible Disclosure Guidelines:
- Provide details of the vulnerability, including information needed to reproduce and validate the vulnerability and a Proof of Concept (POC)
- Make a good faith effort to avoid privacy violations, destruction of data, and interruption or degradation of our services
- Do not modify or access data that does not belong to you
This program adheres to the Bugcrowd Vulnerability Rating Taxonomy for the rating/prioritization of issues.
|Technical severity||Reward range|
|p1 Critical||$3,000 - $4,000|
|p2 Severe||$1,000 - $1,500|
|p3 Moderate||$300 - $500|
|p4 Low||$100 - $150|
Out of scope
When registering for an account at https://www.transferwise.com for testing purposes, use your
@bugcrowdninja e-mail, i.e.
<bugcrowdusername>@bugcrowdninja.com. Please do not use any other e-mail formats, unless testing for a specific bug that requires this.
You can also use alias emails when multiple accounts are required for testing, i.e. <bugcrowdusername>+email@example.com.
Please refrain from creating excessive amount of users. Accounts and / or IP-s that violate this guideline can be blocked.
We are constantly updating our services to make transfer of funds low-cost, fair, easy and fast. We rolled out critical functionalities to meet these targets and we would like to get more eyes on them. Please pay more attention on the following areas:
TransferWise offers a feature for business accounts that enables multiple people to access one account. We call it Multi-User Access (MUA) feature.
Please focus on the possible misuses of this feature set, such as:
Managing users (inviting/removing users and changing roles)
Bypassing role-based permissions, or
Interacting with unauthorized accounts (profiles)
To test this feature, you need to create a TransferWise for Business account under your testing account. The business account name should clearly identify that this is created for testing purposes, e.g. Test Business Account or My Business Testing Account. We currently have only the “Viewer” role available for now and this does not need the business account to be verified. Consult the help page for more information about adding viewers to a business account.
If you need your testing business account to be verified for deeper testing, get into the full business account onboarding process by having yourself verified using real documents (i.e. uploading real IDs). Once successfully verified, you will still be bound by its legitimate use set out in our acceptable use policy (https://transferwise.com/terms-and-conditions).
The MUA feature is still in beta, so check out the status of the functionalities planned out here (https://transferwise.com/gb/business/multi-user-access-status-update). If you run into any issues that have no security impact, please redirect your reports to our help page (https://transferwise.com/help/).
Our API is a less-seen, but critical part of our infrastructure offering. You can find the API docs at https://api-docs.transferwise.com and our sandbox testing environment at https://sandbox.transferwise.tech.
We’re encouraging researchers to read our API documentation and to find API misuses that could significantly affect our business or our customers.
TransferWise offers two types of multi-factor authentication (MFA): SMS and app-based authentication. We would like you to identify possible security issues with our MFA workflow, such as device registration and deactivation and bypass vectors. SMS and SIM vulnerabilities, like those publicised around SS7, are out of scope because we wish to test our implementation and not the underlying infrastructure.
In order to test app-based authentication, you should set up SMS authentication first and then upgrade to app-based authentication via the settings menu on the iOS or Android apps.
SCA support for EEA customers
On 14 Sept 2019, the Strong Customer Authentication (SCA) requirement of the EU Revised Directive on Payment Services (PSD2) went into effect. This requirement ensures that payment service providers within the European Economic Area implement MFA on electronic payments. In compliance, we recently rolled-out application-wide (web, mobile) changes affecting all customers with borderless accounts with country of residence within the EEA. The following functionalities will now require a password or biometrics (mobile app) to proceed:
Downloading of statements
Profile obfuscation when the user is inactive for X minutes (currently, 5 mins)
Users who created their account via Facebook / Google within EEA are now required to set a password; this password will be used for confirmation when any of the above actions are triggered.
We are interested in application misuses that circumvent PSD2/SCA protections we have in place.
TransferWise Debit Mastercard
TransferWise has launched its own debit card - the TransferWise debit Mastercard. We would love to have some attention on card management, account services (statement of accounts), and the card freeze features. Most of these functionalities are only available from the mobile app.
To test these features, you should set up your own Borderless account and have a card issued to you. This involves having a verified TransferWise account and signing up to our Borderless offering. Unfortunately, the TransferWise debit card is only available in selected countries at the moment - see the full list of countries supported here.
Clarifications About Scope
Reports classified as P5 do not qualify for a monetary reward. Focus on impactful findings: how does this affect confidentiality, integrity or availability of TransferWise or customers?
Minor misconfigurations or missing best-practices with low impact typically do not qualify for a reward.
Out of Scope
The following types of submissions will not be accepted and will be marked as "Out of Scope":
- Missing SPF / DMARC records on domains that are not used for sending mail (verify that the domain sends e-mail first)
- Email spoofing where SPF / DKIM / DMARC is configured, but recipient ignores validation failures
- Denial of Service attacks due to excessive amount of requests
- Attacks against customer support; through contact forms or methods (e.g.
https://transferwise.com/contactor phone lines)
- Vulnerabilities only affecting unsupported browsers or platforms (unsupported meaning the vendor has declared end-of-life)
- API keys that are designed to be public. Some 3rd party vendors we adopt use public API keys to identify the customer (for example: as customer ID, for submitting crash reports). When finding a vendor API key, please check from the vendor's documentation how the key should be used and secured; and whether our implementation violates those guidelines. If the key is used only to identify the request sender; but does not grant any unauthorized access, the finding is out of scope.
- Submissions relating to the following HTTP Security Headers:
X-Frame-Options- this header is deprecated and replaced by CSP; we won't be implementing it
- Any other missing HTTP security header, unless accompanied by a impactful PoC
- Any type of social engineering attack against employees
- Sample secrets (private keys, passwords) in GitHub repositories, if the included documentation clearly states this to be a sample/unused password; or it's clear from the code these secrets are only used during automated testing (CI)
- Self-XSS, or XSS attacks that require local access
- Physical attacks against TransferWise premises or employees
- Attacks that require a rooted / jailbroken phone to work; or attacks that require an already compromised system (debugger installed, memory dump possible). If a client device is already compromised to that level, meaningful protection of our processes is not feasible.
- Available typosquatting / punycode / unicode identifiers (such as domain names, e-mail addresses); or identifiers with the name "transferwise" in them.
For example: unregistrered domain name
this-is-transferwise-testing-site.com; or unclaimed S3 bucket name
tr4nsferwis3-staging. Reports typically state phishing risk, but we can't claim every conceivable variation of the name. Reports can still be accepted, if the identifier is in actual use by our production systems (hijacking - with a PoC)
- Attacks that depend on a man-in-the-middle actor in the network path, IF a 3rd party CA is installed to the system
- Default output of security scanners, without any specific accompanying proof-of-concept attack
Findings that require a clear proof-of-concept with impact
The following categories of findings are usually rejected or qualified as a P5 unless the submission
includes a working and impactful proof-of-concept, affecting availability, confidentiality or integrity.
Please include a specific proof of concept that clearly demonstrates significant impact.
For example, it is not enough to say that due to a missing
clickjacking might be possible - you would need to submit a proof-of-concept abuse that is specifically crafted to target TransferWise;
more than an
<iframe> on the page; requires minimal interaction; and clearly demonstrates significant effect for the victim.
- Internal DNS / IP / path (file or class) disclosures
- Descriptive error messages (stack traces, application errors)
- Clickjacking due to lax framing source policies (CSP
frame-ancestors). Reports without a PoC that directly impacts customers (disables 2FA, sets up a transfer...) will be rejected as out of scope
- Missing best practices in TLS configuration (ie TLS1.2 support; BEAST attack; weak cipher suites enabled)
- Not stripped EXIF metadata on files, such as images and PDF-s - unless having a serious and clear impact. For example: author name on a stock image - no impact; GPS coordinates on a profile photo uploaded by another customer - valid impact
- Broken links to any destination that can be hijacked (example: link to an expired domain from our blog).
Unless the link is similar enough to
transferwise.comand can be considered phishing risk; this would be a P5.
- Attacks against our Android/iOS apps that require a malicious (other) application on the device, if there is no feasible defense we could implement
SameSiteflags for cookies not used for secret storage
- Fingerprinting / banner / version disclosure
- CSRF attacks against publicly available forms
- Issues relating to browser "autocomplete" and "save password" functionality
- Data leakage issues from local devices due to
- Information disclosure for non-sensitive information
- Missing best-pracices without a realistic attack scenario
Common findings that are not bugs
- If you have enabled 2FA and you are not asked for it during 2nd login, please check if you have “Remember Me” checkbox enabled on login screen. This sets a cookie about using trusted device.
- Rate limiting and DDoS concerns - while no service guarantees 100% protection and we are open to any valid finding, please keep in mind, that we use Cloudflare rate limiting and DDoS protection service. So your initial test might show no rate limiting, but it kicks in from certain threshold, based on our risk assessment.
- Credentials in Github repos - while we discourage using passwords and especially leaving them in configuration files, we do keep some sample passwords in our public repos. If the password is called “password”, “changeit”, “secret” or similar easy phrase, please read the full code and try to understand if this is really a mistake or maybe left there as an example or placeholder. Findings about sample passwords in GitHub repositories are not valid.
- Not asking for password / 2FA on account deactivation
- Webhook functionality making requests to external IP-s / domains
- Ability to log in after account creation, without verifying the e-mail first
- Avoid submitting the same underlying issue multiple times. For example, if the same issue exists in our testing and production site, send both with one submission
- Some of the pay-in methods incur a transaction charge. Should the researcher chose to use them, TransferWise won't be able to refund these charges. Pay-in using bank transfers will result in no extra charges for the researchers.
- Test transactions should be less than £20 or equivalent in value. Unless you plan to test by actually transferring funds between your test accounts, the transactions should be cancelled through the UI (and money marked as "not sent") once the flow has been completed.
- We have layered protection and not all our security checks happen synchronously and seen in the frontend. There are background verification and fraud checks regarding monetary transactions, so we encourage you to do a PoC and verify if you can actually bypass our procedures.
- Many android researchers like to use Drozer to initially evaluate the attack surface of the app. Please submit a PoC including details and not just the output after running the tool. We also need the environment configuration that was used (e.g. Virtual and the Android version).