Responsible Disclosure Policy


Protecting our infrastructure and the data entrusted to us by our customers is integral to what we do.

We recommend reading this disclosure policy fully before you report any vulnerabilities. This helps ensure that you understand the policy, and act in compliance with it. We value the work done by security researchers in making the Internet a safer and more secure space and have developed this policy using guidance from ISO 29147:2018.

As an organization with highest transparency, and working closely with our developer community, it should be no surprise that CredAvenue extends the same philosophy to our relationship with security researchers in good faith. CredAvenue welcomes the responsible disclosure of potential security vulnerabilities in our products, services or systems, subject to terms and conditions outlined in this policy, and in return, CredAvenue make efforts to show our appreciation to security researchers who take the time and effort to investigate and report security vulnerabilities to us according to this policy wherever we can.

We are committed to thoroughly investigating, understanding and resolving security issues across our websites in collaboration with the security community.

In Scope

Any of the CredAvenue services iOS, Android or Web apps, which process, store, transfer or use in one way or personal or sensitive personal information, such as customer data and authentication data.

The fully qualified domain names of the systems within scope are listed below. Subdomains not explicitly listed are not in-scope.

Products and services in scope:

Together referred to as Platform.

Cloud, including:

Webhook and integration system
Any publicly exposed infrastructure elements that support CredAvenue product or organizational operations, e.g. public S3 buckets.

The policy applies to everyone, including for example the CredAvenue staff, third party suppliers and general users of the CredAvenue services.

Out of Scope
All systems not explicitly mentioned as in-scope.
Volumetric vulnerabilities are not in scope - meaning that simply overwhelming a service with a high volume of requests is not in scope.
Reports of non-exploitable vulnerabilities, or reports indicating that our services do not fully align with “best practice”, for example missing security headers, are not in scope.
TLS configuration weaknesses, for example “weak” cipher suite support or the presence of TLS1.0 support, are not in scope.
Third party business applications leveraged by CredAvenue: this includes the CredAvenue blog, Careers Site, and others.
Hardware vulnerabilities that require physical device access to exploit.
Staging servers, unless their vulnerabilities impact production environments.
Github repositories that are not part of the organization.
Bug Bounty

Unfortunately, due to CredAvenue funding structure, it is not currently possible for us to offer a paid bug bounty programme. We will, however, make efforts to show our appreciation to security researchers who take the time and effort to investigate and report security vulnerabilities to us according to this policy wherever we can.

Testing for Vulnerabilities

If you want to actively test our systems for vulnerabilities, you must:

Only test systems that are in scope of this policy.
Use a test, or other non-production, environment if it is available to you.
Only test vulnerabilities using your own accounts, or accounts that you have permission to test with.

And you must not:

Perform testing likely to provide you with access to someone else’s data.
Perform testing likely to delete, destroy or corrupt anyone else’s data.
Perform testing likely to affect other users e.g. denial of service, brute-force attacks and spamming.
Use automated scanners/fuzzers.
Test systems not-in-scope of this policy.
Rules and Legalities to be followed

CredAvenue will not engage in legal action against individuals or entities that submit vulnerability reports that cover in scope of products and services (as defined above), through the approved channels (defined below).

Furthermore, CredAvenue agrees not to pursue legal action against individuals or entities that adhere to the following rules of engagement when identifying and submitting vulnerabilities unless we are compelled to do so by a regulatory authority, other third party, or applicable laws:

Must not perform:

Any action that will negatively affect CredAvenue, its subsidiaries or agents.
Retaining any personally identifiable information discovered, in any medium. Any personally identifiable information discovered must be permanently destroyed or deleted from your device and storage.
Disclosing any personally identifiable information discovered to any third party.
Destruction or corruption of data, information or infrastructure, including any attempt to do so.
Any exploitation actions, including accessing or attempting to access CredAvenue’ s data or information, beyond what is required for the initial “Proof of Vulnerability.” This means your actions to obtain and validate the Proof of Vulnerability must stop immediately after initial access to the data or a system.
Attacks on third-party services.
Denial of Service attacks or Distributed Denial of Services attacks.
Any attempt to gain physical access to CredAvenue property or data centres.
Use of assets that you do not own or are not authorised or licensed to use when discovering a vulnerability.
Violation of any laws or agreements in the course of discovering or reporting any vulnerability.
Violate the privacy of the CredAvenue users, staff, contractors, services or systems. For example, by sharing, redistributing and/or not properly securing data retrieved from our systems or services.
Communicate any vulnerabilities or associated details using methods not described in this policy.
Use high-intensity invasive or destructive technical security scanning tools to find vulnerabilities.
Access unnecessary amounts of data. For example, 2 or 3 records is enough to demonstrate most vulnerabilities, such as an enumeration or direct object reference vulnerability.
Security researchers are responsible for ensuring they adhere to local laws and legislation at all times.
Do not use social engineering to gain access to a system.
Do not place a backdoor in an information system in order to then demonstrate the vulnerability, as this can lead to further damage and involves unnecessary security risks.
Do not try to repeatedly access the system and do not share the access obtained with others.
Do not use any so-called 'brute force' to gain access to systems. After all, that is not really about vulnerability but about repeatedly trying passwords.
Require financial compensation in order to disclose any vulnerabilities outside of a declared policy (such as holding an organisation to ransom).

