security-review

Always use parameterized queries or an ORM instead of string concatenation. With Supabase, use query builder methods like .eq('email', userEmail); with raw SQL, pass values as bound parameters like db.query('SELECT * FROM users WHERE email = $1', [userEmail]).

Store tokens in httpOnly cookies with Secure and SameSite=Strict flags, never in localStorage, which is vulnerable to XSS attacks. Set the cookie via the Set-Cookie response header with an appropriate Max-Age.

Use Zod schemas to define expected shapes and parse all incoming data before processing. Prefer whitelist validation over blacklists, restrict file uploads by size, MIME type, and extension, and avoid leaking sensitive details in validation error messages.

No, RLS and application-level authorization work together. Enable RLS policies on every table so users can only access their own rows, and still verify roles in server code before sensitive operations like deletions.

Detailed errors and stack traces expose internal implementation details that attackers can exploit. Return a generic message like 'An error occurred' to users while logging full details only on the server.

Verify wallet ownership by checking a signed message against the user's public key using signature verification from @solana/web3.js. Also validate transaction recipients, amounts, and balances before signing to prevent blind transaction approval.