This website uses cookies to ensure you get the best experience. More info
This website uses cookies to ensure you get the best experience. More info
This website uses cookies to ensure you get the best experience. More info
xto10x-logo
xto10x-logo
xto10x-logo

Responsible Disclosure Policy

Introduction

xto10x is committed to ensuring the safety and security of our customers and employees and their information. We aim to foster an environment of trust, and an open partnership with the security community, and we recognize the importance of vulnerability disclosures and whistleblowers in continuing to ensure safety and security for all of our customers, employees and company. We have developed this policy to both reflect our corporate values and to uphold our legal responsibility to good-faith security researchers that are providing us with their expertise and whistleblowers who add an extra layer of security to our infrastructure.

Purpose

The purpose of this policy is to allow for the reporting and disclosure of vulnerabilities discovered by external entities, and anonymous reporting of information security policy violations by internal entities.

Scope

xto10x's Responsible Disclosure Policy covers applies to xto10x's core platforms, website (xto10x.com), products and its information security infrastructure, and to internal and external employees or third parties.

How to Submit a Vulnerability

To submit a vulnerability report to xto10x's Security Team, please utilise the following email security@xto10x.com.

Preference, Prioritisation, and Acceptance Criteria

We will use the following criteria to prioritise and triage submissions. What we would like to see from you:

  • Well-written reports in English will have a higher probability of resolution.

  • Reports that include proof-of-concept code equip us to better triage.

  • Reports that include only crash dumps or other automated tool output may receive lower priority.

  • Reports that include products not on the initial scope list may receive lower priority.

  • Please include how you found the bug, the impact, and any potential remediation. You do not exploit a security vulnerability that you discover for any reason. (This includes demonstrating additional risk, such as attempted compromise of sensitive company data or probing for additional issues. )

  • Violating any laws or breaching any agreements in order to discover vulnerabilities.

  • You do not publicly disclose details of a security vulnerability that you've reported without xto10x's permission.

What can you expect from xto10x

  • A timely response to your email (within 2 business days).

  • After triage, we will send an expected timeline and commit to being as transparent as possible about the remediation timeline as well as on issues or challenges that may extend it.

  • An open dialog to discuss issues.

  • Notification when the vulnerability analysis has completed each stage of our review.

  • If you want, publicly acknowledge your contribution

If we are unable to resolve communication issues or other problems, xto10x may bring in a neutral third party to assist in determining how best to handle the vulnerability.

Programme terms

We recognise security researchers who help us to keep users safe by reporting vulnerabilities in our services. Recognition for such reports are entirely at xto10x's discretion, based on risk, impact and other factors.

Qualifying Vulnerabilities

Any design or implementation issue that is reproducible and substantially affects the security of xto10x systems users is likely to be in scope for the program. Common examples include: Injections

  • Cross Site Scripting (XSS)

  • Cross Site Request Forgery (CSRF)

  • Remote Code Execution (RCE)

  • Authentication/Authorisation flaws

  • Domain take-over vulnerabilities

  • Able to take-over other xto10x user accounts (while testing, use your own another test account to validate)

  • Any vulnerability that can affect the xto10x brand, user data and financial transactions

Exclusions

