Responsible Disclosure Policy

The information on this page is intended for security researchers interested in reporting security vulnerabilities to the Firi Security Team. If you are a customer and have a question about security or a password or account issue, please contact us through our support.

This policy sets out our definition of good faith in the context of finding and reporting vulnerabilities, as well as what you can expect from us in return.


This policy covers all Firi services, products or web properties.

Any service on our domains *, but not services that are hosted by third parties. Examples of 3rd party services may include, but are not limited to, Akamai, Azure and GCloud. If you have any questions about scope, please contact us on

Please note! Most reports we receive have little or no security impact or are already known. To avoid a disappointing experience when contacting us, take a moment and consider if the issue you want to report actually has a realistic attack scenario. Please consider (1) attack scenario / exploitability, and (2) security impact of the bug.

More specifically, we ask you to not submit issues regarding:

  • Theoretical vulnerabilities without any proof or demonstration of the real presence of the vulnerability.
  • Findings from automated tools without providing a Proof of Concept.
  • Vulnerabilities requiring MITM, or physical access to a user’s browser, or a smartphone, or email account, as well as issues on rooted or jailbroken smartphones.
  • Missing or weak security-related HTTP headers.
  • Non-Sensitive Data Disclosure, for example server version banners.
  • Content spoofing and text injection issues without showing an attack vector/without being able to modify HTML/CSS.
  • Cross-Site Request Forgery (CSRF) on unauthenticated forms or forms with no sensitive actions.
  • Self-XSS
  • Missing email best practices (invalid, incomplete or missing SPF/DKIM/DMARC records, etc.).
  • Host header injection, unless you have confirmed that it can be exploited in a practical attack.
  • Previously known vulnerable software or libraries without a working Proof of Concept.
  • Rate limiting or brute force issues on non-authentication endpoints.
  • Missing best practices in Content Security Policy.
  • Denial Of Service
  • CSV/formula injection.
  • Clickjacking on pages with no sensitive actions.


When working with us according to this policy, you can expect us to:

  1. Extend Safe Harbor for your vulnerability research that is related to this policy
  2. Work with you to understand and validate your report, including a timely initial response to the submission
  3. Work to remediate discovered vulnerabilities in a timely manner
  4. Recognize your contribution to improving our security if you are the first to report a unique vulnerability, and your report triggers a code or configuration change.

Safe Harbour

When conducting vulnerability research according to this policy, we consider this research to be authorized, lawful, helpful to the overall security of the Internet, and conducted in good faith.

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 submit a report through our Official Channels before going any further.

Ground Rules

To encourage vulnerability research and to avoid any confusion between good-faith hacking and malicious attack, we ask that you:

  1. Play by the rules. This includes following this policy, as well as any other relevant agreements. If there is any inconsistency between this policy and any other relevant terms, the terms of this policy will prevail.
  2. Only interact with accounts or devices you own or with explicit permission from the owner.
  3. Make a good faith effort to avoid privacy violations, destruction of data, and interruption or degradation of our service.
  4. 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.
  5. Cease testing and submit a report immediately if you encounter any user data during testing, such as Personally Identifiable Information (PII), Personal Healthcare Information (PHI), credit card data, or proprietary information.
  6. Do not attempt to execute Denial of Service attacks.
  7. Social engineering (e.g. phishing, vishing, smishing) is not allowed.
  8. Report any vulnerability you’ve discovered promptly.
  9. Do not engage in extortion.
  10. Use only the Official Channels to discuss vulnerability information with us.


A researcher can share details of the vulnerability after a fix has been applied and the program owner has provided permission to disclose, OR after 90 days from submission, whichever is sooner.


We do not currently offer money or swag as rewards for reports.

But we will as a small token of appreciation, offer a place in our Security Wall of Fame for all researchers that submits a previously unknown vulnerability that triggers a code or configuration change.

How To Contact Us

Our official communication channel is maintained within our security.txt file, located here:, or you may contact us by sending an email to The issues are triaged by a Security Analyst before being escalated to the appropriate team. If you feel that the email should be encrypted, our PGP key is available at