Security & Responsible Disclosure

This Security & Responsible Disclosure Policy ("Policy") governs the reporting, handling, and resolution of security vulnerabilities affecting systems, services, and infrastructure operated by Saproh Private Limited under the Pingovo brand.

This Policy applies to all individuals and entities who discover, research, or wish to report potential security vulnerabilities in Saproh-operated systems, whether they are professional security researchers, independent researchers, customers, or members of the public.

By submitting a vulnerability report to Saproh, the reporter agrees to comply with the terms of this Policy in full.

Saproh Private Limited is committed to the following principles in the context of vulnerability research and disclosure:

• Good faith engagement — We will respond to all valid vulnerability reports promptly and in good faith
• Transparency — We will communicate our assessment of reported vulnerabilities clearly and honestly
• Remediation — We will prioritise the remediation of confirmed vulnerabilities based on severity and risk
• No retaliation — We will not take legal action against researchers who act in accordance with this Policy
• Credit — We will acknowledge the contributions of researchers who report valid vulnerabilities, subject to their consent

We ask that researchers act in good faith, avoid harm to our users and systems, and follow the coordinated disclosure process described in this Policy.

3.1 Conditions for Safe Harbour

Safe harbour protection applies when the researcher:

1. Discovers a vulnerability through legitimate, non-destructive means
2. Reports the vulnerability to Saproh promptly through the designated channel before any public disclosure
3. Does not exploit the vulnerability beyond what is minimally necessary to confirm its existence
4. Does not access, exfiltrate, modify, or destroy any data belonging to Saproh or its users
5. Does not disrupt or degrade any Saproh service or system
6. Complies with all applicable laws in the jurisdiction(s) where the research is conducted
7. Does not engage in any prohibited activities listed in Section 6 of this Policy

3.2 Scope of Protection

Safe harbour protection is offered by Saproh Private Limited for civil claims under Indian law. Saproh cannot guarantee protection from prosecution by third parties or law enforcement authorities, particularly where the research may have violated laws in the researcher's jurisdiction or laws of other countries.

3.3 No Waiver

Safe harbour protection does not constitute a waiver of any rights Saproh may have under applicable law in respect of activities that fall outside the scope of this Policy or that are conducted in bad faith, with malicious intent, or in violation of applicable law.

4.1 In-Scope Systems

The following Saproh-operated systems are in scope for this Policy:

