nausika

security

Security.

Last updated

Nausika takes security seriously. This page is the canonical place for security researchers, AI client developers, and connected users to understand how to report a vulnerability, what response to expect, and what is in or out of scope. The machine-readable contact lives at /.well-known/security.txt.

Reporting a vulnerability

Email [email protected] with as much detail as you can: the affected endpoint or tool, a reproduction recipe, the impact you observed, and whether you believe the issue is exploitable in the wild. We acknowledge every report within 2 business days.

We do not currently offer PGP encryption. Send plain email and we will follow up to coordinate a secure channel if the report contains material sensitive to expose in transit. We do not run a paid bug bounty.

Please do not test for vulnerabilities in ways that degrade service for other users (denial of service, automated scanning at high request rates, attempts to access other users' data). If you find an issue while using Nausika normally and discover it accidentally, that is fine — just report it.

Patch response SLA

Severity is assessed by the maintainer in dialogue with the reporter, using industry-standard triage criteria (CVSS-like reasoning, focused on real-world impact for Nausika's data model and threat surface).

  • Critical — remote code execution, authentication bypass on the MCP endpoint, cross-tenant data exfiltration, take-over of an existing user account: patched within 7 days; hotfix deploy on mcp.nausika.app the same day where feasible.
  • High — privilege escalation (for example user → admin), sensitive data leak (OAuth tokens, session cookies), persistent injection (stored XSS in admin UI): patched within 14 days.
  • Medium — denial of service through a single tool call, information disclosure that does not include personal data, reflected injection: patched within 30 days.
  • Low — best-practice deviations with no demonstrable exploit, hardening improvements, theoretical issues: addressed in a regular release, generally within 90 days.

Coordinated disclosure

We prefer coordinated disclosure. Once a vulnerability is acknowledged, we ask reporters to hold public disclosure for at least 30 days from acknowledgment (or until the patch is deployed, whichever comes first), so connected users are not exposed to in-the-wild exploitation before a fix is available.

We will credit the reporter on /log when the issue is disclosed, unless the reporter requests otherwise. Anonymous reports are welcome and we treat them with the same triage discipline as named ones.

Supported versions

Nausika is served from a single public endpoint at mcp.nausika.app, deployed from the most recent main-branch build. Only the currently deployed version is supported; there are no parallel maintenance branches and no on-premise distributions. When a patch ships, it ships for everyone simultaneously.

Self-hosted forks or unofficial deployments are out of scope for the patch SLA above — the source code is private and we do not currently distribute it.

Out of scope

  • Vulnerabilities in third-party services we depend on — Railway, Cloudflare, Resend, GitHub OAuth, Google OAuth, Open-Meteo, NOAA, Wikimedia, OpenStreetMap. Please report directly to the upstream provider; if the issue is in how Nausika integrates with them (for example a missing redirect-URI check on our side), that is in scope.
  • Reports that require physical access to a user's device or compromised browser/OS, unless a Nausika-specific behavior worsens the situation.
  • Lack of rate-limit on read-only endpoints below the documented service-wide limits — these are tracked as performance work, not as security issues.
  • Best-practice "findings" with no demonstrable impact (missing security headers on static assets, version disclosure on third-party libraries we already patch on a regular cadence, etc.) — we read them and consider them, but they do not qualify for the SLA above.

What we protect, in plain terms

Two distinct asset classes inform our triage:

  • User-scoped data — your account email, OAuth tokens, boat profile, saved routes, ratings, favorites, submitted proposals. Cross-tenant access to any of this is treated as critical.
  • Public-but-curated data — places, attributes, attribution metadata, images. Tampering that affects what other users see (for example unauthorized writes to places) is treated as high; read access to it is by design open.

Nausika does not store payment data, health data, government-ID data, or biometrics. See Privacy for the full data model and retention policy.

Hardening posture

For transparency: the things we do continuously, not as a reaction to specific reports.

  • OAuth 2.1 with PKCE for public clients; opaque bearer tokens stored hashed in our database (no JWT secret to leak).
  • Anti-SSRF validation on every fetch from user-supplied URLs (image proxy, place proposals).
  • Strict CORS allow-list on the MCP endpoint; same-origin requirement on connector icons per the MCP spec.
  • Database access strictly through parameterized queries (tagged template literals); no string-concatenated SQL anywhere in request-scoped code.
  • 90-day retention on full request logs, 30-day retention on operational logs, automatic cleanup via a scheduled job. See Privacy.
  • Schema-version guard on the MCP service: the public connector refuses to start against a database older than the schema it expects, preventing stale-deploy footguns.

Maintenance & backwards compatibility

Security patches sometimes require breaking changes. When that happens we follow the notice rules described in the roadmap: 60 days of advance notice on /log for breaking interface changes, with the exception of active exploitation, where we ship the fix immediately and explain the change retroactively.

The wider commitment to keeping Nausika maintained — service availability, sunset notice, public log — lives in the roadmap.