The following bugs are unlikely to be eligible:

  • Vulnerabilities found through automated testing

  • "Scanner output" or scanner-generated reports

  • Publicly released CVE’s or 0-days in internet software within 90 days of their disclosure

  • "Advisory" or "Informational" reports that do not include any xto10x testing or context

  • Vulnerabilities requiring MITM or physical access to the victim’s unlocked device.

  • Denial of Service attacks

    • SPF and DKIM issues
    • Content injection
    • Hyperlink injection in emails
    • IDN homograph attacks
    • RTL Ambiguity
  • Content Spoofing

  • Vulnerabilities relating to Password Policy

  • Full-Path Disclosure on any property

  • Version number information disclosure

  • Third-party applications on the xto10x Application directory (identified by the existence of a "Report this app" link on the app's page). Please report vulnerabilities with these services to the creator of that specific application.

  • Clickjacking on pre-authenticated pages, or the non-existence of X-Frame-Options, or other non-exploitable clickjacking vulnerabilities

  • CSRF-able actions that do not require authentication (or a session) to exploit

  • Reports related to the following security-related headers

  • Strict Transport Security (HSTS)
  • XSS mitigation headers (X-Content-Type and X-XSS-Protection)
  • X-Content-Type-Options
  • Content Security Policy (CSP) settings (excluding nosniff in an exploitable scenario)

  • Bugs that do not represent any security risk Security bugs in third-party applications or services built on the xto10x API - please report them to the third party that built the application or service

  • Security bugs in software related to an acquisition for a period of 90 days following any public announcement

  • HTTP TRACE or OPTIONS methods enabled Non-sensitive (i.e., non-session) cookies missing the Secure or HttpOnly flags

  • Tap jacking

  • Mobile client issues require a rooted device and/or outdated OS version or SSL pinning issues.

  • Subdomain takeovers without supporting evidence

  • Missing best practices in SSL/TLS configuration.

  • The Vulnerabilities that cannot be used to exploit other users or xto10x -- e.g., self-XSS or having a user paste JavaScript into the browser console

  • Open ports without an accompanying proof-of-concept demonstrating vulnerability

  • Vulnerabilities in the whitehat report form

Acknowledgements

We do not have a bounty/cash reward program for such disclosures, but we express our gratitude for your contribution in different ways. For genuine ethical disclosures, we would be glad to publicly acknowledge your contribution in this section on our website. Of course, this will be done if you want a public acknowledgement.

Hall Of Fame

We thank the following people for finding & responsibly disclosing the security vulnerabilities.

PRODUCTS

PeopleCues

SERVICES



xto10x-logo

Copyright © 2022 - xto10x Technologies

Responsible Disclosure Policy

Introduction

xto10x is committed to ensuring the safety and security of our customers and employees and their information. We aim to foster an environment of trust, and an open partnership with the security community, and we recognize the importance of vulnerability disclosures and whistleblowers in continuing to ensure safety and security for all of our customers, employees and company. We have developed this policy to both reflect our corporate values and to uphold our legal responsibility to good-faith security researchers that are providing us with their expertise and whistleblowers who add an extra layer of security to our infrastructure.

Purpose

The purpose of this policy is to allow for the reporting and disclosure of vulnerabilities discovered by external entities, and anonymous reporting of information security policy violations by internal entities.

Scope

xto10x's Responsible Disclosure Policy covers applies to xto10x's core platforms, website (xto10x.com), products and its information security infrastructure, and to internal and external employees or third parties.

How to Submit a Vulnerability

To submit a vulnerability report to xto10x's Security Team, please utilise the following email security@xto10x.com.

Preference, Prioritisation, and Acceptance Criteria

We will use the following criteria to prioritise and triage submissions. What we would like to see from you:

  • Well-written reports in English will have a higher probability of resolution.

  • Reports that include proof-of-concept code equip us to better triage.

  • Reports that include only crash dumps or other automated tool output may receive lower priority.

  • Reports that include products not on the initial scope list may receive lower priority.

  • Please include how you found the bug, the impact, and any potential remediation. You do not exploit a security vulnerability that you discover for any reason. (This includes demonstrating additional risk, such as attempted compromise of sensitive company data or probing for additional issues. )

  • Violating any laws or breaching any agreements in order to discover vulnerabilities.

  • You do not publicly disclose details of a security vulnerability that you've reported without xto10x's permission.

What can you expect from xto10x

  • A timely response to your email (within 2 business days).

  • After triage, we will send an expected timeline and commit to being as transparent as possible about the remediation timeline as well as on issues or challenges that may extend it.

  • An open dialog to discuss issues.

  • Notification when the vulnerability analysis has completed each stage of our review.

  • If you want, publicly acknowledge your contribution

If we are unable to resolve communication issues or other problems, xto10x may bring in a neutral third party to assist in determining how best to handle the vulnerability.

Programme terms

We recognise security researchers who help us to keep users safe by reporting vulnerabilities in our services. Recognition for such reports are entirely at xto10x's discretion, based on risk, impact and other factors.

Qualifying Vulnerabilities

Any design or implementation issue that is reproducible and substantially affects the security of xto10x systems users is likely to be in scope for the program. Common examples include: Injections

  • Cross Site Scripting (XSS)

  • Cross Site Request Forgery (CSRF)

  • Remote Code Execution (RCE)

  • Authentication/Authorisation flaws

  • Domain take-over vulnerabilities

  • Able to take-over other xto10x user accounts (while testing, use your own another test account to validate)

  • Any vulnerability that can affect the xto10x brand, user data and financial transactions

Exclusions

The following bugs are unlikely to be eligible:

  • Vulnerabilities found through automated testing

  • "Scanner output" or scanner-generated reports

  • Publicly released CVE’s or 0-days in internet software within 90 days of their disclosure

  • "Advisory" or "Informational" reports that do not include any xto10x testing or context

  • Vulnerabilities requiring MITM or physical access to the victim’s unlocked device.

  • Denial of Service attacks

    • SPF and DKIM issues
    • Content injection
    • Hyperlink injection in emails
    • IDN homograph attacks
    • RTL Ambiguity
  • Content Spoofing

  • Vulnerabilities relating to Password Policy

  • Full-Path Disclosure on any property

  • Version number information disclosure

  • Third-party applications on the xto10x Application directory (identified by the existence of a "Report this app" link on the app's page). Please report vulnerabilities with these services to the creator of that specific application.

  • Clickjacking on pre-authenticated pages, or the non-existence of X-Frame-Options, or other non-exploitable clickjacking vulnerabilities

  • CSRF-able actions that do not require authentication (or a session) to exploit

  • Reports related to the following security-related headers

  • Strict Transport Security (HSTS)
  • XSS mitigation headers (X-Content-Type and X-XSS-Protection)
  • X-Content-Type-Options
  • Content Security Policy (CSP) settings (excluding nosniff in an exploitable scenario)

  • Bugs that do not represent any security risk Security bugs in third-party applications or services built on the xto10x API - please report them to the third party that built the application or service

  • Security bugs in software related to an acquisition for a period of 90 days following any public announcement

  • HTTP TRACE or OPTIONS methods enabled Non-sensitive (i.e., non-session) cookies missing the Secure or HttpOnly flags

  • Tap jacking

  • Mobile client issues require a rooted device and/or outdated OS version or SSL pinning issues.

  • Subdomain takeovers without supporting evidence

  • Missing best practices in SSL/TLS configuration.

  • The Vulnerabilities that cannot be used to exploit other users or xto10x -- e.g., self-XSS or having a user paste JavaScript into the browser console

  • Open ports without an accompanying proof-of-concept demonstrating vulnerability

  • Vulnerabilities in the whitehat report form

Acknowledgements

We do not have a bounty/cash reward program for such disclosures, but we express our gratitude for your contribution in different ways. For genuine ethical disclosures, we would be glad to publicly acknowledge your contribution in this section on our website. Of course, this will be done if you want a public acknowledgement.

Hall Of Fame

We thank the following people for finding & responsibly disclosing the security vulnerabilities.

PRODUCTS

PeopleCues

SERVICES



xto10x-logo

Copyright © 2022 - xto10x Technologies

PRODUCTS

xto10x-logo

Copyright © 2022 - xto10x Technologies