Security and Compliance

Overview

Learn more about security at Duffel. This page includes some of the key information and practices that help keep your data safe.

At Duffel, security is one of our top priorities. We really care about protecting our systems and data, as well as our users and their data from nefarious activities. We know how important security is, and we put a lot of effort into ensuring that all of the appropriate safeguards are in place to support our business.

If there's something that you'd like to know but cannot find it on this page, or if you have any questions, please don't hesitate to contact us at security@duffel.com. We'd love to hear from you.

Compliance

You can find our reports on compliance and additional information regarding security monitoring, and overall posture by visiting our Trust Report.

Protecting our customers' data

Encryption of sensitive data 'in transit' and 'at rest'

For data in transit, e.g. an API request, Duffel uses HTTPS for all of its services using TLS (SSL) version 1.2 and above, this includes traffic to our public website (https://duffel.com), our API (https://api.duffel.com) and our Dashboard (https://app.duffel.com). We enforce the usage of HTTPS, by using HTTP Strict Transport Security (HSTS).

• Duffel does not, under any circumstance, store card numbers. All card numbers received via our API are forwarded to the relevant service providers.
• Duffel is responsible for the security of the card data received through our API.

At rest, e.g. stored in our databases, data is encrypted using AES-256.

Physical security

We leverage the world-class physical security from Google Cloud Platform (GCP), a industry-leading cloud-provider. You can read more about their security here

Penetration testing and vulnerability scanning

Duffel has a strict security timeline. Every year we carry out many internal and external audits of our systems, which are performed by both third parties and the internal team. They help to ensure that our systems and its configurations are being frequently reviewed for potential flaws.

We believe firmly in learning from failure, and this is built right into our culture. Some of these practices include:

• Bi-yearly external and internal penetration tests.
• Quarterly Approved Scanning Vendor security scans.
• Monthly internal security scans.
• Post-mortems after significant incidents.

Responsible vulnerability disclosure

Keeping our customers' data safe is one of our highest priorities. If you discover an issue or a vulnerability that may compromise the security of our systems, please report it in a secure and responsible manner. It's worth calling out that sharing open vulnerabilities widely incurs a risk to our business and our users. Please refrain from disclosing the vulnerability until you've had confirmation from us that it has been addressed.

You can read more about how to responsibly disclose vulnerabilities in the Vulnerability Disclosure Cheat Sheet provided by OWASP.

Rules of engagement

As per the Vulnerability Disclosure Cheat Sheet provided by OWASP, we expect that all security researchers should:

• Ensure that any testing is legal and authorised.
• Respect the privacy of others.
• Make reasonable efforts to contact the security team of the organisation.
• Provide sufficient details to allow the vulnerabilities to be verified and reproduced.
• Not demand payment or rewards for reporting vulnerabilities outside of an established bug bounty program.

As a researcher, you can expect that Duffel as an organisation will:

• Provide a clear method for researchers to securely report vulnerabilities. See 'Reporting a vulnerability' below.
• Clearly establish the scope and terms of any bug bounty programs.
• Respond to reports in a reasonable timeline.
• Communicate openly with researchers.
• Not threaten legal action against researchers.
• Request CVEs where appropriate.
• Publish clear security advisories and changelogs.
• Offer rewards and credit where applicable. See 'Reward eligibility' below.

Reporting a vulnerability

This is our version of a 'Bug Bounty Program'. Upon discovering a vulnerability please contact us at security@duffel.com as soon as possible. We recommend that you encrypt your message to us. Our GPG key id is 0xB13FDB69 with its fingerprint being: F4B7 8241 A61A ED4A 69AC 16ED 5122 33E2 B13F DB69.

Do:

• Include as much detail as possible, preferably with steps to reproduce the issue.

Do not:

• Exploit the vulnerability, except to provide a demonstration or you have been explicitly instructed to do so.
• Disclose the issue publicly, until you have confirmation from Duffel staff that you can do so.

Reward eligibility

We understand and appreciate the effort that goes into investigating and responsibly disclosing security vulnerabilities. This work helps immensely in keeping our services and our customers safe, as well as the wider community. Because of that, we want and aim to remunerate security researchers appropriately. However, we will not accept any type of malicious behaviour, or actions that cause disruption to our services. We also want to make clear that we will not pursue legal action against security researchers provided that your activities were legal.

Each submission is assessed individually by our engineering team, however we will not provide rewards for:

• Any denial of service (DoS, DDoS) attacks.
• The usage of automated tools, such as scanners and fuzzers.
  • These tools can negatively impact our quality of service and generate large amounts of noise and cost.
• Social engineering attacks.
• Physical attacks or threats against Duffel staff, merchants or customers.
• Self-XSS.
• Disclosure of server or software version numbers.
• User/organisation enumeration.
• Best practice reports without a valid exploit (e.g. use of “weak” TLS ciphers).
• Reports of spam.
• Hypothetical subdomain takeovers without supporting evidence (e.g. actually taking over the sub-domain).
• Perceived security weaknesses without concrete evidence of the ability to compromise a user (e.g., missing rate limits, missing headers, etc.).
• Submissions that relate to third-party services that Duffel has little or no control over (e.g. https://changelog.duffel.com)
• Submissions that we are already aware of.

Please note that submissions that are closely related should be submitted together rather than as separate bounties.