This file covers how to report a security problem and what happens after you do.

Email security@geodb.io. If that address bounces or you get no acknowledgement within three working days, use support@geodb.io — it reaches the same people.

Do not open a public issue for a security problem. The issue tracker is public and indexed; a report filed there is a disclosure, not a report.

A useful report includes:

• What you were able to do that you should not have been able to do.
• The endpoint, operation id, or schema involved, and the protocol version or spec commit you were reading.
• The request you sent and the response you got — headers included where they matter, with any access token redacted.
• Whether you used a grant token, a first-party token, or no credentials at all.
• Anything you know about blast radius: one project, one account, or everyone.

You do not need a proof-of-concept exploit. A clear description of the flaw is enough, and we would rather hear about it early than see it fully weaponised.

Please do not run automated scanners against api.geodb.io, and please do not pull, retain, or share data belonging to anyone but yourself while investigating. If you reached data that is not yours, stop, tell us what you reached, and delete your copy.

• We acknowledge a report within three working days.
• We tell you whether we consider it a vulnerability, and why, within ten working days.
• We aim to ship a fix and publish the details within 90 days of the report. If a fix ships earlier, the disclosure follows the fix rather than waiting out the window.
• If a fix will take longer than 90 days we will say so, say why, and agree a date with you rather than letting the window lapse in silence.
• We will credit you in the changelog entry unless you ask us not to.

There is no bug bounty. We are a small team and we pay for fixes with attention, not money.

In scope:

• The protocol specification. A design that cannot be implemented safely, an access-control model with a hole in it, a scoping rule that does not compose — the spec itself being wrong is a security finding.
• The reference implementation, the hosted API at api.geodb.io, and the grant surface it exposes (Authorization: Grant …).
• The Python client, geodb-client.
• The artifacts in this repository — schemas, the xpl: STAC extension, and the scripts under scripts/.

Out of scope:

• Findings about a specific customer's data. If you are a geoDB customer and the issue is with your own project's data, configuration, or access, that is a support matter: email support@geodb.io. We handle it with that customer directly and we do not publish it here. If a customer-specific finding turns out to have a general cause, the general cause comes back into this process.
• Reports generated by a scanner with no analysis attached, missing hardening headers with no demonstrated impact, rate-limit tuning, and findings that require an attacker to already hold a valid credential the owner deliberately issued to them.
• Social engineering, physical access, and denial of service by volume.

Issues about the design — how grants scope, what a revoked grant should do on the wire, whether the access log can be trusted, what a write ought to require — are ordinary public issues and are very welcome. See CONTRIBUTING.md. The line is simple: a flaw in our running system goes to the address above; a flaw in the contract anyone would implement goes in the open, because everyone implementing it needs to see the argument.