Vulnerability Disclosure Program

Qwilr understands that securing the data our customers entrust us with is a big responsibility. A responsibility that we don't take lightly. We value security researchers and the broader security community's efforts to improve security and privacy online.

Qwilr's vulnerability disclosure program aims to value and recognise security researchers who responsibly disclose vulnerabilities to us, explain the conditions and how we will manage disclosed vulnerabilities (including safe-harbour provisions), giving both customers and security researchers confidence in our processes to ensure Qwilr, our customers and their data remain secure.

Guidelines

Qwilr requires that all researchers:

  • Make a good faith effort to avoid violations of privacy, degradation of user experience, disruption to production systems, and destruction of data during security testing
  • Reduce overly broad use of automated scanning tools. We understand that scanning tools are an important first step, however please aim to minimise impact. We're more interested in a researcher's ability to test our application, than someone who can point a scanner at our domain(s).
  • Perform research only within the scope set out below
  • Limit the number of accounts created to three, using emails from the following domains (Note: we do not have a formal program with any of the below providers at this time):
    • @bugcrowdninja.com
    • @guerrillamail.com
    • @maildrop.cc
    • @wearehackerone.com
  • Email a report to security@qwilr[.]com, including:
    • The names and email addresses of any accounts created during testing (noting the above dot point) .
    • A description of the location and potential impact of the vulnerability
    • A detailed description of the steps to reproduce the vulnerability. Please explain what you're doing, we much prefer "modify the value of 'yoghurt_flavour' and submit to the '/api/breakfast/' endpoint" rather than "use BURP repeater". POC scripts, screenshots, or video recordings (we particularly like Loom) are also helpful.
    • Potential remediation activities
    • Your contact details
    • Do not include a severity or rating (we receive too many submissions that are super-duper urgent or most critical vulnerability in the history of humanity for very low risk submissions. If you include a severity of "brown m&m" we'll take your submission more seriously)
  • Wait for our consent to discuss a vulnerability with other parties
  • Engage Qwilr respectfully and honestly
  • Allow us to engage a neutral third party to assist if communications or other problems arise

Response Targets

Qwilr will make best efforts to respond to submissions in the following timeline:

  • Acknowledgement by our support team - 2 business days from submission
  • Triage by our engineers - 10 business days from acknowledgement
  • Remediation - Will vary based on the complexity and level of risk

We aim to keep our security researchers updated throughout the process.

In Scope Targets

  • qwilr.com
  • api.qwilr.com
  • app.qwilr.com
  • springboard.qwilr.com
  • any other Qwilr sites that include a security.txt file (i.e. https://<site>/.well-known/security.txt)

Out of Scope

The following attacks or reports are out of scope:

  • Issues related to rate limiting, brute forcing, or denial of service scenarios (inc. account enumeration)
  • Email verification or impersonation (inc. OAUTH pre-account takeover)
  • Missing best practices in SSL/TLS configuration
  • Missing best practices in Content Security Policy (CSP)
  • Missing security headers which don’t directly lead to a vulnerability or account compromise
  • Presence of common public files, such as robots.txt or files in the .well-known directory
  • Missing DNS and email best practices (invalid, incomplete or missing DNSSEC/SPF/DKIM/DMARC records, etc.)
  • Information disclosure including software version disclosure, banner identification issues, descriptive error messages or headers (e.g. stack traces, application or server errors)
  • Password policy issues, including lack of upper limit on passwords
  • Self-exploitation issues (such as self XSS, cookie reuse, self denial of service, etc.)
  • XSS that requires a file to be opened in another browser tab or window
  • Attacks requiring Man-in-the-middle (MITM) or physical access to a user's device
  • Vulnerabilities affecting users of older browsers (less than two versions behind the current stable version)
  • Previously known vulnerable libraries (including prototype pollution) without a working Proof of Concept that demonstrates a meaningful exploit or account compromise
  • Clickjacking issues, without a working Proof of Concept that demonstrates a meaningful exploit or account compromise
  • Blind Server Side Request Forgery (SSRF), without a working Proof of Concept that demonstrates a meaningful exploit or account compromise
  • UI and UX bugs (including spelling mistakes or broken links)
  • Qwilr social media accounts
  • OSINT information
  • Sites and services provided to Qwilr by other organisations, such as:
    • Drata - trust.qwilr.com
    • Help Scout, including help.qwilr.com

In the interest of the safety of our staff and our customers, the following test types are also out of scope:

  • Social engineering or phishing of Qwilr’s workforce
  • Any attacks against Qwilr’s physical property, offices or data centres
  • Any attacks against other users of Qwilr

Things we do not want to receive

In the unlikely scenario you discover any sensitive information we request that you either describe or redact the below information in your submission.

  • Personally Identifiable Information (PII)
  • Cardholder data, such as credit or debit card details

Rewards

Qwilr may at its sole discretion offer nominal rewards (including monetary rewards) for new and unique vulnerability disclosures. Qwilr will base any rewards on the completeness of the report and the risk to Qwilr and its customers (rather the severity). Security researchers who have worked with us to improve the security of Qwilr can be found on our Hall of Fame.

Higher Risk (aka access to everything): AUD $500

  • Examples: Remote code execution, unrestricted access to underlying file systems or databases, or bypassing significant security controls.

Medium Risk (aka access to an account): AUD $250

  • Examples: Unauthorised access to read or modify other customer accounts, or significant unauthorised access of customer generated content.

Lower Risk (aka modify a user's content): AUD $50

  • Examples: Privilege escalation within an account that leads to data modification, the ability to deliver malicious content to individual creators or consumers, such as XSS, SSRF, and open redirects.

Others (aka everything else): Recognition on Qwilr's Hall of Fame

  • Valid security vulnerabilities that don’t fall into the above ratings such as subscription / feature elevation, information disclosure within an account, or that apply to third-party / external services.

Submissions from people who are subject to international sanctions will not be eligible for monetary rewards.

Safe Harbour

Any activities conducted in a manner consistent with this program will be considered authorised conduct and we will not initiate legal action against you. If legal action is initiated by a third party against you in connection with activities conducted under this policy, we will take steps to make it known that your actions were conducted in compliance with this program.

Modified: 2024-10-30