Skip to content

Security: alainux/meaningspace

Security

SECURITY.md

Security

Public-service model

MeaningSpace v0.5 is intentionally public and unauthenticated. It stores no user data, has no accounts, accepts no payments, and calls no external model or API.

The service never receives the caller's creative material in the first place. It returns procedures; the work is performed client-side. A brief is echoed back within the same response and used to seed deterministic selection, and nothing is retained between requests.

This is the strongest privacy property of the design: there is no concept representation to leak, no session to compromise, and no generated content to attribute.

Protections

  • MCP requests validate the Origin header and return HTTP 403 for disallowed browser origins.
  • The local Node adapter binds to 127.0.0.1 by default.
  • Dynamic request bodies are capped at 512 KB, measured in bytes, so prior moves can be replayed for continuation without accepting unbounded payloads.
  • Cloudflare's native rate-limit binding protects dynamic tool and API calls.
  • Dynamic responses use Cache-Control: no-store and X-Content-Type-Options: nosniff.
  • Static paths are resolved inside the build directory by the local adapter.
  • Runtime input normalization rejects malformed JSON-RPC and creativity payloads.
  • Strict TypeScript, exact optional properties, and unchecked-index protection reduce accidental shape errors.
  • The service performs no dynamic code execution, template evaluation, filesystem writes, or outbound network requests.

Origin policy

Requests without an Origin header are accepted because non-browser MCP clients commonly omit it. Browser-originated MCP requests are accepted only from:

  • the configured application origin;
  • localhost;
  • 127.0.0.1;
  • [::1].

APP_URL in wrangler.jsonc is optional; same-origin and localhost requests are allowed automatically. Set it only if browser clients from another origin must call the API. Do not broaden the allowlist without reviewing DNS-rebinding and cross-site request risks.

Rate-limit limitations

The rate-limit key is derived from the connection IP (cf-connecting-ip, falling back to the first x-forwarded-for entry, or local-development when running locally). It never trusts client-supplied headers such as x-meaningspace-client or mcp-session-id, so a caller cannot spoof a different bucket.

The rate-limit binding is a fair-use control, not exact global accounting. It is permissive and location-local. Cloudflare's daily Worker allowance remains the practical cost boundary and may temporarily reduce availability under abuse.

For a future paid service, replace this limiter with authenticated, durable usage accounting. Do not use the present rate-limit result as a billing ledger.

Data handling

The deployed Worker is stateless. Creative briefs and client-carried states are processed in memory for the duration of a request.

Cloudflare observability may record standard request metadata according to the operator's Cloudflare configuration. Avoid logging request bodies. Disable or narrow observability if your deployment must minimize metadata retention.

Resource-exhaustion considerations

Structured states can grow when clients repeatedly send prior results. The Worker caps request size, normalizes collection lengths, limits generated candidate counts, and runs under a configured CPU ceiling. Clients should send only the selected ideas and feedback needed for the next operation rather than an unbounded session transcript.

Reporting

Do not include private creative briefs, credentials, personal data, or unpublished work in a public issue. Report vulnerabilities privately to the repository owner.

There aren't any published security advisories