This security policy applies to all components maintained by the BharatData Team:
| Component | Repository Path |
|---|---|
| BharatData API | packages/api/ |
| TypeScript SDK | packages/typescript-sdk/ |
| Python SDK | packages/python-sdk/ |
| Playground | packages/playground/ |
| Data Pipeline | pipeline/ |
We actively maintain and provide security patches for the following versions:
| Version | Status |
|---|---|
v1.x (Current) |
✅ Actively supported |
v0.x (Beta) |
Please do NOT open a public GitHub Issue for security vulnerabilities. Public disclosure before a fix is available puts all users of BharatData at risk.
- Email us directly at:
security@bharatdata.org - Subject line format:
[SECURITY] Brief description of issue - Include in your report:
- A clear description of the vulnerability
- The component and version affected
- Step-by-step reproduction instructions
- Impact assessment (what an attacker could do)
- Any proof-of-concept code (if applicable)
| Timeline | Action |
|---|---|
| Within 48 hours | We acknowledge receipt of your report |
| Within 7 days | We provide an initial severity assessment |
| Within 30 days | We aim to have a patch ready for critical and high severity issues |
| Upon release | We publicly disclose the vulnerability with full credit to the reporter |
We assess all reports using the standard CVSS (Common Vulnerability Scoring System) v3.1 framework.
| Severity | Score | Example |
|---|---|---|
| Critical | 9.0–10.0 | Remote Code Execution, database credential leak |
| High | 7.0–8.9 | Authentication bypass, mass data exfiltration |
| Medium | 4.0–6.9 | Rate limit bypass, stored XSS |
| Low | 0.1–3.9 | Information disclosure, verbose error messages |
The following attack surfaces are in scope for responsible disclosure:
- API Security: Authentication bypass, injection attacks (SQL, NoSQL, SSRF), broken access control
- Rate Limiting: Methods to bypass the 10/min or 200/day per-IP limits at scale
- Data Integrity: Any method that could allow modification or fabrication of the data served
- Infrastructure: Misconfigured Cloudflare Workers, Supabase Row Level Security issues
- SDK Security: Any vulnerability in the TypeScript or Python SDK that affects downstream users
The following are explicitly not considered valid security vulnerabilities:
- Issues in third-party dependencies that are already publicly known (check the relevant package's CVE list)
- Denial of service via extremely high volume requests beyond normal legitimate use (this is handled by rate limiting)
- Social engineering attacks targeting BharatData team members
- Physical security attacks
- Vulnerability reports for versions that are no longer supported
BharatData is committed to working with security researchers in good faith. Any researcher who:
- Follows responsible disclosure practices
- Makes a good-faith effort not to access or modify data
- Does not perform attacks on production infrastructure beyond what is necessary to demonstrate the vulnerability
...will receive our full cooperation, credit in the public disclosure, and our sincere thanks.
We will not pursue legal action against researchers who comply with this policy.
Security researchers who responsibly disclose valid vulnerabilities will be acknowledged in our public CHANGELOG.md with the disclosure note and credited for their contribution to keeping BharatData safe.
We do not currently offer a monetary bug bounty program, but we are deeply grateful for community contributions to our security.