← Documentation

Data services exposed on the internet

One harmless read request to Elasticsearch, ClickHouse, Meilisearch, CouchDB and MongoDB default interfaces; reported only when the reply proves no credential was needed.

Check method

One harmless read request to Elasticsearch, ClickHouse, Meilisearch, CouchDB and MongoDB default interfaces; reported only when the reply proves no credential was needed.

Possible evidence type

Live observation when the check is compatible and authorized. This description does not mean your platform has been tested.

Access and limitations

Website address. Actual results and checks not run appear in your report. A check with no finding does not guarantee the absence of risk.

Concrete scenario

A search or data service exposes a public endpoint without the intended access restriction.

What to inspect

Determine whether returned content is deliberately public or private; a reachable port alone is not a data leak.

Remediation approach

Restrict network exposure and apply authentication and dataset-level permissions appropriate to the service.

Understand grants, policies and identity

Database grants determine whether a role can reach a table or function; row-level security determines which rows it can access. Enabling RLS without a usable policy can block legitimate users, while a broad policy can expose every tenant. A privileged server credential may bypass these protections and must never be shipped to the browser.

  1. Identify the role making the request and the identity used by the policy.
  2. Review both table grants and policies for each read or write operation.
  3. Check owner access to private, draft and archived rows separately from public access.

Validate without changing production data

Catalog-only inspection can show policy definitions and privilege configuration, but does not prove every application-level access path. Two-account isolation exercises provide stronger behavioral evidence when separately authorized. Backup availability is also different from a successful restore test.

  1. Review definitions and grants in the supported read-only audit.
  2. Use isolated test records for any owner-approved behavioral exercise.
  3. Retest the expected owner access and denied cross-account access after changes.

References

OWASP A05

Sources and further reading

These publications describe related practices and standards. They do not certify your platform or imply that Hackaiz executes every documented method.