Last updated: 2026-05-24
Ollagraph welcomes reports from independent security researchers. This page describes what we consider in scope, how to report a vulnerability, what we promise in return, and what we ask researchers not to do.
Reporting a vulnerability
Email [email protected]. Include:
- A description of the issue and the affected endpoint or page.
- Steps to reproduce, including request bodies and any sample accounts you created.
- The impact you believe the issue has.
- Your name or handle for credit (optional — we are happy to keep reports anonymous if you prefer).
If you would like to encrypt your report, ask for our PGP key in your first message and we will reply with it.
In scope
api.ollagraph.com— the production API.ollagraph.com— the marketing site.app.ollagraph.com— the customer dashboard.- The official Postman collection and OpenAPI specification.
Vulnerability classes we want to hear about, in roughly descending priority:
- Authentication and authorization bypass — access to another customer's keys, jobs, usage, or billing.
- Server-side request forgery on customer-supplied URLs that reaches our internal network.
- Remote code execution or container escape.
- SQL injection, command injection, prototype pollution.
- Sensitive data exposure — API keys, password hashes, raw card data, internal logs.
- Webhook signature bypass.
- Billing webhook spoofing, double-spend in the credit ledger.
- Stored XSS in the dashboard.
- Account takeover via password-reset, email-verification, or session-fixation flaws.
Out of scope
The following are known limitations or accepted trade-offs and are not eligible for reward or coordinated disclosure unless they enable an in-scope class above:
- Self-XSS that requires the victim to paste content into their own console.
- Missing security headers on static asset domains.
- Email enumeration on signup (ollagraph.com uses a catch-all mailbox; every address resolves).
- Reports from automated scanners without a reproducible exploit.
- Denial of service via raw volume against the public API — rate limits and quotas are the documented control.
- Issues affecting browsers more than five years out of date.
- Theoretical attacks without a demonstrable security impact.
- Reports about our use of subprocessors that are themselves operating within their own published security policy — report those to the subprocessor.
- Anything that depends on social-engineering Ollagraph staff.
- Physical attacks against our facilities or staff.
Safe harbour
If you make a good-faith effort to comply with this policy when investigating a vulnerability, Ollagraph will:
- Not pursue legal action against you for the research.
- Not ask law enforcement to investigate you.
- Treat your research as authorized for the purposes of any applicable computer-misuse statute.
- Work with you on a coordinated disclosure timeline that respects both customer safety and your research interest.
"Good-faith effort" means: you do not access or modify other customers' data beyond the minimum needed to demonstrate the issue; you do not exfiltrate data; you do not deliberately disrupt the service for other users; you report the issue promptly; and you give us a reasonable window to fix it before public disclosure.
What we promise in response
- Acknowledgement within one business day of your initial email.
- An initial severity assessment within five business days.
- Regular updates — at least every two weeks while the issue is open.
- Public credit in the security acknowledgements once a fix is shipped, unless you ask for anonymity.
- For confirmed in-scope issues, a thank-you in the form of swag and, for material findings, a discretionary bounty. Ollagraph does not currently run a formal paid bounty programme, and this should not be assumed.
Target time to fix, by severity:
- Critical (active exploitation, data breach): hours to a few days.
- High (privilege escalation, auth bypass without active exploitation): under 14 days.
- Medium (sensitive data exposure with limited impact): under 30 days.
- Low (defensive hardening): scheduled into normal release cycle.
Coordinated disclosure
We ask researchers to keep the details private until either (a) the fix is deployed and verified, or (b) 90 days from initial report — whichever comes first. If the fix is not in production at the 90-day mark we will discuss an extension with you; we will not invoke the 90 days as a reason to stay silent past it.
Hall of fame
Researchers who have helped harden Ollagraph will be listed here once we receive our first qualifying report.
Contact
Security reports: [email protected]
General security questions: see the security page and the architecture page.