Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.riftmap.dev/llms.txt

Use this file to discover all available pages before exploring further.

​
Reporting a vulnerability

If you’ve found a security issue in Riftmap, please disclose it privately rather than posting it publicly. Email hello@riftmap.dev with reproduction steps and any relevant version, request, or environment info. We aim to acknowledge within two business days.

Email security disclosures

Goes straight to maintainers. Please use this channel rather than opening a public issue anywhere.

​
What’s in scope

  • The hosted product at riftmap.dev and its API
  • The static schema and docs at docs.riftmap.dev and riftmap.dev/openapi.json

​
What’s out of scope

  • Reports based purely on automated scanner output without a working proof‑of‑concept
  • Volumetric DoS / brute-force findings against the hosted product (we have rate limits; please don’t try to find their thresholds)
  • Issues that require a privileged position the attacker shouldn’t have (e.g. “if I steal an owner’s API key, I can act as that owner”)
  • Social engineering of staff or customers

​
What we’ll do

  1. Acknowledge the report.
  2. Triage and confirm the issue, or push back with reasoning.
  3. Develop and ship a fix; coordinate disclosure timing with you.
  4. Credit you in release notes if you’d like (and if the fix is shipped).
We don’t currently run a paid bug-bounty program, but we do appreciate the work and will say so publicly when a fix lands.

​
What Riftmap does with your data

Short version:
  • Source code is never stored. Repos are shallow-cloned (depth=1) into a per-scan temporary directory at 0700 permissions, parsed for dependency manifests, and rmtree’d in a try/finally. Only the dependency graph metadata persists in the database.
  • Tokens are encrypted at rest with Fernet. The encryption key lives in env (ENCRYPTION_KEY) and is required at startup outside dev mode.
  • Cross-workspace isolation is enforced at every endpoint: workspace API keys can’t reach another workspace’s data, and foreign-workspace requests return 404 (not 403, to avoid leaking existence).
  • GDPR data export is available at GET /workspaces/{id}/export (owner/admin only). Account deletion is at POST /auth/account/delete with a 30-day grace period.

​
Auth design (one-pager)

SurfaceAuthNotes
Browser sessionsJWT cookies (15-min access, 30-day refresh, HttpOnly)Set by /auth/login and OAuth callback.
API integrationsWorkspace API keys (rfm_live_…)SHA-256 hashed at rest; raw key shown once.
Mutations are rate-limited per identity. Cross-workspace access returns 404. See Authentication for the header conventions and limit specifics.

​
Responsible exposure decisions

We deliberately:
  • Disable live /openapi.json and /docs in production — agents read the static schema published from CI at riftmap.dev/openapi.json, which is reviewed and exported deliberately rather than auto-introspected from a running prod server.
  • Return 404, not 403, for cross-workspace requests — so attackers can’t enumerate which workspace IDs are real.
  • Return rate-limit errors with a precise Retry-After rather than silently dropping requests — predictable behaviour beats opaque failure.
If you find a place where these defaults haven’t been applied, that’s exactly the kind of report we want.