Security

How Respondo keeps accounts, keys and answers apart, written from how the system actually works.

Describes the product as it runs today.

Two kinds of key

Publishable keys (rsp_pk_…) go in your pages. They are made to be public: a page uses one to load a survey and send answers to it.

Secret keys (rsp_sk_…) act as you, for MCP clients that cannot sign in through a browser. Respondo stores only a SHA-256 hash of each one, so the key is shown once, when it is created, and never again. Keep them out of pages and repositories.

Accounts stay apart

Reads and writes go through database functions that work out which account a credential belongs to themselves. Access is never assembled in the application code that calls them, so there is no filter a later change could forget, and no path for one account to read another’s surveys or responses.

Assistants and the MCP server

MCP clients sign in with OAuth: an authorisation code with PKCE (S256), exchanged for a token issued for the Respondo server alone. Access comes in two scopes, reading surveys and changing them, so a connection can be allowed to read without being allowed to publish or delete.

  • You approve each client on a Respondo consent screen.
  • Every connected client is listed in Settings under Connected apps, and can be revoked there.
  • A missing scope is refused outright, not reported to the assistant as an ordinary error, so a client knows to ask you again rather than try something else.

The survey widget

The widget sets no cookies. It keeps three small values in the visitor’s browser storage: a random respondent id, whether this browser has answered a survey, and its place in a survey’s sample. None of them identifies a person.

Names, emails and traits are sent only if your site passes them. See Cookies for the details.

Where data lives

Surveys, responses and accounts are stored in Postgres on Supabase, and all traffic to Respondo is served over HTTPS.

Report a vulnerability

If you find a security issue, email support@myrespondo.com with “Security” in the subject. Include what you found and how to reproduce it.

Please give us a chance to fix it before telling anyone else, and do not access or change data that is not yours while testing.