Acceptable Hacking Policy

Frenxi OÜ (“us”, “we”, or “our”) operates (hereinafter referred to as “Service”).

Our Acceptable Hacking Policy governs which reports are eligible to be submitted on


We have an ambitious mission: allow any security researcher (referred to as “Hacker” or “Reporter”) to safely submit security reports to any legal entity (referred to as “Company”, “Recipient” or “Receiver”). In order to do that and protect all the parties, we need to have an Acceptable Hacking Policy and deeply scrutinize every report to ensure it meets our ethical criteria.

Rules of Engagement

Your report submission is voluntary and subject to the following:

  • You must not disclose the vulnerability to anyone else while we process your report.
  • You must not access, download, or delete users’ data that are not your own.
  • You must not degrade, interrupt, or deny services.
  • If you are performing research, you must use your own accounts and not interact with other users’ accounts or data.
  • You must avoid phishing, scamming, and social engineering.
  • Vulnerabilities must be detected in non-intrusive ways.
  • No exploitation has to be performed on the target system.
  • Your testing must not violate any applicable laws or regulations.

Out-of-Scope Vulnerabilities

  • Account squatting by preventing users from registering with certain email addresses
  • Attacks requiring MITM or physical access to a user’s device
  • Best practice reports without a valid exploit (e.g., use of “weak” TLS ciphers)
  • Clickjacking on pages with no sensitive actions
  • Comma Separated Values (CSV) injection without demonstrating a vulnerability
  • 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
  • Server-level Denial of service
  • Disclosure of server or software version numbers
  • Issues that are premised on unlikely user interaction
  • Missing best practices in Content Security Policy
  • Missing best practices in SSL/TLS configuration
  • Missing email best practices (invalid, incomplete or missing SPF/DKIM/DMARC records, etc.)
  • Missing HttpOnly or Secure flags on cookies
  • Open redirect – unless an additional security impact can be demonstrated
  • Perceived security weaknesses without concrete evidence of the ability to compromise a user (e.g., missing rate limits, missing headers, etc.)
  • Previously known vulnerable libraries without a working Proof-of-Concept
  • Rate limiting or bruteforce issues on non-authentication endpoints

The list above is not exhaustive but provides many good examples if the type of vulnerabilities we will not handle.


We operate following a “quantifiable impact” criteria. Given the condition that a vulnerability is “ethically sourced”, it also needs to be “impactful” to meet our eligibility criteria. This is because there is no obligation for the recipient of the report to pay any fee.

We process every report with no guarantee of monetary compensation, so we need to prioritize and limit our activity to the most impactful report.

We reserve to ourselves the right to accept or reject a report at our sole discretion, based on our internal evaluation.


Remember that submitting a report via OpenCIRT is voluntary, and no compensation is due in any circumstance unless the receiver of the final report spontaneously decides to award a bounty. In that case, the reward will be split according to our current fees.

Last updated: December 28th, 2022