How do you manage security?

We value your security

At Rows, we know that we have to be a spreadsheet that you can entrust with any type of data. As such, we place the highest priority on ensuring the security of your data.

We follow state-of-the-art security practices, as some of our integration partners, for example, Google or Facebook, perform security audits of our platform.

Your data, including backed-up data, is encrypted at rest, that is when it’s stored on our servers, using 256-bit AES encryption. When sending data from your spreadsheet to our servers, we use HTTPS TLS protocols.

Your credit card data is additionally protected using Stripe’s security procedures.

Vulnerability bounty program

In case you discover a security vulnerability in Rows' website or platform, please report it to Rows' Security team by sending an email to security@rows.com. Your report might be eligible for a reward. Please see the details of our bounty program below.

Rewards

At Rows, we provide rewards to vulnerability reporters at our discretion. The reward amounts are calculated based on the category/severity of each reported issue and are paid out only via PayPal.

Before you submit a new issue, you should calculate the issues' severity using the CVSS calculator and attach the output when sending the issue report.

Eligibility

Here are our eligibility requirements for rewards:

• The issue must occur on the latest publicly available website/app of rows.com.
• You should be the first one to report the issue - We don't reward an issue that has already been reported.
• The issue must be real, not a hypothetical situation. Proof of concept of exploit is essential in order to be eligible for reward.
• You can't disclose the issue publicly without Rows' consent.
• It's recommended you have a video, how to or information to help the Rows team to reproduce the problem.
• The issue must be in scope (see below).

Out of scope

Here are some areas we generally consider to be out of scope:

• Automated Scan Outputs: Reports that are simply the output from automated security scanners without additional insight or validation. (Proven method of exploit).
• Feature Bugs: Bugs that do not have a direct security impact, such as UI glitches or broken links.
• SMTP Issues: Issues related to Simple Mail Transfer Protocol (SMTP), such as missing or misconfigured SPF/DKIM/DMARC records.
• Clickjacking: Clickjacking attacks without a practical, exploitable scenario or significant security impact.
• DNSSEC: Missing DNSSEC on our domains.
• SSL/TLS Best Practices: SSL/TLS best practices such as BEAST, BREACH, Forward Secrecy support, or the presence of certain cipher suites, unless you can demonstrate a realistic exploit affecting our users.
• Cookie Security Flags: Missing security flags on cookies, such as the 'secure' flag on HTTPS pages or 'HttpOnly' flag, unless you can demonstrate a high-impact exploit.
• Information Disclosure: Disclosure of software versions, server banners, and other public information unless you can demonstrate a direct, actionable vulnerability associated with this information disclosure.
• Third-Party Services: Vulnerabilities in third-party code or services that do not lead to an exploit. Services like Discourse (which we use for our forum), HelloNext (to collect feedback) etc.
• Missing HTTP security headers, such as (but not limited to):
  • Content-Security-Policy
  • Feature-Policy
  • HTTP Strict Transport Security
  • HTTP Public Key Pinning
  • X-Content-Type-Options
  • X-XSS-Protection
  • Referrer-Policy
  • P3P
  • Certificate Transparency (Expect-CT)
  • X-Download-Options
  • X-DNS-Prefetch-Control
• Self-XSS: Self Cross-Site Scripting vulnerabilities where the user needs to inject a script into their own session. These types of issues are generally not exploitable.
• Missing Best Practices: Missing security best practices that do not lead to an actual vulnerability, such as autocomplete attributes on web forms.
• Social Engineering: Any type of social engineering attack, including phishing and pretexting, as these are more related to user awareness than a technical vulnerability in the system.
• Brute Force Attacks: Attacks requiring a large number of requests, such as regular rate-limiting issues, brute-force attacks, or password complexity.
• Denial of Service (DoS): Vulnerabilities that only lead to a Denial of Service (DoS).
• Content Spoofing: Issues without an exploitable payload, like text injection or content spoofing.
• Host Header Injection: Unless you can demonstrate a specific and actionable exploit scenario.
• Software Version Disclosure: Disclosure of software versions, unless an outdated version is being used with known exploitable vulnerabilities.
• Missing CSRF Tokens: Missing Cross-Site Request Forgery (CSRF) tokens where the impact is minimal, or the page does not perform any sensitive actions.
• Vulnerabilities Only Affecting Outdated or Unpatched Browsers: Issues that only affect users of outdated or unpatched browsers.
• Issues Requiring Extensive User Interaction: Vulnerabilities that require unlikely user interaction.

Prevention of spam reports

At Rows, we appreciate the time and effort that security researchers put into finding vulnerabilities to help us secure our platform. However, to maintain the effectiveness and efficiency of our vulnerability program, we urge all reporters to adhere to the following guidelines to prevent spam reports:

• No Automated Scan Reports Without Insight: While automated tools can assist in identifying potential vulnerabilities, they often generate false positives or highlight low-severity, non-exploitable issues. We discourage the submission of raw automated scanner output. If you use automated tools, please manually validate each finding, understand its impact, and provide a proof of concept or a detailed explanation.

• Quality Over Quantity: A well-written report with a detailed explanation and proof-of-concept for a single vulnerability is far more valuable than multiple reports with scant details. We urge researchers to focus on the quality of their submissions.

• Penalty for Spamming: To maintain the quality of our vulnerability program, reporters who repeatedly submit low-quality, out-of-scope, or duplicate reports may be temporarily or permanently excluded from the program. In severe cases, we may restrict their ability to submit future reports.

Our goal is to foster a community that values quality and meaningful contributions. We appreciate your understanding and cooperation in maintaining the standards of our vulnerability program.

How to report an issue

To report an issue, you should send us an email to security@rows.com with all the detail below:

• Issue description.
• How to, video or proof of concept.
• CVSS calculator output.
• Self-assessed severity.
• Any other information you consider useful for the Rows team.
• Encrypt your email report with our PGP key.

By submitting a vulnerability report to Rows, you grant to Rows GmbH, a perpetual, irrevocable, no charge license to all intellectual property rights licensable by you in or related to the use of this material. Also, it is important that you notify us if any of this material is not your own work or is covered by the intellectual property rights of others. Not notifying us means that you've represented that no third-party intellectual property rights are involved.

We will reply to your report within 3 business days.

Thank you for helping keep Rows and our customers safe.

Last update: 7 May 2024.