Skip to Content

Begin Main Content

Responsible Vulnerability Disclosure

Tally is committed to ensuring the security of its users and the public by protecting their information from unwanted disclosure. The Vulnerability Disclosure policy is intended to provide independent researchers with defined guidelines for conducting vulnerability research, and establishes what systems are in scope. This policy provides researchers with guidance on how to responsibly identify and submit discovered vulnerabilities to Tally.

Tally acknowledges the value that independent researchers bring to the entire Internet community. Tally’s Security Team in conjunction with independent researchers can help identify potential vulnerabilities in Tally’s ecosystem to ensure that customers are receiving the highest quality products and services.

Lastly, our Security Team has developed the Vulnerability Disclosure policy to reflect Tally’s values and uphold security researchers to the highest-level of responsibility in their reporting.


The following guidelines have been established by Tally’s Security Team to promote a secure and collaborative environment for Tally employees and independent researchers alike. We kindly ask that independent researchers:

  • Email Tally’s Security Team at following the discovery of a real or potential security issue.

  • Once an independent researcher establishes that a vulnerability exists or encounters any sensitive data (including personally identifiable information, financial information, proprietary information or trade secrets), all testing must stop, and Tally’s Security Team should be contacted immediately.

  • Do not engage in any activity that violates (a) federal or state laws or regulations, or (b) the laws or regulations of any country where (i) data, assets or systems reside, (ii) data or traffic is routed or (iii) the researcher is conducting research activity.

  • Only interact with accounts you own, or with accounts for which you have the express written permission of the account owner.

  • Do not intentionally access non-public Tally data any more than is necessary to demonstrate a vulnerability.

  • Refrain from public disclosure of any identified vulnerability prior to receiving written consent from Tally’s Security Team.

  • Avoid privacy violations, degradation of user experience, disruption to production systems, and destruction or manipulation of data including actions that could be perceived as DoS/DDoS, Brute Force, or automated scans against Tally platforms and services.

  • Do not permanently modify, destroy, or delete data from Tally systems.

  • Tally values confidentiality, and we ask that independent researchers never share confidential information, including any information acquired during our interactions, with any 3rd party.

  • Tally does not operate any form of paid Vulnerability Disclosure Program, be it public, private, or invite-only and will not award any form of compensation including but not limited to bug bounties, rewards, gift cards, etc. for confirmed reports. Vulnerability reports are made on a strictly voluntary basis and Tally will not negotiate for any form of compensation in the face of duress or threat including but not limited to the release of the vulnerability or any exposed data to the public.


If you make a good faith effort to comply with Tally’s Vulnerability Disclosure policy during your security research, we will consider your research to be authorized. We will work with you to understand and resolve the issue quickly, and Tally will not recommend or pursue legal action related to your research.

When conducting research, security researchers are encouraged to include the X-Tally-Vuln-Research HTTP header on requests when possible, to assist Tally’s Security Team in tracking and addressing potential vulnerabilities. The use of this identifying HTTP header will also help to distinguish legitimate research activities from malicious attacks. For example, a researcher could include the following header in their request:

X-Tally-Vuln-Research: security@meettally. com

This will help Tally's Security Team quickly identify and respond to any potential vulnerabilities discovered by researchers, while also ensuring that our systems are protected from malicious attacks.


Tally’s Vulnerability Disclosure policy enumerates a set of systems and services that are considered in-scope and are pre-authorized by Tally’s Vulnerability Disclosure Policy. Anything not included in this list is considered out-of-scope and requires pre-authorization prior to commencing research. If you are not sure whether a system or endpoint is in scope or if you would like to get authorization to work on an item not in scope, contact us at before commencing research.


Domainapi.meettally.comAPI stacks powering Tally's mobile applications.
Domainapp.meettally.comWeb-based onboarding application
CDNcdn.meettally.comAmazon CloudFront CDN, scope is limited to content and configuration issues.
Domainwww.meettally.comCorporate website and blog platform.
Android: Play Storecom.meettallyAndroid Tally app. Scope is limited to the as-delivered app from the US Play Store.
iOS: App Storecom.meettally.tallyappiOS Tally app. Scope is limited to the as-delivered app from the US App Store.

Out of scope

In addition to the guidelines above, the following are explicitly considered out of scope and are not governed by this Vulnerability Disclosure Policy:

  • Reports from automated scanning tools.  Any such report must include a working proof of concept against an in-scope property demonstrating that the vulnerability is both present and poses a verifiable vulnerability within that property.

  • Clickjacking reports on pages with no sensitive actions.

  • Previously known vulnerable libraries without a working proof of concept against an in-scope Tally property.

  • Any activity that could lead to the disruption of Tally services including but not limited to DoS/DDoS.

  • Social engineering of any kind, including but not limited to Tally employees and their families, contractors, partners, investors, marketers and social media, and customers.

  • Physical testing or tampering of Tally’s real-world facilities including but not limited to offices, data centers, and employee devices.

  • Missing best practices or hygiene issues in SSL / TLS configurations.

  • Missing best practices or hygiene issues in SPF / DMARC / email configuration.

  • Missing best practices or hygiene issues in Cookie flags or security-related headers without a working proof of concept against an in-scope Tally property demonstrating the vulnerability.

  • Any vulnerability that is dependent on use of an outdated or unsupported browser or platform.

  • Version disclosures, detailed error messages, any any other findings whose only security impact is classified as ‘attacker reconnaissance’.

  • Other security concerns or missing best practices without a proof of concept that the concerns lead to a vulnerability on an in-scope Tally property.

Any services not listed above, such as any connected services, are excluded from scope and are not authorized for testing.

We ask that active research and testing only be conducted on the systems and services covered by the scope of this policy.


Tally’s Security Team accepts vulnerability reports via email at

Our commitment

When an independent researcher chooses to share a potential vulnerability with us, we commit to coordinating with them as openly and as quickly as possible.

  • Within 5 business days, our Security Team will acknowledge that a report has been received.

  • We will maintain an open dialog to discuss issues, seek clarifications and assess the vulnerability report.

  • We will confirm the existence of the vulnerability to you and be transparent in what steps we are taking as part of remediation efforts.

  • We will act as a liaison between Tally teams and the researcher to remediate any confirmed and accepted issues.

  • We will provide a final disposition for resolved issues.

Tally recommends the use of a public key to both verify the integrity of messages sent by the Security Team and to encrypt any messages containing sensitive information or details about a potential vulnerability. This key may be identified with fingerprint 48C3 B58A 0C79 7499 FC32 478E 20AE 217F 4A87 8DBE located across many common public key servers, for example: