Encryption in transit
The production site and API are served over HTTPS/TLS. The backend's own connection to the upstream government portal also uses HTTPS, and it uses the AES parameters the portal's own public client-side code ships to decode the portal's response payloads — those are protocol constants published by the government portal itself, not a secret credential of ours.
Data at rest
- Fetched land records are cached briefly (minutes to hours) on the server and reset daily; they are not stored in a permanent, personally-indexed database.
- Location hierarchy (district/mandal/village names and IDs — not land records) is stored in PostgreSQL so repeat lookups don't hit the government portal every time. This is taxonomy data, not personal data.
- No user credentials exist to store, because there is no account system.
- Secrets such as an optional OpenAI API key are kept in server-side environment configuration, never returned by an API response, logged, or written to the database.
Access controls
Query parameters and identifiers are validated before use. Cross-origin access (CORS) is configurable per deployment; our production instance currently allows broad browser access consistent with a public, read-only lookup tool, and we recommend any self-hosted, non-public deployment restrict CORS to its actual frontend origin. The MCP endpoint performs the same read-only operations as the REST API and is unauthenticated by default — appropriate for a public, read-only data source, but operators running a private deployment should place authentication and rate limiting in front of it.
Backend resilience
The backend is built to fail safely rather than fail open:
- bounded concurrency and connection pooling toward the upstream portal, so one heavy request can't exhaust shared resources;
- exponential-backoff retries for timeouts and transient upstream errors, with clear error mapping (404/502/504) back to the client;
- one bad survey or Khata branch is logged and skipped rather than failing an entire village fetch;
- defensive HTML parsing isolated to a single module, since the upstream portal's markup is outside our control.
API and MCP exposure
Every REST operation the browser uses is also available as an MCP tool, and both share the same service layer, validation, and retry logic — there is no separate, less-audited code path for MCP clients. All exposed operations are read-only: none of them can modify a government record.
Audits and compliance signals
BhuBharati Explorer is an independently operated, free tool rather than an enterprise product, and does not currently hold a third-party security certification (e.g. SOC 2, ISO 27001). If that changes, it will be listed here with a link to the relevant report or attestation.
Reporting a security issue
If you find a vulnerability, please report it privately through the project repository rather than filing a public issue with exploit details, so it can be fixed before wider disclosure. Include enough detail to reproduce the issue; we will acknowledge reports and work on a fix.