We ask you to delete securely any and all data retrieved during your research as soon as it is no longer required or within 1 month of the vulnerability being resolved, whichever occurs first.

Disclosure Guidelines for Vulnerabilities in third Party Software:

When a security vulnerability in some third party product is discovered by you the following disclosure guideline should apply:

The first priority is our users.
Therefore for any vulnerability discovered in your dependency we will make sure our users are not affected.
For the following disclosure process our priority is to get the reported vulnerability fixed.
If such third party acknowledges the vulnerability and is working on a patch, we will keep vulnerability details confidential until the issue is fixed.
If possible, we will verify the fix before it is being published
In special cases we might release details without a fix to make the public aware. This might, for instance, be the case when a vulnerability is being actively exploited
We aim for fixing this as per our third party agreed timelines
We will treat this as a soft deadline and help to meet the deadline when reporting.
We will try to coordinate with the affected third party to have a patch released before we release an advisory.
Resulting advisories will be published in the disclosures repository.
Reporting Template

Vulnerability reports should be submitted to the CredAvenue security team via email, to the address

Full Name of the Individual:

Mobile Number:

Link to their professional handles (LinkedIn, Twitter, Facebook, Github, etc)

Bug Information:

Vulnerability Name:

Affected areas:


Detailed POC with the below details:

The IP address from which you performed the testing so that we can view logs related to your testing.
Clearly identifying your traffic, for example by including a unique custom HTTP header such as X-CAPL-CVD: {youremail@address}
Disclosing any personally identifiable information discovered to any third party.
If you are attempting to demonstrate root level access, please use CAPL /root/{uniqueid}

Preference, Prioritization and Acceptance CriteriaIn

order to obtain the most value from this program, for both CredAvenue and the participating security researcher, we strongly advise that, and will give priority to disclosures which include:

Reports that are well written and submitted in English where possible.
Reports that include proof of concept code that permit CredAvenue to better triage the issue.
Reports that include details of how the vulnerability was identified, a suggested impact rating, and any potential remediations you might suggest.
Reports that are more than just output from automated testing tools, and scans.

If you follow these guidelines, you can expect the following from CredAvenue:

After submission, if your issue is accepted, you will hear from us within 72 hours.

If you do not hear from us within 72 hours, it means your issue has not been accepted this time.

The team will triage the reported vulnerability and respond as soon as possible to let you know whether further information is required, whether the vulnerability is in or out of scope, or is a duplicate report. If remediation work is necessary, it is assigned to the appropriate CredAvenue teams or supplier(s).

Priority for bug fixes or mitigations is assessed by looking at the impact severity and exploit complexity. Vulnerability reports might take some time to triage or address. You are welcome to enquire on the status of the process but should avoid doing so more than once every 14 days. The reason is to allow our teams to focus on the reports as much as possible.

When the reported vulnerability is resolved, or remediation work is scheduled, the Vulnerability Disclosure Team will notify you, and invite you to confirm that the solution covers the vulnerability adequately.

What not to be reported via this program?

The disclosure point is not intended for:

Submitting complaints about services
Making fraud reports and/or suspicions of fraud reports from false mail or phishing e-mails
Reporting viruses
Submitting complaints or questions about the availability of the website
Legal Note

Your participation in the Program will not violate any law applicable to you or disrupt or compromise any data that is not your own.

You are solely responsible for any applicable taxes, withholding or otherwise, arising from or relating to your participation in the Program, including from any bounty payments when we run bug bounty programs in the future.

CredAvenue reserves the right to terminate or discontinue the Program at its discretion.