The GoFundMe security programme is aligned to the NIST Cybersecurity Framework Functions and a combination of controls from NIST 800-53, CIS CSC Top 20 and the PCI Data Security Standard.
Audits and 3rd party assessments for compliance
Audits: Annually, GoFundMe engages external Assessors to audit its compliance with PCI requirements.
Continuous Testing: GoFundMe engages external Scanning and Penetration Testers to conduct network level and application level penetration testing and vulnerability scanning.
Software development life cycle
GoFundMe’s software development life cycle is fully integrated with our security organisation and strategy. Assessment of risks of software projects is based on the OWASP Top 10. Secure coding principles are emphasised and developers undergo recurrent secure coding training. Static Code Analysis, Dynamic Code Analysis and Software Composition Analysis are done at multiple stages of the software development lifecycle. All code is version controlled, subject to peer review, integration, functional, and QA testing.
How we protect customer data
GoFundMe takes a number of steps to protect customer data. This is a collaborative effort to identify and mitigate risks and implement best practices.
Data encryption in transit
Data submitted to the GoFundMe website and transmitted over public/open networks is encrypted. TLS version 1.2+ protocols are used and an AES 256 bit cryptographic algorithm is employed. The security team constantly monitors changing encryption standards, makes recommendations and implements changes as needed.
Encryption at rest
We use the FIPS-approved cryptographic algorithm – AES 256 bit when encrypting datasets at rest.
Secure infrastructure hosting service
GoFundMe infrastructure is hosted with Amazon Web Services. AWS maintains multiple certifications for its data centres, including ISO 27001 compliance and PCI DSS Certification. For more information about their certification and compliance, please visit the AWS Security Website.
GoFundMe uses services provided by AWS which include AWS Cloudfront CDN, AWS Application Load Balancing, AWS Availability Zones to distribute its production environment over different physical locations. These different physical locations protect the GoFundMe services from connectivity loss, power loss and other location-specific failures. High Availability is built into the GoFundMe infrastructure. In addition, infrastructure is configured by code & configuration management systems. This enables quick restoration of failed infrastructure. Full and incremental backups are maintained for critical data & infrastructure.
Compliance and certifications
GoFundMe does not store cardholder data as defined in the PCI Data Security Standard, however, GoFundMe has achieved the highest level of PCI Compliance as a PCI DSS Level 1 Compliant Service Provider. GoFundMe is annually audited by an independent PCI Qualified Security Assessor and complies with all the PCI Data Security Standard requirements. GoFundMe is listed on the Visa Global Registry of Service Provider’s website. GoFundMe’s PCI Attestation of Compliance is available on request.
Bug bounty and vulnerability disclosure programme
GoFundMe has a bug bounty/vulnerability disclosure programme. If you believe you have discovered potential security vulnerabilities on GoFundMe, we encourage you to disclose your discovery to us as quickly as possible. GoFundMe maintains a private bug bounty programme with the assistance of BugCrowd. Researchers are eligible for payment upon accepted unknown findings. While those who were not involved in the programme may still submit a security bug or vulnerability to GoFundMe via BugCrowd by filling out the form at the bottom of this page.
All submitted security bugs or vulnerabilities are subject to GoFundMe’s terms and conditions. By providing a submission, you agree that you may not publicly disclose your findings or the contents of your submission to any third parties without GoFundMe’s prior written approval.
- Reports of spam
- Social engineering
- Unconfirmed reports from automated vulnerability scanners
- Disclosure of server or software version numbers
- Hypothetical sub-domain takeovers without supporting evidence
- Session invalidation or other improved security related to account management when a credential is already known (e.g. password reset link does not immediately expire, adding MFA does not expire other sessions, etc.)
- Perceived security weaknesses without concrete evidence of the ability to compromise a user (e.g. missing rate limits, missing headers etc.)
- Reports exploiting the behaviour of or vulnerabilities in outdated browsers
- User/merchant enumeration
- Best practice reports without a valid exploit (e.g. use of “weak” TLS ciphers)
- Disclosure of known public files or directories (e.g. robots.txt)
- Domain Name System Security Extensions (DNSSEC) configuration suggestions
- Banner disclosure on common/public services
- Lack of Secure/HTTPOnly flags on non-sensitive cookies
- Presence of application or web browser “autocomplete” or “save password” functionality
- Sender Policy Framework (SPF) configuration suggestions
- Contact us Form
Out of scope