Responsible Disclosure Policy

1. Our Commitment

MAGDOX Private Limited (Magdox, we, us) treats the security of our products, including FDIE, as core to how we operate. We know that independent security researchers often find things our own team misses, and we want to make it easy and safe for you to tell us about them.

This policy explains how to report a vulnerability to us, what we ask of you while you do, and what you can expect from us once you have.

2. No Monetary Rewards

Magdox does not currently run a paid bug bounty program. We are not able to offer cash rewards for vulnerability reports at this time.

What we do offer is public recognition. After confirmation and coordinated remediation, researchers who choose public attribution for a valid, previously unreported vulnerability are credited on our Hall of Fame page, with their name or handle and a short description of what they found, unless they would rather stay anonymous.

We may introduce paid rewards in the future. If we do, this policy will be updated first.

3. Scope

In scope:

• https://fdie.dev and every subdomain under *.fdie.dev that we operate. The FDIE product application and its REST API are not yet publicly reachable; this section will name them when they are. Test only accounts and data you own or are expressly authorized to test; a shared demo login does not authorize testing other users’ data. A hostname alone does not authorize testing third-party infrastructure.

Out of scope:

• mail.fdie.dev. This subdomain is part of our Zoho Mail setup and is operated by Zoho, not by us. Any vulnerability there belongs to Zoho’s own security team, not ours, and we cannot offer safe harbor for testing infrastructure we do not control.
• Any third-party service we use but do not operate ourselves, including our CRM, support desk and scheduling provider (Zoho), our DNS and edge provider (Cloudflare), our video meeting provider (Zoom) and our cloud hosting provider (Oracle Cloud Infrastructure). Please report issues with those services directly to the company that runs them.
• Physical security, social engineering aimed at our employees, and denial-of-service testing of any kind.

4. How to Report & Response Targets

Email [email protected] with as much detail as you can give us. A report that lets us reproduce the issue on the first try gets fixed faster than one that does not.

Please include:

• What the vulnerability is and what kind of issue it is (for example, an authentication bypass or a stored XSS).
• Which URL, endpoint, or feature is affected.
• Step by step instructions to reproduce it.
• Proof of concept, if you have one. A screenshot or short screen recording is fine.
• What the impact is, in your own words.
• Your name or handle, and whether you would like to be credited publicly if we confirm the issue.

Response & Resolution Targets

We read every report ourselves. We use the following best-effort response and remediation targets; these are not a contractual uptime or support SLA:

• Initial Acknowledgement: within 3 business days of receipt.
• Triage & Confirmation: within 5 business days of receipt.
• Target Resolution Timeframes from confirmation (informed by CVSS and actual impact):
  • Critical (CVSS 9.0 to 10.0): 14 business days
  • High (CVSS 7.0 to 8.9): 30 business days
  • Medium (CVSS 4.0 to 6.9): 60 business days
  • Low (CVSS 0.1 to 3.9): 90 business days

We will keep you informed on progress at each stage of remediation.

5. Ground Rules & Safe Harbor

We ask that you:

• Only test against accounts and data you own, or that you have explicit permission to test against.
• Make a good faith effort to avoid privacy violations, data destruction, and any interruption or degradation of our service.
• Avoid social engineering of any kind, including phishing our staff or customers.
• Follow the coordinated disclosure window in Section 8. Report accidental access to other users’ data and stop that access immediately; do not download further data to demonstrate impact.
• Send us one report per vulnerability, unless several smaller issues need to be reported together to show their combined impact.
• Avoid running aggressive, high-volume automated scanners against our production systems. Manual testing, or a scanner configured to be gentle with rate limits, is fine.

If you follow these rules in good faith, we consider your research authorised. We will not initiate civil action against you, will not make a complaint or report against you under the Information Technology Act, 2000 (including sections 43 and 66) or any equivalent law, and will not suspend your account because of it. If a third party takes legal action against you for activity that was consistent with this policy, we will do what we can to make clear to them that your work was authorised. This safe harbor is our own commitment; it cannot bind a court or a public authority, so please stay within the rules above.

6. What We Prioritize

We triage every report by real-world impact so the most serious issues get looked at first. The table below shows how we categorize severity. It is not exhaustive; we apply judgment on a case-by-case basis.

Lower-priority issues, such as missing security headers on their own, or something only usable through clickjacking, are still worth reporting, but will usually not be treated as urgent.

7. What Is Not In Scope for Reporting

We generally do not need reports about:

• Rate limiting, unless you can show it leads to real data loss or a real business impact.
• Open redirects on their own.
• Clickjacking without a demonstrated security impact; impactful cases remain reportable.
• Missing SPF, DKIM, or DMARC hardening beyond what we already publish.
• Username or email enumeration on public forms.
• Self-XSS that requires the victim to paste something into their own browser console.
• Descriptive error messages or stack traces that do not expose secrets or user data.
• Best-practice suggestions that do not themselves put data or accounts at risk, such as a missing HSTS preload flag.
• A public CVE or version banner without evidence that an FDIE-operated deployment is affected. A recent upstream patch does not exclude a reproducible issue in our deployment.

If you are not sure whether something counts, send it anyway. We would rather see a report that turns out to be low impact than miss a real one.

8. Confidentiality

If you report a vulnerability to us, you may come across information that is not public. This could include details about how our systems are built, our product roadmap, or other non-public technical or business information.

We ask for coordinated disclosure, not silence:

• Keep non-public information about our systems, customers and roadmap confidential, and use it only to help us fix the issue you found.
• Do not publish details or a working proof of concept for a vulnerability until we have fixed it, or until 90 days have passed since you reported it, whichever comes first. If more time is needed, we may request a mutually agreed extension; it is not automatic and does not override a mandatory reporting obligation.
• Delete any customer data or non-public material you may have encountered once your report is confirmed, and tell us that you have.

Your own write-up is yours. Once the disclosure window above has passed you are free to publish it, present it, and credit yourself for it; we only ask that you do not include customer data or non-public information that was not needed to explain the issue.

The safe harbor in Section 5 does not cover exploiting a vulnerability beyond what is needed to demonstrate it, selling non-public access or customer data, or using it to access data that is not yours. Coordinated publication permitted by this Section is not excluded merely because it describes the vulnerability. In those cases we reserve every remedy available to us, including a court order, because the harm involved cannot be repaired with money.

9. Scope of Our Commitments

A report does not guarantee a monetary reward, a particular remediation date or disclosure of confidential investigation details. We aim to explain the outcome and keep you informed. This does not cancel the safe harbor above or any applicable legal notification or remediation duty.

10. Changes to This Policy

We may update this policy from time to time as our program matures, including if we introduce paid rewards later. We will post the update here with a new effective date.

11. Governing Law

This policy is governed by the laws of India, including the Information Technology Act, 2000. Any dispute arising from it will be handled in the competent courts of West Bengal, India.

Thank you for taking the time to help keep Magdox and our customers safe.