Apna Vulnerability Disclosure Policy


As one of the fastest growing unicorns in India, Apna helps secure millions of people’s careers and future aspirations. While we secure people’s careers, you as a security researcher/bug hunter can help secure Apna. At Apna we are constantly trying to achieve 3 things: scalability, reliability and security. Even though our in-house platforms, development & security teams are all working towards an airtight security posture for our web and mobile applications, we also know and acknowledge the importance of peer review in the technical/scientific community. Hence, we take each and every vulnerability disclosure seriously & if you want to be our “extra pair of eyes” then read on!

Systems in Scope

Out of Scope

Any endpoint/asset not mentioned explicitly in scope, be it vendor endpoints, 3rd party application endpoints or internal and external endpoints belonging to Apna domain, is strictly off limits for testing purposes of any sort pertaining to any phase of the MITRE attack-framework or Lockheed Martin cyber-killchain.

Second-level testing/pivoting from one vulnerability to a subsequent vulnerability should only be done after requesting and receiving prior written permission from us.

Prohibited Testing Methodologies

  • Any type of DOS and DDOS attacks or testing with automated scanners or manually that may lead to similar conditions.
  • Brute-forcing & dictionary type of attacks
  • Social Engineering techniques
  • Attacks against the integrity of Apna users
    • Attempts to compromise user accounts
    • Any vulnerability obtained through the compromise of a user or employee account. Please create a free account to test potential vulnerabilities

Vulnerability Disclosure

Accepted Vulnerabilities

Any vulnerability, whether it is part of OWASP top 10 or SANS 25 is accepted as long as they are associated directly with the systems in scope, unique (not reported by another hunter before), not a P5 issue in Bugcrowd’s VRT/Vulnerability Rating taxonomy and not one of the following :-

  1. Cookies (apart from session cookies) not having secure flags
  2. Issues already known and in the process of remediation by the internal security and engineering teams.
  3. Multiple reports for the same vulnerability type with minor differences (only one will be accepted)
  4. Issues that are actually intended functionalities. Our development and security teams will decide on this.
  5. Accepted risks (For instance, Google doesn’t reward for open redirects. Despite being an OWASP top ten issue, they’ve decided it’s not something they care about or have additional mitigating factors in place for).
  6. IDOR references for objects that you already have permission to
  7. HTTP 404 codes/pages or other HTTP non-200 codes/pages
  8. Fingerprinting / banner disclosure on common/public services
  9. Disclosure of known public files or directories, (e.g. robots.txt)
  10. CSRF on forms that are available to anonymous users (e.g. the contact form, sign-up form)
  11. Absence of captcha and session timeouts.
  12. Error messages like stack traces or DB errors that may arise from fuzzing will not be accepted unless the researcher/hunter can present us with a POC of utilizing that info leak in an exploit.
  13. Clickjacking issues (Except on non-financial or login pages).

If you do find any vulnerabilities, that abides by the above points and conditions, but is associated with a 3rd party vendor of Apna, then immediately suspend all testing and inform us. We’ll get back to you in such cases, after taking the necessary steps to notify the 3rd party. If they allow further testing and our security team considers further testing to be necessary, we’ll inform you of the steps you need to follow then. That is of course considering you do want to proceed with further testing as well.

Official Channels

Please report security issues or direct any queries via security@apna.co, providing all relevant information. We’ll do our best to reply within 5 business days starting from the reporting date. If we fail to get back to you after this time you may send another reminder after a week from the reporting date.

Reporting Procedure