• pingovo.com — primary web application and marketing website
• API endpoints — pingovo.com/api/v1/* and all other API routes
• Authentication systems — login, registration, password reset, OTP flows
• User dashboard & platform features — all authenticated features including verification, campaigns, SMTP configuration, Pingovo Mail sending infrastructure, billing, and settings
• Admin panel — /admin
• Webhook delivery infrastructure
• Email tracking infrastructure — tracking pixel endpoints and click redirect endpoints

4.2 In-Scope Vulnerability Categories

We are particularly interested in reports covering:

• Authentication & Authorisation Flaws — broken authentication, insecure session management, JWT vulnerabilities, IDOR (Insecure Direct Object References), privilege escalation, missing authorisation checks
• Injection Vulnerabilities — SQL injection, NoSQL injection (MongoDB), command injection, LDAP injection, Server-Side Template Injection (SSTI)
• Cross-Site Scripting (XSS) — stored XSS, reflected XSS, DOM-based XSS, including those with a demonstrated security impact
• Cross-Site Request Forgery (CSRF) — especially on authenticated actions with real-world impact
• Server-Side Request Forgery (SSRF) — particularly in bulk upload processing, webhook configuration, or API request handling
• Insecure Direct Object References (IDOR) — access to other users' data through predictable or guessable identifiers
• Sensitive Data Exposure — unintended disclosure of API keys, SMTP credentials, personal data, or other sensitive information
• Business Logic Flaws — circumventing credit limits, plan restrictions, rate limits, or verification quotas
• Remote Code Execution (RCE) — any vulnerability enabling execution of arbitrary code on Saproh servers
• File Upload Vulnerabilities — malicious file upload through bulk verification or template features
• Security Misconfiguration — exposed admin interfaces, default credentials, overly permissive CORS policies, unnecessary services exposed
• Cryptographic Weaknesses — weak encryption, predictable token generation, insecure key management
• Denial of Service via Application Logic — vulnerabilities (not volumetric attacks) that allow a single user to crash or severely degrade the service
• Account Takeover — any mechanism enabling takeover of another user's account without their credentials
• Email Spoofing / Header Injection — vulnerabilities enabling injection of arbitrary headers into outbound emails

5.1 Out-of-Scope Systems

The following are out of scope and reports regarding them will not be accepted:

• Third-party services, libraries, or infrastructure not operated by Saproh (e.g., Razorpay, MongoDB Atlas, AWS)
• Systems of Saproh partners, vendors, or customers
• Social engineering attacks targeting Saproh employees
• Physical security of Saproh facilities
• Any domain, subdomain, or service not explicitly listed in Section 4.1

5.2 Out-of-Scope Vulnerability Types

The following vulnerability types are generally considered out of scope:

• Vulnerabilities in outdated browsers or operating systems
• Missing HSTS headers, CSP headers, or similar best-practice-only security headers where no exploitable impact is demonstrated
• Clickjacking on pages with no sensitive actions
• Self-XSS that cannot be used to attack other users
• Missing rate limiting on low-risk endpoints (unless a specific attack is demonstrated)
• User enumeration through email existence confirmation (inherent to a verification service)
• Password complexity or lockout policy issues without demonstrated impact
• Theoretical vulnerabilities without a proof-of-concept demonstrating real-world exploitability
• Reports based solely on automated scanner output without manual validation and demonstrated impact
• Vulnerabilities requiring physical access to the victim's device
• SPF, DKIM, or DMARC issues on domains not used for user-facing authentication

The following testing activities are strictly prohibited:

1. Accessing, exfiltrating, or modifying any user data — including data belonging to other Pingovo customers, without their explicit written consent
2. Disrupting or degrading service availability — including any form of denial-of-service (DoS/DDoS) testing against Pingovo infrastructure
3. Sending spam, phishing, or malicious email campaigns through the Platform as part of testing
4. Using the verification engine to harvest or build email lists for commercial, personal, or malicious use
5. Deploying or detonating malware, ransomware, or destructive payloads on Saproh systems
6. Testing against production accounts or data of other users — all testing must be performed against your own account and data
7. Disclosing vulnerability details publicly before Saproh has had the opportunity to remediate and issue a coordinated disclosure
8. Demanding payment or extortion in exchange for not disclosing a vulnerability or for providing details of a vulnerability
9. Conducting research from compromised systems or systems located in sanctioned jurisdictions
10. Accessing the Admin panel without explicit written authorisation from Saproh

7.1 Submission Channel

All vulnerability reports must be submitted by email to:

7.2 Encryption

For reports involving highly sensitive vulnerabilities (e.g., RCE, mass data exposure), We encourage reporters to encrypt their submission using PGP. Please email [email protected] to request our PGP public key.

7.3 Required Information

To ensure We can triage and remediate effectively, please include the following in your report:

1. Vulnerability title — a concise, descriptive title
2. Affected URL / endpoint / feature — precise location of the vulnerability
3. Vulnerability type — e.g., IDOR, XSS, SSRF (reference OWASP or CVE categories where applicable)
4. Severity assessment — your assessment of the severity (Critical / High / Medium / Low) with justification
5. Step-by-step reproduction instructions — detailed enough for our team to reproduce without additional guidance
6. Proof of concept — screenshots, videos, HTTP request/response logs, or code demonstrating the vulnerability
7. Potential impact — what an attacker could achieve by exploiting this vulnerability
8. Affected account — the Pingovo account used during testing (so We can audit the test)
9. Your contact details — email address for follow-up communications
10. Whether you wish to be publicly credited

7.4 Language

Reports should be submitted in English. Reports in other languages will be considered but may experience delayed response times.

Once a report is received, Saproh follows this structured response process:

Remediation timelines are targets, not guarantees. Complex vulnerabilities requiring architectural changes may require additional time. Saproh will communicate any timeline changes to the reporter promptly.

10.1 Hall of Fame

Saproh maintains a Security Hall of Fame recognising researchers who responsibly disclose valid, in-scope vulnerabilities. Listing is subject to the reporter's consent. Recognition will include the researcher's name or handle and the vulnerability category.

10.2 Bug Bounty

Saproh does not currently operate a formal paid bug bounty programme. We are grateful to the security research community and will consider offering non-monetary rewards such as extended platform credits, premium subscription access, or other tokens of appreciation for high-severity, high-quality reports at our sole discretion.

10.3 No Monetary Obligation

Saproh has no obligation to provide any monetary compensation, reward, or benefit to any researcher. Any reward offered is entirely at Saproh's discretion and does not create any precedent or obligation for future reports.

10.4 Eligibility

To be eligible for recognition or any reward, the reporter must: (a) be the first to report the specific vulnerability; (b) comply with this Policy in full; (c) not be an employee, contractor, or direct family member of an employee or contractor of Saproh; and (d) not be located in a jurisdiction subject to applicable sanctions.

11.1 Disclosure Embargo

Saproh requests that reporters maintain strict confidentiality about reported vulnerabilities until Saproh has issued a remediation and authorised disclosure. The standard embargo period is 90 days from the date of initial report.

11.2 Early Disclosure Requests

If a reporter wishes to disclose before the 90-day period, they must request written permission from Saproh. Saproh will consider such requests on a case-by-case basis, taking into account the severity of the vulnerability and the status of remediation.

11.3 Extended Embargo

For vulnerabilities requiring complex remediation (such as architectural changes or third-party coordination), Saproh may request an extended embargo. The reporter will be notified and Saproh will provide regular updates on remediation progress.

11.4 Public Disclosure Without Coordination

Uncoordinated public disclosure of an unpatched vulnerability — including on social media, security conferences, bug bounty platforms, or public repositories — before remediation constitutes a violation of this Policy and will result in the immediate withdrawal of safe harbour protections and may result in legal action.

11.5 Security Advisories

Following remediation of significant vulnerabilities, Saproh may publish a security advisory on its platform. Such advisories will include a description of the vulnerability, affected components, remediation actions taken, and credit to the reporter (where consent is given).

12.1 Confidentiality of Reports

Saproh treats all vulnerability reports as confidential. Report contents will not be shared outside of Saproh's security and engineering teams without the reporter's consent, except where required by law or where sharing is necessary to remediate the vulnerability (e.g., with a third-party vendor whose product is affected).

12.2 Data Minimisation

Saproh will only request information from reporters that is necessary to triage and remediate the reported vulnerability. Reporters should avoid including unnecessary personal data of other users in their proof-of-concept materials.

12.3 Retention

Vulnerability reports and associated correspondence are retained by Saproh for a period of 3 years from the date of remediation, for internal audit and incident history purposes.

12.4 Reporter Personal Data

Personal data provided by reporters (name, email, handle) is processed in accordance with Saproh's Privacy Policy and used solely for the purpose of managing the vulnerability report and, where consent is given, for public recognition.

Saproh implements the following technical and organisational security measures to protect the Pingovo Platform and its users:

13.1 Application Security

• TLS 1.2+ encryption for all data in transit
• AES-256 encryption for SMTP credentials at rest
• bcrypt password hashing with appropriate work factor
• Signed JWT tokens for session management with appropriate expiry
• API key hashing — only key prefixes are stored in readable form
• Input sanitisation and validation to prevent NoSQL injection, XSS, and other injection attacks
• CSRF protection on all state-changing requests
• Role-based access controls (RBAC) with separate roles for users, admins, editors, and contractors
• Rate limiting on all API endpoints and authentication routes

13.2 Infrastructure Security

• Isolated execution environments for bulk verification processing
• Encrypted storage for uploaded files
• PCI DSS-compliant payment processing through Razorpay (Saproh never stores raw card data)
• Automated security scanning in the deployment pipeline
• Network firewalls and intrusion detection
• On-premises outbound email content scoring (Rspamd) to prevent delivery of spam-flagged campaigns from the Pingovo Mail IP pool
• DKIM signing of all outbound campaign emails; per-user RSA-2048 key pairs with encrypted private key storage
• Continuous DNSBL monitoring of sending IPs with automated blacklist alerting

13.3 Operational Security

• Principle of least privilege for all internal system access
• Security-aware development practices and code review
• Regular review of dependencies for known CVEs
• Incident response procedures for security events
• Automated monitoring for anomalous account access patterns

14.1 No Authorisation for Unauthorised Access

Nothing in this Policy constitutes authorisation for any form of unauthorised access to Saproh systems or data. This Policy applies only to good-faith vulnerability research conducted in accordance with its terms.

14.2 Applicable Law

This Policy is governed by the laws of India. Saproh's commitments under this Policy are subject to applicable Indian law, including the Information Technology Act, 2000 and the Indian Penal Code, as amended.

14.3 Limitation of Liability

Saproh shall not be liable to any reporter for any damages, losses, or claims arising from or in connection with their security research activities, including but not limited to accidental data exposure, service disruption, or third-party claims.

14.4 Amendment

Saproh reserves the right to amend this Policy at any time. The current version is always published at pingovo.com/responsible-disclosure. Continued participation in the vulnerability disclosure programme after an amendment constitutes acceptance of the revised Policy.

To report a security vulnerability or for any security-related inquiry, please contact: