Bootstrapware Feedback security

Publishable vs secret keys

• bsw_test_pub_ / bsw_live_pub_: browser-safe for config and Hosted widget calls.
• bsw_test_sec_ / bsw_live_sec_: server only. Never ship in client bundles or NEXT_PUBLIC_ / VITE_ env vars.

Dashboard login uses a user session cookie, not a secret API key in the browser.

Host-asserted author.id

Bootstrapware does not authenticate board end users. Your host asserts an opaque stable user.id. Publishable key + forged author.id can be abused if the key leaks. Mitigate with allowed origins and optional authorToken (mint with your secret key; enable requireAuthorToken on the board). Treat client validation as UX, not a trust boundary.

Guide: host-asserted identity.

Origins and CORS

Browser calls to the Feedback API are subject to CORS via allowed origins. Production should list the exact origins that embed the widget. This is not a substitute for keeping secret keys off the client. See origins.

BYO vs Hosted data path

• BYO: post title/body never touch Bootstrapware. Your adapter hits your API.
• Hosted: posts and votes (plain text) are stored on Bootstrapware. You moderate; you own content decisions. Cancel Hosted: freeze writes immediately; JSON export for 30 days; then delete.

MCP boundary

MCP configures boards only (list_boards, draft, publish, …). Never send post title or body through MCP tools. Prefer OAuth Connect over putting secret keys in mcp.json.

Webhook signing

Deliveries POST JSON and sign the raw body with HMAC-SHA256. Verify header X-Bootstrapware-Signature (hex digest) using your endpoint secret. Payloads carry identifiers, not title/body. See webhooks guide.

What Bootstrapware cannot access (BYO / local)

• Post title and body on BYO or local adapter
• Your database
• Your application session cookies (unless you send them yourself)
• End-user passwords or OAuth tokens for your product login