The reporting procedure is fairly simplified for ease of use. In order to make a responsible disclosure conforming to the VDP(https://apna.co/vulnerability-disclosure-policy), please fill the below form correctly and provide all the details for the fields marked by (*). When reporting for the first time this form must be filled correctly or else your report will not be accepted!

BE VERY CAREFUL WHILE FILLING THIS FORM AS YOU'LL NOT BE ABLE TO EDIT IT LATER. In case you made any mistake then please submit another form with the "Is this VD a fixed version of a previously submitted disclosure which had errors?" field marked.

In scenarios where there is any new update regarding this vulnerability (whether it is a fix bypass or it is another exploitation method or a chained-vulnerability or a new impact related to this vulnerability) you must fill a new form.

Also in scenarios where the security team contacts you personally for more details regarding the disclosure you must not fill the form again. Reply via mail directly to security@apna.co.

Form Link:-


Please keep your vulnerability reports current by sending us any new information as it becomes available. We may share your vulnerability reports with any affected partners, vendors, or open source projects. Also, the more details you provide, the easier it will be for us to triage and fix the issue (a POC video must be included in the report if possible)

Our Commitments

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

  • Respond to your report promptly, and work with you to understand and validate your report.
  • Strive to keep you informed about the progress of a vulnerability as it is processed.
  • Work to remediate discovered vulnerabilities in a timely manner, within our operational constraints.
  • Extend Safe Harbor for your vulnerability research by not pursuing legal action as long as you comply to the terms in this document.
  • Not undermine your findings or behave in any unfair manner to avoid rewarding. For instance, calling a finding intended functionality even though its not.

Our Expectations

This policy is designed to be compatible with common vulnerability disclosure good practice. It does not give you permission to act in any manner that is inconsistent with the applicable law, or which might cause us to be in breach of any legal obligations. In participating in our vulnerability disclosure program in good faith, we ask that you:

  • Play and follow the applicable law, including following this policy and any other relevant agreements. If there is any inconsistency between this policy and any other applicable terms, the terms of this policy will prevail.
  • Report any vulnerability you’ve discovered promptly. Do not go into further testing if you find any critical vulnerability that results in data loss/exfiltration, or Remote code execution of any sort, disruption of business continuity, system outage or jeopardizes the company’s reputation.
  • If you find any server-side vulnerability refrain from exploiting it in a way that may cause harm to user experience or expose our systems in unintended way (like exploiting a File upload vulnerability by uploading a full blown payload/malware to our backend systems).
  • If you get any sort of CLI access immediately stop and inform us.
  • Avoid violating the privacy of others, disrupting our systems, destroying data, and/or harming user experience.
  • Use only the Official Channels to discuss vulnerability information with us. Do not send reports to any other address than the one stated in Official Channels (especially not an address that doesn’t have @apna.co in it). If any report is leaked it may result in legal actions against the researcher.
  • Use custom headers when possible which can help identify and isolate traffic, this can help expedite the triaging of vulnerability reports.
  • Provide us a reasonable amount of time (at least 30 days from the initial report) to resolve the issue before you ask for a public disclosure. The amount of time will depend on how critical/difficult the vulnerability is to remediate.
  • Perform testing only on in-scope systems, and respect systems and activities which are out-of-scope.
  • For POC purposes always use a custom payload that you created/have full knowledge of and which will not cause any sort of harm to our systems, environment, users, data or anything related to APNA (like 3rd party vendors).
  • 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; and 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
  • You should only interact with test accounts you own or with explicit written permission from the account holder
  • Do not engage in extortion.
  • You shall not exploit a security issue you discover for any reason other than for testing purposes, and you do not conduct testing outside your own account, a test account or another account for which you have the explicit written consent of the account owner to test. (This includes demonstrating additional risk, such as the risk that the security issue could be used to compromise sensitive company data or another user's account)
  • Do not access unnecessary, excessive, or significant amounts of data or modify data in our systems or services.
  • Do not disrupt our services or systems, use high‐intensity invasive or destructive testing methods.
  • If you inadvertently access another person's data or Apna company data without authorization while investigating an issue, you must promptly cease any activity that might result in further access of user or Apna data and notify Apna what information was accessed (including a full description of the contents of the information) and then immediately delete the information from your system. Continuing to access another person's data or company data may demonstrate a lack of good faith and disqualify you from any benefit of the Safe Harbor provisions described below. You must also acknowledge the inadvertent access in any related bug bounty report you may subsequently submit. You may not share the inadvertently accessed information with anyone else.


We will maintain confidentiality and exclusivity in the disclosure and remediation process. Likewise, you shall also maintain confidentiality and shall handle information including but not limited to description of vulnerability, shared findings, report, etc. with strict confidentiality. You shall not disclose any related information to third parties without written permission from our team.

Safe Harbor

When conducting vulnerability research, according to this policy, we consider this research conducted under this policy to be:

  • Authorized concerning any applicable anti-hacking laws, and we will not initiate or support legal action against you for accidental, good-faith violations of this policy.
  • Authorized concerning any relevant anti-circumvention laws, and we will not bring a claim against you for circumvention of technology controls.
  • Exempt from restrictions in our Terms of Service (TOS) and/or Acceptable Usage Policy (AUP) that would interfere with conducting security research, and we waive those restrictions on a limited basis and
  • Lawful, helpful to the overall security of Apna, and conducted in good faith.

You are expected, as always, to comply with all applicable laws. If legal action is initiated by a third party against you, and you have complied with this policy, we will take steps to make it known that your actions were conducted in compliance with this policy in our sole discretion. However, Apna cannot authorize any activity on third-party products without their written approval or guarantee they will not pursue legal action against you. We are not, in any way, responsible for your liability from actions performed on third parties.

Bug Bounty/Rewards

If your finding(s) is/are in accordance with all the rules stated above in Accepted Vulnerabilities section and does not violate any of our expectations then we’ll be extremely thankful for your hard-work and time and reward you by showcasing your name and contribution in our Hall of Fame. If you have any blogs/want to publicly disclose the finding for educational purposes of the security community then we also will allow that once we fix the issue and notify you. In case we don’t you can simply ask!

We understand it can be a little disheartening but Apna does not have a bounty/cash reward for vulnerability disclosures as of now. We definitely do have plans for one in the future!

If at any time you have concerns or are uncertain whether your security research is consistent with this policy, please submit a report through one of our Official Channels before going any further. We understand that restricting your further testing will prevent us from understanding the full-blown impact of the vulnerability and will do our best to permit you for further testing.