Email kyle@corpdevcompanion.com rather than opening a public issue. Include what you found, how to reproduce it, and what an attacker could do with it. You will get a reply within three business days.

Please do not run automated scanners against the hosted deployment — every request there costs real money on third-party APIs. Run it locally instead; npx netlify dev gives you the same functions.

• Every function begins with guardRequest(): method check, origin allowlist, body-size cap and a per-instance rate limit.
• API keys are server-side only. The browser never sees an Anthropic or FMP key; anything with a VITE_ prefix is public by definition and only the Supabase anon key uses it.
• Supabase access is governed by row-level security. Read supabase/schema.sql — the SECURITY MODEL comment block explains what each policy assumes — before changing any policy.
• A content security policy is set in netlify.toml. It is deliberately tight: default-src 'self', no unsafe-eval, and an explicit allowlist for fonts, the tag container and Supabase.

These are documented rather than fixed, because the fix would cost more than the risk warrants for a free tool. If any of them matters to you, self-host.

• Rate limiting is per function instance, in memory. Netlify may run several instances concurrently, so the effective limit is higher than the configured one. It is a speed bump against casual abuse, not a defence against a determined attacker.
• Sessions are anonymous. Anyone with a share code can vote in that session. Codes are not guessable in practice, but there is no authentication and none is claimed.
• Solo session state lives in localStorage, unencrypted. On a shared machine, clearing site data is the only way to remove it.
• Submitted text reaches Anthropic. Custom options you type are sent as part of the prompt. The UI says so; do not enter material non-public information.

The main branch is the only supported version. Fixes are not backported.