Vulnerability Disclosure Policy

Effective Date: 25 March 2026  |  Last Updated: 25 March 2026

SecNinjaz is committed to the security of our platform, our users' data, and the broader internet ecosystem. We welcome and encourage responsible security research on our systems. This Vulnerability Disclosure Policy (VDP) describes how to report security vulnerabilities found in SecNinjaz systems and what you can expect from us.

1. Scope

1.1 In Scope

The following assets are in scope for responsible security research:

Asset Type
secninjaz.com Web application
*.secninjaz.com Subdomains
All SecNinjaz tools and services (frontend & API) Web application & API

1.2 Out of Scope

The following are out of scope and must not be tested:

  • Third-party services we use (email providers, cloud infrastructure, AI providers)
  • Physical security of offices or data centres
  • Social engineering attacks against SecNinjaz employees or contractors
  • Denial-of-service (DoS/DDoS) attacks
  • Automated mass vulnerability scanning without prior coordination
  • Any testing that could degrade service for other users
  • Customer domains scanned through our vulnerability assessment tool

2. How to Report

2.1 Reporting Channel

Send vulnerability reports to: security@secninjaz.com

2.2 What to Include

Please include the following in your report:

  1. Description — Clear description of the vulnerability.
  2. Impact — What an attacker could achieve by exploiting this vulnerability.
  3. Steps to Reproduce — Detailed, step-by-step reproduction instructions.
  4. Proof of Concept — Screenshots, video recordings, HTTP request/response logs, or scripts (non-destructive).
  5. Affected Asset — The specific URL, endpoint, or component affected.
  6. Severity Assessment — Your assessment of severity (Critical / High / Medium / Low / Informational).
  7. Suggested Fix (optional) — If you have a recommendation for remediation.

2.3 Encryption

For sensitive reports, you may encrypt your email using our PGP key:

  • PGP Key: Available at pgp-key.asc
  • Fingerprint: 67BE 363E 447C BF21 23E6 2FDC 8AC5 21C4 B947 3D5B

2.4 Machine-Readable Security Policy (RFC 9116)

We publish a security.txt file in accordance with RFC 9116:

  • URL: https://secninjaz.com/.well-known/security.txt
  • Contains our security contact, PGP key link, preferred languages, and this policy's canonical URL.

3. What We Commit To

Commitment Timeline
Acknowledgement Within 48 hours of receiving your report
Initial Assessment Within 5 business days
Status Update At least every 10 business days until resolution
Resolution Target Critical: 7 days; High: 14 days; Medium: 30 days; Low: 60 days
Disclosure Coordination We will coordinate with you before any public disclosure

4. Safe Harbour

If you conduct security research in compliance with this policy, we commit to:

  1. No legal action — We will not pursue civil or criminal legal action against you for security research conducted in accordance with this policy.
  2. Good faith interpretation — We will consider your research to be authorized and will not pursue action under the Information Technology Act, 2000 (Sections 43, 65, 66) provided you comply with this policy.
  3. Protection from third parties — If a third party initiates legal action against you for research conducted in compliance with this policy, we will make it known that your actions were authorized under this VDP.

This safe harbour applies only if you:

  • Act in good faith
  • Comply with the rules of engagement (Section 5)
  • Report findings promptly to us
  • Do not publicly disclose findings before we have had a reasonable opportunity to remediate

5. Rules of Engagement

When conducting security research on our systems, you must:

  1. Minimize harm — Avoid actions that could impact service availability, corrupt data, or affect other users.
  2. Do not access others' data — If you encounter another user's personal data during research, stop immediately, do not record it, and report the finding.
  3. Do not exfiltrate data — Demonstrate the vulnerability with minimum necessary evidence. Do not download, copy, or store user data.
  4. Do not modify data — Do not alter, delete, or corrupt any data on our systems.
  5. Use test accounts only — If testing requires authentication, use only accounts you own or accounts we provide for testing.
  6. No automated scanning without coordination — Contact us before running automated scanners. Unauthorized automated scanning is out of scope.
  7. No physical attacks — Physical access attacks, social engineering, and phishing are out of scope.
  8. No denial of service — Do not intentionally degrade or disrupt our services.
  9. Respect rate limits — Work within existing rate limits; do not attempt to bypass them during research.

6. Qualifying Vulnerabilities

Examples of vulnerabilities we are interested in:

  • Remote code execution (RCE)
  • SQL injection, NoSQL injection
  • Cross-site scripting (XSS) — stored, reflected, DOM-based
  • Cross-site request forgery (CSRF)
  • Server-side request forgery (SSRF)
  • Authentication/authorization bypass
  • Insecure direct object references (IDOR)
  • Sensitive data exposure
  • Broken access control
  • Security misconfiguration
  • Injection flaws (command injection, LDAP injection, etc.)
  • Cryptographic vulnerabilities
  • Business logic flaws

7. Non-Qualifying Issues

The following are generally not considered qualifying vulnerabilities:

  • Missing HTTP headers that do not lead to direct exploitation (e.g., X-Frame-Options on non-sensitive pages)
  • SSL/TLS best practice deviations without demonstrated impact
  • Content spoofing or text injection without clear security impact
  • Rate limiting absence on non-sensitive endpoints
  • Outdated software versions without a demonstrated exploit
  • Clickjacking on pages with no state-changing actions
  • Missing cookie flags on non-sensitive cookies
  • Theoretical attacks without proof of concept
  • Issues requiring physical access to a user's device
  • Self-XSS (requires victim to paste attacker code into their own browser)

8. Recognition

We believe in recognizing the contributions of security researchers:

  • Public Acknowledgement — With your permission, we will acknowledge your contribution on our Security Hall of Fame page.
  • Private Thanks — If you prefer anonymity, we will provide private acknowledgement.
  • Reference Letter — For significant findings, we can provide a reference letter confirming your responsible disclosure.

Note: We do not currently operate a paid bug bounty program. This may change in the future.

9. Disclosure Timeline

  • We request a minimum 90-day disclosure window from the time you report a vulnerability before any public disclosure.
  • We will coordinate with you on the timing and content of any public disclosure.
  • If we are unable to remediate within 90 days, we will communicate the reason and agree on an extended timeline.
  • We will not suppress disclosure indefinitely — we commit to transparent communication about remediation progress.

10. CERT-In Coordination

For vulnerabilities classified as Critical that involve active exploitation, data breach, or impact to user data, SecNinjaz will:

  • Report the incident to CERT-In (Indian Computer Emergency Response Team) within 6 hours as required under CERT-In Directions dated 28 April 2022.
  • Coordinate with CERT-In on any advisories or broader notifications as needed.
  • This does not affect the safe harbour provisions for the reporting researcher.

11. Contact

This Vulnerability Disclosure Policy was last reviewed and published on 25 March 2026.